Actually, it works as a true notifier if equipped with a buffer (which
only needs to be allocated when nonempty, which will not be the
steady-state configuration.) This would actually be my preferred
choice.
> 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.
> - 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.
> - 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.
> /proc/device_notifier is a functional subset of devfs, but prohibits
> users to make the choice to have a virtual /dev. As I've said time and
> again, devfs gives *choice*. People can not use it at all, or mount it
> elsewhere and use devfsd to manage a disc-based /dev. Despite (often
> offensive) claims to the contrary, devfs won't stop people from
> maintaining their traditions.
>
> > * 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.
> > 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.
-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/