Messages in this thread | | | Date | Mon, 11 Oct 1999 11:57:16 -0700 | From | "H. Peter Anvin" <> | Subject | Re: My $0.02 on devd and devfs |
| |
Richard Gooch wrote: > > H. Peter Anvin writes: > > Richard Gooch wrote: > > > > > > > > > > > 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. > > > > I disagree. I think it gives you a better framework for doing the > > right thing. > > 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.
You don't need many devices. You can easily chew up tens of kilobytes storing *one* ACL.
> > > > > - 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.
This seems to be a standing issue of yours, yet there is never any explanation of why this is a bad thing, at least not on the scale we're currently discussing. I get the feeling that it just looks messy, and that that offends you. Anyhow, as part of my "supermodule" proposal, I am trying to separate out probing code for the rather few remaining busses that need it - non-PnP ISA and what else?
> 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.
The kernel has to be notified *anyway* when the partition table changes, so it is perfectly capable of invoking the notification mechanism. Not an issue.
> Devfs handles these "inconvenient" cases much more cleanly.
No difference.
> > > > > - 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.
I disagree that it is a significant difference.
> > > 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.
Of course. But the point is that I consider devfs to be dead weight here, and I don't want it *anywhere in my system.*
> > > > > 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.
But you're still trying to require that the virtual filesystem exists. You're building your system around devfs, instead around the daemon, or the interface, which is what I object to. It means you need to expand all the trees, etc, etc, in kernel space yet. I think we're relatively close, but not close enough.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
- 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/
| |