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

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