On Tue, 11 Apr 2000, George Bonser wrote:
>> (mounting it under /devfs instead of /dev) and there still seem to
>> be many people opposed to devfs.
And I'm one of them...
>> So, I know the pro side of devfs, but I would like to read up on
>> the objections raised so I can make a judgement for myself.
>
>While this subject is up ... is there any problem with linking from /dev
>to /devfs ?
I don't see any problem with it as long as your system can live without any
valid entries in /dev until devfs is mounted. Of course, the primary reason
for devfs is "all the wasted space" from over a thousand nodes in /dev.
Each one uses one FS block (4k in my case) to store a few bytes of info.
The symlinks, while using more of the inode, still waste an entire FS block.
The answer to this problem is a fs capable of storing "non-files" more
efficiently. Devfs is doing this in kernel memory (in a fashion I'm not
real fond of -- see below.)
>I mean, think of a Solaris
That's my main objection to devfs... let's see, do I use:
dd if=foo of=/devices/sbus@1f,0/SUNW,fdtwo@f,1400000:c,raw
or
dd if=foo of=/dev/fd0c
(There are more explicitly complicated examples, but that makes the point.)
>Imagine if linux would boot, load all of its modules and stuff, then
>create a link from /dev to everything found in /devfs
>
>maybe rather than /devfs it should be /devices ???
Well, solaris has a well defined driver interface for gathering node
information -- and it _is_ still major/minor number info. The reconfiguration
forceloads every driver to detect all the available hardware -- doing that in
Linux can do very bad things to the system :-)
If you wanted to be a purist, modules need a new function for reporting
devfs information... init_module, delete_module(?), devfs_module? That
certainly fixes one problem (and kills the need for devfsd.)
--Ricky
-
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/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:19 EST