Re: My $0.02 on devd and devfs

David Lang (dlang@diginsite.com)
Tue, 12 Oct 1999 13:53:38 -0700 (PDT)


a question for Richard on this.

what is the difference between

1. the amount of code needed to maintain the database

2. the current amount of code needed to maintain the database
and provide it as a filesystem.

3. the current database with FS support with an option to display the data
in a flat /proc file instead of mounting it

from what I have read this should be a fairly minor change, but may
satisfy those who dislike a virtual filesystem without sacraficing
existing capabilities.

David Lang

On Mon, 11 Oct 1999, H. Peter Anvin wrote:

> Date: Mon, 11 Oct 1999 11:57:16 -0700
> From: H. Peter Anvin <hpa@transmeta.com>
> To: Richard Gooch <rgooch@ras.ucalgary.ca>
> Cc: linux-kernel@vger.rutgers.edu
> 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/
>

-
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/