Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is and how it works.

[Ingo Molnar <mingo@elte.hu>]

* Will Drewry <wad@chromium.org> wrote:

> On Fri, Jul 1, 2011 at 11:10 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> > But that's exactly my point: i consider it the right way forward 
> > because it maximizes kernel utility in the long run.
> 
> Not if it never happens.  Which is what happened with the proposals 
> from Adam and from Eric.

Well, that's what my job is as a maintainer: to tell you if i dislike 
a solution and to suggest better solutions - and here this was really 
easy to do, as you already prototyped a solution i consider (far) 
superior.

I cannot force you to do it like that, but i do have to say 'no'.

> > are not some bad side effect or quirk, they are all generic 
> > improvements we want in any case and not just for sandboxing.
> 
> I didn't say they were bad side effects or quirks.

That's a pretty important point as well.

> > You might not be interested in all of those items, you are only 
> > interested in getting the narrow feature-set you are interested 
> > in, but you sure are interested in getting sandboxing versus not 
> > getting anything at all, right?
> 
> Unfortunately, that isn't the value proposition for me or many 
> other contributors.  The real question is whether I am interested 
> in getting sandboxing in with mainline or if I want to sign up to 
> maintain the patches out of tree until my hair falls out.

Well, if you implement the right solution then why should it stay out 
of tree?

If the code is clean and useful and resolves all the technical 
objections that were raised against it then i will certainly merge it 
- and i hope Linus will chime in if he finds the actual iteration 
unacceptable and the direction harmful, to save us all the trouble.

In the end the 'sandboxing' feature should be a few dozen lines at 
most - all the rest will just be shared infrastructure.

Thanks,

	Ingo