I disagree. You lose information with your scheme, so you have to hack
around that (for example the special flagging you mention below).
> > It really isn't that much information. And if you really do have
> > thousands of devices, then you can spare a few extra pages. But
> > perhaps ACL's can be kept in devfsd rather than devfs. I'm still
> > hoping for a good framework for ACL's to appear in the VFS.
>
> That would be hideously expensive, since you're effectively
> proposing a user-space callout for each *use* of a device. This
> doesn't seem reasonable.
I'm not actually proposing that. I'm just saying we'd have a choice.
Personally, I think having the ACL's in devfs is fine. It really
wouldn't take much space. As I've said before, systems with thousands
of devices will have plenty of RAM.
> > > > - 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.
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.
Devfs handles these "inconvenient" cases much more cleanly.
> > > > - 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.
> > 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.
> > > > 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.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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/