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