Toward a larger dev

Toward a larger dev_t

Posted Mar 27, 2003 23:23 UTC (Thu) by torsten (guest, #4137)
Parent article: Toward a larger dev_t

devfs creates as many problems as it solves. Here are some:

1. Requires modifying applications that are stable, mature, secure, and well-tested.

2. devfs requires an ugly hack overlay daemon to maintain compatibility with the current standard. The correct way to fix this is change all /dev dependent programs, but the devfs proponents are not spearheading the work.

3. While there are fewer devices present in /dev, the device naming is more complicated. i.e. /dev/hdc1 becomes /dev/ide/disk/1/cb0u0u0p0 (or something like that, it was so complicated, I couldn't remember it exactly). The same reduction in complexity can be had with /dev by deleting unused /dev devices (i.e. I could easily whittle my /dev down to 10 or 15 device names by deleting unused devices).

4. It is not a unifying solution, it divides opinion. This is the most damaging.

5. The devfs guys have not rewritten all the utilities whose authors refuse to play along with devfs implementation. The overlay daemon is not a long-term solution.

6. Does not handle the situation well, where a program requires the existence of a device node prior to the device being attached to the machine (i.e. plugging and unplugging a device while it's associated control software is running).

7. Implements a plan of rapid change. This is not how proper development is done (proper development is obviously far less exciting because of this).

8. Lack of confidence - devfs has been available for a long time, but there is no trend to have it universally adopted.

9. devfs requires more typing - for those of use that still use the command line, devfs represents far more typing than /dev. Also, the similar naming of device partitions means the universal [tab] completion does not work well.

10. devfs has more levels of abstraction than needed. As a general rule of thumb, data abstraction layers should match the complexity of data. devfs implements four to five levels of abstraction. In the case there are 10 devices attached to a system, a typical person would not need more than one level of abstraction (I can easily handle names of ten devices in one directory, where having ten devices spread out over four or five levels of subdirectories is useless).

Torsten

to post comments

devfs transition, not devfs, is the problem

Posted Mar 31, 2003 18:59 UTC (Mon) by giraffedata (guest, #1954) [Link]

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.