lkml.org 
[lkml]   [1999]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.820 / U:0.288 seconds]
©2003-2011 Jasper Spaans. Advertise on this site