[lkml]   [1999]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Migrating to larger numbers
    Hi Peter, Rogier.

    >>>>> And so how do you distinguish between (0,2000) and (7,208)?

    >>>> I do not.

    >>>> (But (0,2000) is not normalized and hence would not normally
    >>>> occur.)

    >>> "Normalized"? We need to support more than 255 anonymous
    >>> devices. I believe your basic idea is good, but the only possible
    >>> escape number is ~0, not 0.

    >> Hmmm. If I get this correctly, my kernel draws a new number from
    >> it's hat when I mount /proc or an NFS mount?

    >> Well, from the isofs specification, we can conclude that it is
    >> highly frowned upon to use major 0 for anything. We might consider
    >> moving THAT. On the other hand, the major 0 thingy is completely
    >> inside the kernel, so that it would never be handed to the
    >> conversion routine anyway.

    > That's a good point, actually. I don't know how much in the
    > kernel would break if we moved unnamed devices away from 0.
    > Perhaps we should leave 0:0 as the null device and use another
    > major for the anonymous devices.

    I've just had a look at the Documentation/devices.txt file included
    with kernel 2.2.9, and the obvious solution based on that file would
    be to swap the definitions of majors 0 and 42 over. For reference,
    here are the relevant definitions therein:

    Q> 0 Unnamed devices (e.g. non-device mounts)
    Q> 0 = reserved as null device number

    Q> 42 Demo/sample use
    Q> This number is intended for use in sample code, as well
    Q> as a general "example" device number. It should never be
    Q> used for a device driver that is being distributed; either
    Q> obtain an official number or use the local/experimental
    Q> range. The sudden addition or removal of a driver with
    Q> this number should not cause ill effects to the system
    Q> (bugs excepted.)

    The basic problem is to determine what sort of effect this particular
    change would have on driver development, as it's the sort of change
    that could easily be implemented.

    Whilst I'm talking about devices.txt, can I confirm the status of the
    so-called alternate serial devices? If, as I've been told, they have
    now been discontinued, would I be right in assuming that the following
    char major numbers are all now obsolete:

    5, 18, 20, 23, 25, 33, 44, 47, 49, 72, 76 and 79.

    Also, block major 40 is apparently obsolete. Is that correct ???

    Finally, I note that major 28 is listed as having two conflicting
    definitions both as a character major and as a block major. Is this

    Personally, I'd like to see the system completely redone in 2.3, and
    would propose something along the lines of the following (assuming 32
    bit node numbers):

    1. Split the node number into three subfields as follows:

    a. The most significant byte specifies the Category.

    b. The next two bytes specifies the Major.

    c. The least significant byte specify the Minor.

    This allows for 256 categories, each with 65,536 majors in them,
    and each major can have 256 minors in it.

    2. Define nodes with Category 0, Major 0 as "Compatibility nodes",
    and arrange for the kernel to convert each to the equivalent new
    node number, as appropriate.

    3. Define nodes with Category 0, Major >0 as "Development nodes".

    4. Define other categories as follows (this list for block devices):

    Category Major Definition
    ~~~~~~~~ ~~~~~ ~~~~~~~~~~
    1 All Experimental
    2 0 Floppy discs
    1 EIDE primary channel, master drive
    2 EIDE primary channel, slave drive
    3-4 EIDE secondary channel
    5-6 EIDE tertiary channel
    7-8 EIDE quaternary channel
    9-10 EIDE fifth channel
    11-12 EIDE sixth channel
    13-14 EIDE seventh channel
    15-16 EIDE eighth channel
    17-32 EIDE 9th-16th channels
    33+ Other non-SCSI discs
    3 All SCSI hard discs

    Other categories are defined as required.

    5. Specify that all hard disc categories shall use the minor to
    select the appropriate partition on the device, with minor 0
    specifying the entire device and minors 1 through 255 specifying
    partitions 1 through 255 on the device in question. This allows
    far more partitions per device than are currently available, and
    also does not differentiate between device types when allocating
    these limits.

    Also, one fairly simple means to ensure that compatibility nodes were
    used as little as possible would be to arrange for the kernel's mknod
    service to translate any request to create a compatibility node into
    one to create the equivalent new node.


    Best wishes from Riley.

    | There is something frustrating about the quality and speed of Linux |
    | development, ie., the quality is too high and the speed is too high, |
    | in other words, I can implement this XXXX feature, but I bet someone |
    | else has already done so and is just about to release their patch. |

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.027 / U:70.952 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site