lkml.org 
[lkml]   [1999]   [Oct]   [9]   [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.991008155428.5043A-100000@chaos.analogic.com> Richard B. Johnson (root@chaos.analogic.com) wrote:
RJ> On Fri, 8 Oct 1999, Dan Hollis wrote:

>> On Fri, 8 Oct 1999, Khimenko Victor wrote:
>> > RJ> The Unix-like kernel knows only major/minor device numbers, not names.
>> > Which POSIX standard says how unix-like kernel acts inside ???
>>
>> I'm beginning to wonder why we're still fumbling around with the
>> major/minor concept. Is there any compelling reason for it other than
>> "thats the way we've always done it since 1970's, and 640k is enough ram
>> for anyone"?
>>

RJ> Because CPUs are much more efficient at handling numbers than strings.

This is not an argument (see below).

RJ> What 'ls' (readdir) or whatever, does is convert a bunch on numbers to
RJ> human-readable form. Internally, files are just numbers (inodes). In
RJ> fact, a VFS (virtual file-system) is just a linked-list of inodes.
RJ> Periodically, if the linked-list starts to use too much memory, it's
RJ> written to physical media and the linked-list is pruned. This is what
RJ> Unix file-systems, including ext2, are all about. Some file-systems,
RJ> (FAT comes to mind), are not designed in this way. Therefore, to
RJ> be compatible, they are partially emulated in the Unix environment.

RJ> The human-readable format of a file or a device has no real place
RJ> within any operating system. It adds overhead and bulk. It is only
RJ> when a human needs such a translation that the translation should
RJ> be done.

Correct. And major/minor numbers are not needed there.

RJ> To give a simple example, given:

RJ> LargeFileNameDirectory/LFN-Subdirectory/MyFile.txt

RJ> ... requires 3 directory lookups to obtain a number. After which,
RJ> the file is accessed as a number. It is read/written/extended/truncated,
RJ> /seeked, etc, without ever having to parse strings again.

Correct.

RJ> The same is true for 'special files'. These require a lookup first
RJ> to associate a major/minor number (instead of an inode). Then the
RJ> human readable name string is never accessed again. To do it any other
RJ> way would be to return to the days before even CP/M.

Not at all. Take a look on how devfs doing it: when special file under /dev
is created then it's connected with address of driver (roughly: automatically
created major/minor numbers and lookup there is just to make system compatible
with what was done before). When you access driver you just access driver.
Without additional lookups in major/minor numbers table ! Gosh. Why MORE
EFFECTIVE and MORE SCALEABLE thing is called "days before even CP/M" is
beyond me.

RJ> Historical buffs may remember that the file-system on the famous
RJ> "green-machine" (MDS-200), circa 1967, consisted of 'directory' entries
RJ> that contained only numbers. A directory program translated these numbers
RJ> into strings in a "container file". (No M$ didn't invent the container
RJ> file). Even then, it was understood that strings didn't belong within
RJ> an operating system.

Gooch also understood it very well. But when you try to open device you WILL
use string (like "/dev/printer/0") and not number anyway. So transition phase
is needed anyway. Why we must translate it to major/minor numbers first and
not straight to driver address ? It is beyond me.

RJ> So, we are not "fumbling around" with the major/minor concept. It
RJ> is an excellent, efficient way of handling devices.

Not at all. This is idea is not scaleable and not effective. Read devfs FAQ
and you'll find -- why.

RJ> However, soon it will have to be extended because we need more numbers.

And it'll make it even less effective (though more scaleable :-)





-
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.185 / U:1.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site