* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote: > > I think the sanest semantics is to run all active callbacks as well. > > > > For example if this is used for three stacked security policies - as if 3 LSM > > modules were stacked at once. We'd call all three, and we'd determine that at > > least one failed - and we'd return a failure. > > But that only works for boolean functions where you can return the > multi-bit-or of the result. What if you need to return the specific > error code. Do you mean that one filter returns -EINVAL while the other -EACCES? Seems like a non-problem to me, we'd return the first nonzero value. > Also, there's bound to be other cases where people will want to employ > this, look at all the various notifier chain muck we've got, it already > deals with much of this -- simply because users need it. Do you mean it would be easy to abuse it? What kind of abuse are you most worried about? > Then there's the whole indirection argument, if you don't need > indirection, its often better to not use it, I myself much prefer code > to look like: > > foo1(bar); > foo2(bar); > foo3(bar); > > Than: > > foo_notifier(bar); > > Simply because its much clearer who all are involved without me having > to grep around to see who registers for foo_notifier and wth they do > with it. It also makes it much harder to sneak in another user, whereas > its nearly impossible to find new notifier users. > > Its also much faster, no extra memory accesses, no indirect function > calls, no other muck. But i suspect this question has been settled, given the fact that even pure observer events need and already process a chain of events? Am i missing something about your argument? Thanks, Ingo
