What? The only reason for any of the stuff in the /dev directory is
to associate a major/minor number with a file-descriptor. This happens
during open(). This is Unix and that's the way Unix works. the choice
of putting such "devices" in the "/dev" directory is policy. They
could be anywhere.
Any 'devfs' cannot violate the Unix policy or you don't have Unix.
This whole discussion is moot. What is needed is a larger dev_t.
It could be a structure (as proposed) or it could be a N-bit word.
It doesn't matter, these are implementation details. Because of
the way dev_t, both in the kernel, and in the C runtime library, is
accessed, any change will break practially everything. So changes
must be carefully thought out.
Presently, a kernel that uses 'struct dev_t' will boot and then
fail to do anything useful after that. Every program that accessed
files (practically all, if they use standard I/O), will have to
be recompiled using a new 'C' runtime library that was modified to
use the new dev_t structure. This is a lot of work, but will probably
eventually have to be done.
Something called 'devfs' where only existing hardware has entries
written in 'dev' fails to address the problem. It is not the amount
of names (directory entries) that we are running out of, it is the
amount of available values in major/minor device numbers.
The Unix-like kernel knows only major/minor device numbers, not names.
If you have so many devices that you need major number N, you are
presently screwed if N is greater than can be represented in the
current dev_t.
So instead of inventing a new Operating System that doesn't use
major/minor device numbers, I feel that time would be better spent
extending the current dev_t. I personally like the structure approach
because shifts/ANDs/ORs are machine-specific while a properly aligned
structure is not.
Cheers,
Dick Johnson
**** FILE SYSTEM WAS MODIFIED ****
Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
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/