Johannes Erdfelt <jerdfelt@sventech.com> said:
[...]
> 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
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.
> - 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.
> 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.
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.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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