>>>>> 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.)
Q>
Q> IN PARTICULAR, ANY DISTRIBUTION WHICH CONTAINS A DEVICE
Q> DRIVER USING MAJOR NUMBER 42 IS NONCOMPLIANT.
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
correct?
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.
Comments?
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. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/