On Mon, Apr 17, 2000, Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> Johannes Erdfelt <jerdfelt@sventech.com> said:
>
> > 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
>
> Why? If it is s fixed API, it could be implemented as a library or a bunch
> of macros/inline functions in a .h somewhere.
I'm talking userspace API, syscalls. It's more bloat.
I suppose you're talking merging all of the minor number resolution into
a common header file or library.
That is exactly what devfs does in essence, but with a different name to
it.
> > - 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
>
> Right. But it has to be redone for any change, so this isn't a issue
> really.
And it's already been done for devfs. No more work required.
> > 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
>
> Broken. See above.
>
> > - Many subsystems will use similar code to do this resolving
>
> See above.
>
> > - Centralizing it reduces code which reduces memory footprint, and
> > possible bugs
>
> See above.
Exactly, and that effectively reinvents devfs.
Except for devfs doesn't have any of the problems with assigning and
maintaining numbers.
Plus, using names versus numbers is already Linus approved. See the
thread on sysctl.
> That currently devices on disk are handled via a magic 16 bits that are
> split into major/minor 8+8 doesn't mean you could use more bits, do other,
> non-uniform splits (like the 8+24, 16+16, 24+8 or thereabouts split in A
> through C class nets), or even just use a 32 (or whatever) bit cookie for
> the device. Sure, mknod(8) won't work the same in the last case, but that
> shouldn't be a big hindrance.
So, why hasn't the major/minor numbers been increased? This has been a
problem forever.
Cookies are something that hasn't been brought up yet. However, it adds
another kernel to userspace interface to agree on cookies to be created.
Plus, you'll have some interesting and catch-22's with system startup.
Actually, many of the suggestions you made are remarkably similar to
devfs, but buys us very little.
Plus, devfs is already here and implemented.
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