On Fri, Apr 14, 2000, Horst von Brand <vonbrand@sleipnir.valparaiso.cl> wrote:
>
> > Keeping it in the filesystem is not enough.
>
> Agreed.
>
> And the userspace daemon modifies a normal, on-disk filesystem to reflect
> new devices as they appear, the user chmod(1)s and chown(1)s them to her
> heart's content. No virtual filesystem needed at all.
>
> I've been told that this scenario doesn't solve the problems devfs is
> supposed to solve, but nobody has been able to explain to me exactly what
> those unsolvable problems are, and why they are problems worthy of solution
> in the first place.
>
> How do you record devices in the filesystem is up to you, it doesn't have
> to be via major/minor numbers. Any unique ID will do. There is plenty of
> unused space in an inode used for a device right now. So the "no
> major/minor" argument doesn't cut it either. Or am I overlooking something
> fundamental here?
There are a couple of different problems devfs solves. I think everyone
agrees that devfsd (or something similar) is needed and I haven't seen
anyone disagree with it.
The majority of disagreement I see is with the VFS portion of devfs.
Here's my problems with major/minor numbers:
a) It is difficult to increase the size of the major/minor numbers
b) It encourages duplication of code in subsystems instead of
centralizing it
c) It encourages the use of assigned numbers, rather than names
Clarification on point a:
- All of the API's which use major/minor numbers need to be duplicated and
a new one created to support legacy code using the 8/8 split
- Most subsystems use an array of 256 entries to determine which minor
number goes to which device. This will have to be rewritten to work
correctly
Clarification on point b:
- Each subsystem has it's own code to resolve a minor number into a
device. Along with the increased major/minor numbers, will result in
more complicated code to avoid wasting memory
- Many subsystems will use similar code to do this resolving
- Centralizing it reduces code which reduces memory footprint, and
possible bugs
Clarification on point c:
- Recently Linus has stated he would like to see sysctl move to a
completely name based interface since assigning and tracking numbers
is difficult and prone to problems. Some people have some issues with
sysctl using names vs numbers, but they are completely unrelated
JE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:11 EST