> 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