devfs transition, not devfs, is the problem
devfs transition, not devfs, is the problem
Posted Mar 31, 2003 18:59 UTC (Mon) by giraffedata (guest, #1954)In reply to: Toward a larger dev_t by torsten
Parent article: Toward a larger dev_t
Virtually all of these problems with devfs have to do with moving from major/minor numbers to devfs. Devfs per se remains a far more logical and useful way to name devices than major/minor number.
And it is a Linux tradition to accept transition pain as a means of getting to a better place.
The typing argument is an easy one to deal with: Make symbolic links from short file names to the descriptive ones.
devfs has more levels of abstraction than needed
This one I don't get. Devfs removes a layer of abstraction: the major and minor numbers. The concrete way to identify a device is "Logical Unit 0 on Target ID 3 of Bus 0 on Controller 0 in the SCSI subsystem." Mapping that to a major and minor number, as is required in the traditional device naming system, is a layer of abstraction. Mapping the device number to a name such as /dev/sdb is another. And one of those layers is extremely problematic, because the mapping is fairly fluid.
It's better not to introduce two additional names for a device. Devfs uses a (derivation of a) name the device already had.
The biggest valid criticism I've seen of devfs is that it doesn't provide an acceptable way to set the permissions to access a device. In the major/minor scheme, you create a permanent special file and set its permissions, and if you can manage to make sure the same device has the same device number all the time, its permissions are permanent.
But permanent permissions have drawbacks too -- many devices are not setup such that the same people are supposed to be able to read and write them all the time -- tty's, serial lines, removeable media drives. So again, I think the complaint is just that there are existing applications tailored to the exact limitations of the major/minor number permission system.
