On Wed, 2006-06-21 at 02:07 -0700, Andrew Morton wrote:
> On Wed, 21 Jun 2006 01:35:29 -0700
> Matt Helsley <[email protected]> wrote:
>
> > On Mon, 2006-06-19 at 03:24 -0700, Andrew Morton wrote:
> > > On Tue, 13 Jun 2006 16:52:01 -0700
> > > Matt Helsley <[email protected]> wrote:
> > >
> > > > Task watchers is a notifier chain that sends notifications to registered
> > > > callers whenever a task forks, execs, changes its [re][ug]id, or exits.
> > >
> > > Seems a reasonable objective - it'll certainly curtail (indeed, reverse)
> > > the ongoing proliferation of little subsystem-specific hooks all over the
> > > core code, will allow us to remove some #includes from core code and should
> > > permit some more things to be loaded as modules.
> > >
> > > But I do wonder if it would have been better to have separate chains for
> > > each of WATCH_TASK_INIT, WATCH_TASK_EXEC, WATCH_TASK_UID, WATCH_TASK_GID,
> > > WATCH_TASK_EXIT. That would reduce the number of elements which need to be
> > > traversed at each event and would eliminate the need for demultiplexing at
> > > each handler.
> >
> > It's a good idea, and should have the advantages you cited. My only
> > concern is that each task watcher would have to (un)register multiple
> > notifier blocks. I expect that in most cases there would only be two.
>
> OK.
>
> > Also, if we apply this to per-task notifiers it would mean that we'd
> > have a 6 raw notifier heads per-task.
>
> hm, that's potentially a problem.
>
> It's a lock and a pointer. 72 bytes in the task_struct. I guess we can
> live with that.
Happily the per-task chains are raw so each should be just a pointer
making the total 24 or 48 bytes (on 32 or 64-bit platforms
respectively).
> An alternatve would be to dynamically allocate it, but that'll hurt code
> which uses the feature, and will be fiddly.
>
> Perhaps six struct notifier_block *'s, which share a lock? Dunno.
>
> > Would you like me to redo the patches as multiple chains?
>
> Well, how about you see how it looks, decide whether this is worth
> pursuing.
OK. Should be interesing.
> It's hard to predict the eventual typical length of these chains.
That's understandable.
> > Alternately,
> > I could produce patches that apply on top of the current set.
>
> It depends on how many of the existing patches are affected. If it's just
> one or two then an increment would be fine. If it's everything then a new
> patchset I guess.
It would affect most of them -- I'd need to change the bits that
register a notifier block. So I'll make a separate series.
Cheers,
-Matt Helsley
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
