The LANANA discussion has forked into a forest of vaguely related
discussions. If I am not mistaken the only real question is
how user space and kernel space communicate device identities.
Here "user space" is very different from "users".
Devices have a device path and device contents.
For the user it is very desirable to recognize things by contents.
One invents labels and similar schemes, both readable with the eye
and readable with software.
But devices vary quite a lot and labeling schemes vary quite a lot
and user needs vary quite a lot.
Clearly, recognizing a device by contents is something that belongs
to user space.
Of course the kernel can make functions available to simplify
the work of a device manager, but the actual work of making the
correspondence between the identity of a device as seen by the user
and the device path belongs to user space. Be it a boot-time setup
script working from a data base, or a daemon.
(A somewhat weaker function also belongs to user space:
Even if the user has not specified a name for a device
it may be that the device has a serial number or other
recognizable information, so that user space can guess
or be sure that a certain device is the same as something
seen earlier, perhaps before the last reboot.)
That was the user. She thinks about "my boot partition".
And mount sees "UUID=e70bde8e-34d7-11d... /boot ext2 ..."
or "LABEL=Boot /boot ext2 ..." and searches /proc/partitions for
things that, when interpreted as an ext2 filesystem, have
the specified UUID or label.
The communication between user space and kernel is not in terms
of device "contents", since the kernel doesnt know about such
things. The kernel knows only one thing: the device path.
(the driver used, together with all parameters, the port address,
the SCSI ID, the disk subinterval, ...)
But this path is a very complicated object. Moreover, it contains
a lot of items that the user has never heard of. It is a bad idea
to try to use such paths.
So we have: user space has file names and uses open() or mount().
Kernel space has device paths.
In principle the kernel could just number the devices it sees 1,2,...
and export information about them, so that user space can choose
the right number.
The part about exporting information is good. User space needs to
be able to ask if a certain beast is a CD reader, and if so what
manufacturer and model.
But the part about numbering 1,2,... may not be good enough, e.g.
because it does not survive reboots. If we remain Unix-like and use
device nodes in user space to pair a file name with a number, then
it would be very nice if the number encoded the device path uniquely.
Many programs expect this.
It cannot be done in all cases, but a good approximation is obtained
if the number is a hash of the device path. In so far the hash is
collision free we obtain numbers that stay unique over a reboot.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 23 2001 - 21:00:21 EST