News Group Posts

driver development, kernel, device

drivers

See SCO Device Drivers

From: Bela Lubkin <belal@sco.com>
Subject: Re: What does P mean in 3rd field of mdevice?
Date: Thu, 31 Jul 2003 08:51:49 GMT
References: <450ab60f.0307301143.7c56c773@posting.google.com> 

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?
> 
> http://groups.google.com/groups?as_umsgid=20021105105251.H3983%40mammoth.ca.sco.com

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<

Comments?

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.