On 18 Apr 2000, david parsons wrote:
> Aside from Solaris, which has a devfs gone bad, most of the commercial
That's not a "devfs". It's just an interesting twist to get the driver to
tell you what /dev things to make. It's _all_ in a UFS filesystem. And
if you screw up /devices, you're gonna need the CD. And it will only report
what it knows to exist ("PnP" or static cfg'd) -- solaris doesn't go out
of it's way to find your hardware.
> Unices I've got available have /dev that looks closer to the old Linux
> behavior than the new devfs namespace. And FreeBSD (the only of the
> other free Unices that has survived in my server room) looks, not too
> surprisingly, very close to the old namespace.
Indeed. This "major/minor" number thing has been around for 30 years. There
are many _many_ more OSes that still use it. There have been people much
more intelligent designing UNIX(tm) and UNIX-like systems than us...
Now, I'm the last person to stand in the way of innovation, but you've got
to ask if you're prepared to make linux (incompatablly) unlike anything else
in existance. Perhaps others will eventually adopt the Linux Way (tm), but
it's more likely Linux will be mostly ignored. (see also: mtio.h) And, as
I've said before, there are better ways to handle the device namespace in
lieu of major/minor numbers and the static lookup tables. [no, I've not
attached any source code. And no existing filesystem can hold the data.]
> I've been playing around with automount (actually amd, which was
> written by people who would have trouble documenting how to pay a
> bus driver the US$1.15 to ride the #19 bus into town) and thus
> can't imagine anything more foolish than entrusting the operation
> of the system to this particular magic daemon.
That's a little harsh :-) Autofs has always been a "neat" administrative
hack. IME, it's more of a pain than a benefit -- esp. on Linux. (Small
/opt/ODI snafu [solaris] is etched in my mind.)
> If it's patched so you can only mount it once, then this ceases to
> be a problem; the chroot() jails can try to mount devfs until they
> are blue in their little electronic faces, but devfs will merely
> laugh (mount: devfs already mounted or /dev busy) at the attempts.
But then everything in the chroot() environment fails because your libc
malloc uses an mmap() of /dev/null. Where's /dev/null? (most systems
don't do this anymore.) Actually, /proc is more of a problem for a chroot()
environment.
Dynamic filesystems have their place. However, /dev isn't one of them.
The major/minor "problem" is not an easy thing to fix. Yes, it's a finite
resource. Yes, it's a pain to keep kernel, devices.txt, MAKDEV, and /dev
in sync. Yes, every system has 1000+ unused entries in /dev. Yes, most
filesystems are very inefficient at storing /dev. Changing from 8bit to
16bit would be an even bigger mess -- how many FSen won't hold a 32bit
dev_t? (and no backup system will understand it -- the linux dump/restore
is buggy enough. [Some one _please_ step up to burn the BSD tape and write
a clean linux dump/restore for ext2]) I would add, some experimentation
is present in the kernel tree for 16bit major and minor numbers.
devfs addresses the symptoms, but doesn't fix anything. (I cannot see that
anything _really_ needs to be fixed.) Any time you have a kernel function
coupled to userspace, you're asking for trouble. devfsd is _exactly_ what
kerneld used to be. We abandonded the userspace kerneld due to complexity
and lack of use -- what good's a nuke if you never get to use it?
#include <wheel/reinvent.h>
Let's look at devfs[d]... devfs is only going to populate /dev with the
things drivers have registered with devfs. If the DAC960 driver isn't
loaded then it's devices don't exist. As there are no "nodes" in /dev,
kmod will never get a chance to request something to be loaded (it'd request
block-major-* anyway.) You don't want the DAC960 driver loaded until
something accesses it. Enter devfsd. You add appropriate information to
it's config file so devfs knows what to load and presents "fantom" entries
in it's filesystem. devfs is now doing the job of kmod in the same fashion
the old kerneld did.
HOWEVER, isn't devfs supposed to automagically present a /dev for the hardware
available? This "fantom" feature from devfsd goes against everything devfs
stands for (I'm being factious.) This is called "system administration."
[I know. Linux on the desktop and all that shit... gotta make it easy for
the brainless.]
--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 : Sun Apr 23 2000 - 21:00:14 EST