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/