> > 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.
If the device filesystem was acting *only* as an information source for the
device daemon, it wouldn't need ACLs, or ownership, or permissions (at least,
not settable on a per-device basis). I /thought/ what Richard Gooch was
suggesting -- and it seems I may have been wrong, but I think it's worth
considering -- is:
Export the kernel's hardware/device tree via something devfs like, typically
mounted on /devices on similar. However, the files in this filesystem are
*not* block or char special files. Instead they can be procfs like files that
provide device information (BTW, why are files in procfs not pipes?).
Have some way of poking the device daemon to notify it of changes to that
filesystem -- either something specific to this filesystem, or maybe we create
(or implement an existing) API for getting notifications on directory changes.
The device daemon uses the information gleaned from /devices to do work in
/dev.
I'm not sure how we deal with autoloading of driver modules; it should work
so long as /dev gets populated as soon as devices are attached -- and
presumably your driver/module magic (!) can be used to provide iterators etc.
to dev*d. (Would this always work? How would e.g. new IDE/SCSI devices be
known if the IDE / SCSI subsystem wasn't in use and therefore unloaded?)
-- The light at the end of the tunnel may be an oncoming dragon.- 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/