Messages in this thread | | | Date | Mon, 11 Oct 1999 00:13:46 -0600 | From | Richard Gooch <> | Subject | Re: My $0.02 on devd and devfs |
| |
H. Peter Anvin writes: > Richard Gooch wrote: > > OK, we agree that fundamentally, the kernel has to provide device > > availability information in a consistent and coherent manner to > > user-space. Either /proc/device_notifier or devfs can provide > > this. There are two ways that /proc/device_notifier could work: > > > > - it's a true notifier, and doesn't mantain state (i.e. a list of > > what's already there). I see this as totally unworkable because devd > > would then not know about devices found before it starts > > > > - it *does* maintain state, which is then a degenerate case of devfs. > > 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.
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/
| |