Messages in this thread | | | Date | Wed, 21 Jun 2006 02:07:54 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 00/11] Task watchers: Introduction |
| |
On Wed, 21 Jun 2006 01:35:29 -0700 Matt Helsley <matthltc@us.ibm.com> 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@us.ibm.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |