Messages in this thread | | | Date | Tue, 6 Jan 1998 17:01:04 -0600 | From | Michael Elizabeth Chastain <> | Subject | Re: devlinks: an alternative to devfs |
| |
Hi Richard,
> I see a problem with this: when you open /dev/block/fd:0,format=360 > the kernel will have to parse "fd:0,format=360" in order to determine > which set of f_ops callbacks are required for that device.
Nitpick: the user doesn't open /dev/block/fd:0,format=360. The user opens /dev/fd0D360, just like they do right now.
Yes, the driver will have to parse. Right now, the kernel passes an opaque 8-bit minor number to the driver, and the driver interprets that. A driver could continue to use a very simple, very parseable coding scheme for its parameters, such as two hexadecimal digits. Or a driver that needs more complex options, such as a scsi disk driver, could have more advanced parsing.
> And it looks like you would need to search all these entries too. This > is different than implementing a devfs, since it won't use the dcache. I > think this scheme will be rather slow.
It would have the same cache properties as the existing /dev directory.
> > Devlinks can be put anywhere the administrator wants, such as chroot > > jails, or devlinks in /tmp during a system installation. > > You can mount devfs N times.
That's true. Devfs still needs more control mechanisms. If I set up a chroot jail, I want to have /dev/null in it, but I don't want to have my insmod'd printer driver popping up in there.
Regards,
Michael
| |