You don't need many devices. You can easily chew up tens of kilobytes
storing *one* ACL.
> > > > > - not having the virtual FS means you don't trap FS events (like inode
> > > > > lookups) which means that you can't do module autoloading, nor can
> > > > > you speculatively create arbitrary namespaces
> > > >
> > > > Certainly you can - on the filesystem. Module autoloading works
> > > > just fine now. This is where device name notification in the module
> > > > files comes into the picture.
> > >
> > > Not if the device node isn't there in the first place.
> >
> > Again, that is where device name notification in the module files
> > come into the picture. What I want to see is depmod, when scanning
> > the repository of available drivers, construct the appropriate /dev
> > tree as well as register which module belongs where, as opposed to
> > requiring complex information in /etc/conf.modules or such.
> >
> > By having the device node in place on the filesystem for at the very
> > least each device present in the system (as opposed to currently in
> > use -- note that in most cases detecting the presence of the device
> > doesn't require the module to be loaded, and those cases that do can
> > be flagged), you ensure that the proper metadata is retained across
> > load and unload.
>
> At the very least, if you have devices that can't be detected without
> loading the module, you would then have to populate /dev based on all
> the possible devices that module could detect. So we're back to /dev
> clutter.
This seems to be a standing issue of yours, yet there is never any
explanation of why this is a bad thing, at least not on the scale we're
currently discussing. I get the feeling that it just looks messy, and
that that offends you. Anyhow, as part of my "supermodule" proposal, I
am trying to separate out probing code for the rather few remaining
busses that need it - non-PnP ISA and what else?
> Then there is the problem with dealing with removable media (where say
> the partition number changes). Do you create all possible partition
> nodes? If yes, more clutter. If no, how do you automatically rescan
> the partition table and build the correct device nodes.
The kernel has to be notified *anyway* when the partition table changes,
so it is perfectly capable of invoking the notification mechanism. Not
an issue.
> Devfs handles these "inconvenient" cases much more cleanly.
No difference.
> > > > > - since you need to store the device tree structure in the kernel
> > > > > anyway (see above), you may as well allow it to be mounted, which
> > > > > gives maximum flexibility to users (and adds very little extra
> > > > > code).
> > > >
> > > > You don't need to store the device tree structure in the kernel.
> > > > You only need to notify with the appropriate iterator, which is a
> > > > much more condensed representation.
> > >
> > > OK, so you save a few pages, but you lose the autoloading and other
> > > features.
> >
> > See above for autoloading.
>
> Which isn't dealt with as cleanly compared to devfs.
I disagree that it is a significant difference.
> > > Assuming you want to store permissions on a per-device entry basis,
> > > rather than storing permissions on a whole class of devices. Devfsd
> > > allows you to have conventional persistence (no tar hack, inode
> > > changes can be stored in real inodes if you like), but also allows a
> > > more compact storage method if you want it.
> >
> > This is a valid point, and I agree this should be a policy decision
> > left up to the user. Presumably one can have a "--delete" argument
> > to devd, or some such.
>
> Sure. And you can use devfs+devfsd in the same way.
Of course. But the point is that I consider devfs to be dead weight
here, and I don't want it *anywhere in my system.*
> > > > > Having devfs in the kernel *absolutely does not* mean that each device
> > > > > driver has to call <devfs_register>. In the early days of the patch,
> > > > > not all the device drivers I use were patched. Nevertheless, my system
> > > > > continued to work.
> > > >
> > > > However, if that means such a device driver is crippled in the
> > > > common configuration, then it's a non-option.
> > >
> > > But it won't be! It won't be any more crippled than with
> > > /proc/device_notifier.
> >
> > The point that I'm trying to make is that having more than one
> > interface that affects everything is not acceptable. I don't want
> > to *prohibit* devfs -- there are clearly applications for which it
> > is useful -- but I also believe it is the wrong thing in general.
> > Therefore, the interface which has to touch everything needs to do
> > both.
>
> But the interface in devfs *does* do both! That's what I've been
> trying to explain. $DEVFS/.devfsd is your notification channel and
> $DEVFS/ shows you the current state. With your approach, you need to
> patch all drivers to call dev_register() in order that devd can know
> about devices. With devfs, you call devfs_register() instead. Both
> schemes provide an API for notification and examining state, but devfs
> provides more information (at very little extra cost) and far more
> flexibility.
>
> As I've said before, I'm comitted to supporting disc-based /dev
> systems with devfs+devfsd. I've actually put work into supporting
> people who want a dynamic, disc-based /dev. Devfsd and the devfsd
> protocol provide this. I'm not trying to force everyone to mount
> devfs on /dev. If people want to mount devfs in /devices or /dev/hw
> and populate /dev using devfsd, I will help them.
But you're still trying to require that the virtual filesystem exists.
You're building your system around devfs, instead around the daemon, or
the interface, which is what I object to. It means you need to expand
all the trees, etc, etc, in kernel space yet. I think we're relatively
close, but not close enough.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private!- 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/