Professional Web Applications Themes

What does P mean in 3rd field of mdevice? - SCO

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 doented 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]...

  1. #1

    Default What does P mean in 3rd field of mdevice?

    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 doented 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]
    Roger Cornelius Guest

  2. #2

    Default Re: What does P mean in 3rd field of mdevice?

    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 doented 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 Fx 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" Fx 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<
    Bela Lubkin Guest

Similar Threads

  1. Forms: Text field - auto fill another field?
    By LDVDG@adobeforums.com in forum Adobe Acrobat Macintosh
    Replies: 3
    Last Post: May 18th, 05:35 PM
  2. Comparing current field data with last entry for field
    By ccnorris in forum Coldfusion - Advanced Techniques
    Replies: 8
    Last Post: June 1st, 03:20 AM
  3. Defined text field in form -> subject field in e-mail
    By olaka in forum Dreamweaver AppDev
    Replies: 0
    Last Post: March 14th, 02:20 PM
  4. Linking date field to text field entry
    By Trey in forum Microsoft Access
    Replies: 1
    Last Post: July 16th, 07:35 PM
  5. Curved Field vs Flat Field projector lenses
    By Paddleman in forum Photography
    Replies: 3
    Last Post: July 10th, 02:20 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139