Messages in this thread | | | Subject | Re: devlinks: an alternative to devfs | From | (Eric W. Biederman) | Date | 06 Jan 1998 19:06:15 -0600 |
| |
>>>>> "RG" == Richard Gooch <rgooch@atnf.CSIRO.AU> writes:
RG> Michael Elizabeth Chastain writes: >> devlinks could also specify parameters to their drivers. For instance, >> all of the /dev/fd* files would become devlinks like this: >> >> /dev/fd0 -> block/fd:0 >> /dev/fd0D360 -> block/fd:0,format=360 >> /dev/fd0D720 -> block/fd:0,format=360
RG> I see a problem with this: when you open /dev/block/fd:0,format=360 RG> the kernel will have to parse "fd:0,format=360" in order to determine RG> which set of f_ops callbacks are required for that device. And it RG> looks like you would need to search all these entries too. This is RG> different than implementing a devfs, since it won't use the dcache. I RG> think this scheme will be rather slow.
You could use the dcache by having a pseudo directory, with all of the devices in it. With registration and deregistration functions as proposed by the devfs folks. I think I'd name them major_name:minor_name.
>> Devlinks can be put anywhere the administrator wants, such as chroot >> jails, or devlinks in /tmp during a system installation.
RG> You can mount devfs N times.
This is tricky.
>> Devlinks solve the limitation of 8-bit minor numbers almost forever >> (there is some huge limit on the length of a filename but I doubt that >> will ever be a problem).
It still leaves open the problem of generating a device number for stat. If it is centrally located in a directory, I guess the registration functions could arbitrarily assign numbers.
Also as ext2 has optimizations to put small symlinks in the inode, it should be no worse than a device.
Eric
| |