OK, that's an improvement. But I still think it's a poor-man's
substitute.
> > 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.
> > - 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.
> > - 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.
> > > * 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.
> > > 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.
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/