Mike Castle writes:
> On Tue, Apr 18, 2000 at 09:00:39AM -0600, Richard Gooch wrote:
> > Mike Castle writes:
> > > On Fri, Apr 14, 2000 at 09:36:01PM -0400, Johannes Erdfelt wrote:
> > > > Do you have any other ideas for tracking Hot Swap and Plug and Play
> > > > devices?
> > >
> > > What's wrong with expanding the module stuff to handle this? There
> > > already exists the pre/post stuff for modules. They can do any
> > > arbitrary actions, including setting up permissions and stuff, I
> > > would think.
> >
> > You want to have kernel code reading and writing a database of
> > permissions?!? This sort of thing belongs in user-space.
>
> I thought the stuff for modules was handled in user-space. pre/post
> stuff is really part of that whole thing (and wasn't thinking
> clearly at the time).
Ah, now I see what you were driving at. Instead of having the
permissions in the call to <devfs_register>, have it in an ELF
section, like other module stuff.
> Of course, that's what you're trying to do with the backing file
> system isn't it?
Not really. The ELF section mechanism you propose is like the
permisssions you pass to <devfs_register>: they are hard-wired
defaults. The backing store (however that is implemented) is there to
allow the sysadmin to chmod(2) and chown(2) *later*, and have those
changes be permanent.
> Morever, having the kernel call out to user-space helper programs,
> they can do other things besides save/restore permissions.
Indeed. That's what devfsd does.
> I don't see why the module stuff can't be expanded to handle things
> besides just loading modules. After all, it did USED to, with the
> request-route stuff, that wasn't based upon a module explicitly
> loading/unloading.
There are problems with not using devfsd and using an ELF section in
modules:
- doesn't work for built-in drivers
- you can have a race between when when a module is loaded and when
the permissions are changed.
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/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:15 EST