On Wed, Apr 19, 2000, Ricky Beam <jfbeam@bluetopia.net> wrote:
> > 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.]
major/minor is not required for compatibility with other unices.
If other unices don't abolish major/minor's who cares? They keep using
them, we don't.
> > 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.]
You have a very good understanding of the problems at hand. It's
refreshing to see someone with such clarity in this discussion.
Anyway, there are some other problems that you haven't touched.
USB for instance (yeah, yeah, it's what I'm worried about and most
familiar with).
I need to dynamically create not only nodes for devices, but nodes for
interfaces, etc. One device will have multiple device nodes associated
with it.
In this case, we don't want to create nodes for them "just in case" it
will appear at a later point.
However, it appears there are 2 seperate issues we're running into.
The first is devices which exist, but drivers may not be loaded to
support the device (Your DAC960 example).
For example, I have a floppy drive. We want a /dev/fd0 to exist, but
that will only exist when the driver for the floppy is loaded.
The second issue is for devices which we don't know will exist, and more
importantly, may be different than the previous device which occupied
that name.
For example, I have a USB device with one interface assigned USB id 2.
I unplug it and plug in a new device. This one has two interfaces and is
assigned USB id 2.
USB devices are special in that they will have multiple nodes created
for 1 device.
This may be similar to a SCSI device which may have multiple LUN's.
I don't want to be the System Administrator when a USB device is plugged
in and be required to create the device nodes it requires on demand.
Everyone will say now, "Create all of the device nodes on a real device
filesystem".
Not enough major/minors to do it, or if you come up with cookie system
for major/minors then you've complicated everything beyond anyone could
possibly claim for devfs.
JE
-
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