Re: [PATCH 00/11] Task watchers: Introduction

[Andrew Morton]

On Wed, 21 Jun 2006 01:35:29 -0700
Matt Helsley <matthltc@xxxxxxxxxx> wrote:

> On Mon, 2006-06-19 at 03:24 -0700, Andrew Morton wrote:
> > On Tue, 13 Jun 2006 16:52:01 -0700
> > Matt Helsley <matthltc@xxxxxxxxxx> 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.

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.

It's hard to predict the eventual typical length of these chains.

> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/