Johannes Erdfelt writes:
> On Wed, Jun 07, 2000, Richard Gooch <rgooch@xxxxxxxxxxxxxxx> wrote:
> > Johannes Erdfelt writes:
> > > On an unrelated point, I have a question about changing permissions and
> > > supression.
> > >
> > > I have a module which dynamically tracks permissions for USB devices
> > > and applies them back to the device when it gets plugged back in.
> > >
> > > In the REGISTER handler, I do a chown/chmod pair (well, fchown/fchmod)
> > > which then generates another CHANGE request, causing extra processing
> > > since
> > > it looks like a user (admin, etc) made a change to file, when it was
> > > actually generated by devfsd.
> > >
> > > Would it be possible for devfs (the kernel portion) to not generate
> > > events when the devfsd process (or the process which has .devfsd
> > > open) makes changes?
> >
> > This is possible, but it has a performance impact, since inode changes
> > will then require a test to see if the changing process is devfsd or
> > one of its children. This involves walking up the process tables.
>
> I was thinking of just the devfsd process. Not necessarily any children.
That would require adding yet more code for a different kind of test,
one which only checks for the devfsd process. So I couldn't just call
my existing function.
> > And even if it were free, there's still a problem:
> >
> > > I can't see a reason where it would be needed since devfsd is always
> > > aware of the changes it makes, since it made them in the first
> > > place.
> >
> > That's only really true for devfsd itself. It doesn't know what
> > dynamically loaded extensions or scripts will do.
>
> Dynamically loaded extensions could be handled and scripts would
> be children and not match the check.
I don't see how extensions could be handled, not without imposing some
kind of restriction (i.e. you must call this API to make changes)
that's just prone to failure. People will forget to use devfsd_chmod()
instead of chmod(2).
> Probably too complicated for what it's worth anyway.
Indeed. Also, it would break the idea that devfsd and any scripts it
calls are all equal. This equality is important, because scripts are
written to add functionality that devfsd doesn't have. They should be
viewed as part of devfsd (i.e. same rights and privileges). Breaking
this equality would mean when something migrates from the script to
the devfsd core code, the behaviour is changed. An unwelcome surprise.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|