Messages in this thread |  | | | From | "Khimenko Victor" <> | | Date | Fri, 8 Oct 1999 20:34:23 +0400 (MSD) | | Subject | RE: [linux-usb] Re: USB device allocation |
| |
In <Pine.LNX.3.95.991008110717.897A-100000@chaos.analogic.com> Richard B. Johnson (root@chaos.analogic.com) wrote: RJ> On Fri, 8 Oct 1999, Khimenko Victor wrote: >> Devfs DO NOT need major/minor system. It uses major/minor system for existing >> devices to simplify conversation but it's not requirement.
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/
|  |