Messages in this thread | | | From | "Khimenko Victor" <> | Date | Sat, 9 Oct 1999 13:10:43 +0400 (MSD) | Subject | RE: [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/
| |