Don't confuse major numbers (which are really a kernel internal thing) with
names. Major numbers serve a very useful purpose in allowing quick device
driver identification. It would be an unhappy state of affairs if we had to
parse both the major and minor numbers extensively just to identify the device
driver to handle the request. There's no reason why we can't use a consistent
naming scheme for all CD-ROMs and yet have them using different major numbers.
One of the advantages of driverfs, I think, is that it separates the device
name from a static entry in /dev which is tied to a major/minor number.
> 6. The /name is entierly redundant logically to the fact that we have
> already a unique path to the device. For "pretty" printing we have
> userspace. For PCI it's for example repeating the ID info found
> already by lspci.
The /name is useful in the enterprise for persistent device identification.
Leaves in the device tree can move as boxes are regconfigured. The name entry
helps you find your leaf again when this happens. It also helps you find the
same storage in a cluster regardless of the device driver or storage
> And last but not least: I still don't see any kind of abstraction
> there which would allow to easly enumerate for example all disks in
> the system.
Doesn't this depend on the semantics provided in the device node (leaf)? If
you had a way of identifying disk devices (say from an empty type=disk file)
then you could do a simple find to list all the disks in the system regardless
of being SCSI, IDE, SSA etc.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/