RJ> What? The only reason for any of the stuff in the /dev directory is
RJ> to associate a major/minor number with a file-descriptor. This happens
RJ> during open(). This is Unix and that's the way Unix works. the choice
RJ> of putting such "devices" in the "/dev" directory is policy. They
RJ> could be anywhere.
Why it's so important ?
RJ> Any 'devfs' cannot violate the Unix policy or you don't have Unix.
And what if I'm not want Unix ? Keep something to be "unix way" just for sake
of keeping it "unix way" looks really stupid to me.
RJ> This whole discussion is moot. What is needed is a larger dev_t.
Devfs can do much more then just expanded dev_t ...
RJ> It could be a structure (as proposed) or it could be a N-bit word.
RJ> It doesn't matter, these are implementation details. Because of
RJ> the way dev_t, both in the kernel, and in the C runtime library, is
RJ> accessed, any change will break practially everything. So changes
RJ> must be carefully thought out.
On other hand adding devfs breaks MUCH less things.
RJ> Presently, a kernel that uses 'struct dev_t' will boot and then
RJ> fail to do anything useful after that. Every program that accessed
RJ> files (practically all, if they use standard I/O), will have to
RJ> be recompiled using a new 'C' runtime library that was modified to
RJ> use the new dev_t structure. This is a lot of work, but will probably
RJ> eventually have to be done.
Hmm. With devfs you can avoid all this. Even if it's not "Unix way".
RJ> Something called 'devfs' where only existing hardware has entries
RJ> written in 'dev' fails to address the problem. It is not the amount
RJ> of names (directory entries) that we are running out of, it is the
RJ> amount of available values in major/minor device numbers.
Correct. And when device is identified by name and not by major/minor number
internally you have no such problem in first place.
RJ> The Unix-like kernel knows only major/minor device numbers, not names.
Which POSIX standard says how unix-like kernel acts inside ???
RJ> If you have so many devices that you need major number N, you are
RJ> presently screwed if N is greater than can be represented in the
RJ> current dev_t.
You hardly will have more then 65536 devices (dev_t size) and still now
we have size of dev_t as limiting factor...
RJ> So instead of inventing a new Operating System that doesn't use
RJ> major/minor device numbers, I feel that time would be better spent
RJ> extending the current dev_t. I personally like the structure approach
RJ> because shifts/ANDs/ORs are machine-specific while a properly aligned
RJ> structure is not.
Unfortunatelly dev_t structure is also not "unix way". Since you can not
use assignment in C for dev_t. And if we are going to go out of "unix way"
anyway then why it should be dev_t definition and not some other thing ?
-
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/