lkml.org 
[lkml]   [1998]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.042 / U:2.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site