What does P mean in 3rd field of mdevice?

[Roger Cornelius]

In the article referenced below, Bela Lubkin mentions adding the 'P'
characteristic to the third field of /etc/conf/cf.d/mdevice. This
characteristic is not documented in mdevice(F) on 5.0.6 or 5.0.7.
Anyone know what it is?

[url]http://groups.google.com/groups?as_umsgid=20021105105251.H3983%40mammoth.ca .caldera.com[/url]

[Bela Lubkin]

Roger Cornelius wrote:

> In the article referenced below, Bela Lubkin mentions adding the 'P'
> characteristic to the third field of /etc/conf/cf.d/mdevice. This
> characteristic is not documented in mdevice(F) on 5.0.6 or 5.0.7.
> Anyone know what it is?
>
> [url]http://groups.google.com/groups?as_umsgid=20021105105251.H3983%40mammoth.ca .caldera.com[/url]

The 'P' characteristic means that the driver can deal with buffer
addresses which are not in the direct map. OpenServer's kernel virtual
address space includes an area from C0000000 to EFFFFFFF, 768MB in size,
which is "direct-mapped" to physical addresses. For instance, if you
need access to memory at physical address 000B8000, you can use kernel
virtual address C00B8000. (This is normally done with macros and
functions, it would be very poor coding practice to embed this "fact"
directly into code.)

Memory which is in use for kernel structures usually has a second kernel
virtual address in the Fxxxxxxx range, arbitrarily assigned with no
relation to physical addresses.

Because hardware devices usually need physical addresses, drivers often
convert kernel virtual addresses to physical addresses. Physical
addresses may get passed around and become disassociated from their
original kernel virtual address (a low level routine may be called with
only the physical address).

Mapping from an arbitrary physical address to an existing, already valid
kernel virtual address that refers to the given memory can be expensive.
Many drivers use a shorthand approach of using the direct mapping of the
memory, without looking up the "real" Fxxxxxxx kernel virtual address.

Drivers which date back to before OSR5 even supported memory above 768MB
may assume that _all_ physical addresses can be mapped in this manner.
Such drivers will probably do something horribly wrong if passed buffers
whose physical addresses are outside the direct map. Unless a driver
identifies itself as being aware of this possibility, the kernel only
sends it buffers which can successfully be referred to through the
direct map; i.e. whose physical addresses are between 00000000 and
2FFFFFFF.

The distinction applies primarily to buffer cache buffers. Since the
OSR5 buffer cache is limited to a total of 450MB, it is usually
allocated entirely out of direct-mapped memory. This means that the 'P'
characteristic is less important than it sounds. Basically it allows
the kernel to pass in non-direct-mapped buffers _if_ any of those
actually exist.

If the buffer chosen for a particular use has a high address and the
driver doesn't have the 'P' characteristic, a "bounce buffer"-like
scheme is used. The high buffer's buffer header is temporarily linked
to a low memory buffer. For a write, data is copied from the true high
buffer address into the linked low buffer before invoking the driver;
for a read, after the driver has delivered the data into the low buffer,
it's copied up into the high buffer. Then the linked low buffer is
released.

The 'd' characteristic means much the same thing, but applies to an
earlier addressing transition. Drivers without 'd' get bounce buffer
treatment for any buffer whose physical address is outside ISA DMA
range, i.e. above 00FFFFFF.

Drivers can inform the kernel of their capabilities at runtime, so the
'd' and 'P' flags in mdevice are not absolute guides. For instance the
old Compaq "ida" driver internally sets 'd' and 'P'. Also, all SCSI
HBAs (drivers with 'h' characteristic) set these flags by a different
mechanism.

>Bela<