On Wed, Apr 12, 2000 at 03:14:23PM -0400, Ricky Beam wrote:
> 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...
I'm "on the fence". It makes my life simpler with things like the
device drivers I work on (getting them to show up in /dev - the Computone
Multiport drivers can create 520 separate devices when fully loaded) but
there are a lot of gotcha's where the fix (like taring up devices to
preserve permissions and symlinks at boot and halt) is just a butt-ugly
kludge.
> >> 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.
Are you sure about that? For some reason, I was under the impression
that a special file (block or char device) didn't occupy any FS blocks. I
thought it just occupied a directory entry and an inode and all the
information was stored there in. If it DOES occupy an FS block, then
du is lying through it's teeth.
] [root@alcove linux]# du /dev
] 12 /dev/ida
] 0 /dev/pts
] 33 /dev/rd
] 108 /dev
If there's one FS block per special file, there should be thousands
of blocks tied up in that directory. I've got almost 2300 entries in /dev.
If I'm wrong, someone needs to fix du and I've got to correct my thinking
(won't be the first time - won't be the last time).
> 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
Come on now. Solaris royally sucked if you went to the /devices
directory but it only mildly sucked if you went to the /dev directory
where the conventional symlinks existed. You could also still create
non-volatile directories, finer structures, and attributes in /dev that
didn't get toasted on reboot, like they do with devfs. I had applications
which stored device specific named pipes in /dev/ subdirectories on Solaris
with ownerships and permissions that were non-volatile over a reboot.
> (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 ???
/devfs is fine with me, but I though the $#@$# thing booted on
/dev. In fact, a check of 2.3.99-pre5 confirms it. It's not overlaying
/devfs, it's going over /dev unless you tell lilo append="devfs=nomount"
and then mount devfs on /devfs yourself in /etc/fstab (which is exactly
what I'm doing right now).
> 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 :-)
Oh God... The mind boggles at the thought. :-) Giggle...
> 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.)
Bizzzt... Wrong answer. Actually, it's a great idea and I wish it
would solve the problem. Unfortunately, it doesn't solve the problem for
USB, PCMCIA, Firewire, hot-swappable SCSI, hot-swappable IDE, or any other
thing (the list goes on and on) where devices may come and go while the
drivers remain in core. I think resource management is one of the newer
features we are suppose to be cheering in the 2.4 kernel, right? While
devfs better damn well not be REQUIRED for anything or to get the
resource management to behave correctly, it does have it's points,
especially in this area.
Now if there were only a CLEAN solution to the non-volatile
attributes problem. Set permissions and ownership of a device. Device
goes away. Device returns. Permissions and ownership are not what
they were. You're screwed. Game over. Could be a real problem with
USB and paraport devices. That applies to reboots (where the tar kludge
could be used) and for transient devices like USB. I guess one could cobble
up some command execution from devfsd every time a device comes and goes,
but that sucks even harder. Richard suggests, in the devfs README file,
"for the paranoid, you can save your permissions periodically using a
cron job" but I suggest that spells "timing window" and takes "butt-ugly
kludges" to the level of "periodic and repetative butt-ugly kludges".
I've looked over the modules.conf stuff and kmod stuff and devfsd
stuff in those files as well. I haven't tried to get that haywired together
to work with the catch-22 associated with opening devices than don't even
exist until loaded and won't get loaded until opened. Looks like it might
work (probably will when set up right) but also looks like yet more
overloading on devfsd which is looking more like kerneld in it's position
in the world.
> --Ricky
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!- 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