I disagree. I think it gives you a better framework for doing the right
thing.
> > > So a stateful /proc/device_notifier could work. But I think devfs is
> > > a better approach, because:
> > >
> > > - it does not require the daemon to parse a file to work out what
> > > devices are present. A filesystem is a natural way to present a tree
> > > structure; a file is not. Devfs is moving towards a structure that
> > > also reflects the physical topology of the hardware (i.e. bus# and
> > > slot# will appear in device paths), which will reinforce this point
> >
> > A kernel filesystem, however, requires that the iterators are
> > expanded! This is the fundamental problem. You end up storing
> > potentially limitless amounts of data in your kernel, especially
> > when you want to add ACLs to your devices.
>
> 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.
> > > - 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.
> > > - 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.
> > > > * devd should not *delete* devices in normal operation, unless they
> > > > have been superceded. Deleting device nodes is generally a
> > > > destructive operation.
> > >
> > > Well, I don't agree, but that's a policy issue that the user can
> > > decide.
> >
> > The reason is that deleting such a device node destroys any metadata
> > associated with that device node. This is destruction of
> > information, and should not be taken lightly.
>
> 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.
> > > > Notice that this interface would *also* be usable for devfs (which
> > > > would have to include all the various iterators etc in kernel space,
> > > > but it would have to anyway), which makes devfs an optional,
> > > > isolated feature. This is a Good Thing: I don't have anything
> > > > against devfs as an *isolated* feature for the people who want to
> > > > use it (lazy/careless admins, embedded systems...) I *do* have a
> > > > problem with it becoming ubiquitous, and I do have a problem with it
> > > > being a requirement for each device driver. However, with this
> > > > configuration devd would effectively be the "standard" mode of
> > > > operation, and devfs would be an "alternate", using the same
> > > > interfaces.
> > >
> > > 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.
-hpa
-
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/