Bug#474648: please re-enable CONFIG_SECCOMP, it's harmless (and needed)

[Sam Hocevar <sam@zoy.org>]

On Mon, Apr 07, 2008, maximilian attems wrote:
> On Mon, Apr 07, 2008 at 12:47:56AM +0200, Sam Hocevar wrote:
> > 
> > CONFIG_SECCOMP was disabled for performance reasons, but it has always
> > been harmless. Quoting the author:
> > 
> >  | On x86-64 SECCOMP generates absoutely zero performance hit.
> >  | 
> >  | The original seccomp patch for x86 also generated absolutely zero
> >  | performance hit, both pratically and theoretically too. _zero_ CPU
> >  | cycles of difference, zero cachelines.
> > 
> >  (From http://marc.info/?l=linux-kernel&m=115235061904105)
> 
> that's pretty wrong.
> it had a hit on each context switch.

   Okay, but I'm not asking for CONFIG_SECCOMP_DISABLE_TSC, just
CONFIG_SECCOMP, which is completely harmless (unless you can tell me
where the harm is).

> > Please re-enable this feature. It is needed for CPUShare (see #417130).
> 
> no.
> that is a commercial entity, no need to push that.

   CPUShare is not a commercial entity, it is a piece of software I
use and package and is unfortunately non-functional on Debian systems
because CONFIG_SECCOMP is disabled.

   I see no reason for deliberately diverging from the upstream kernel
for political reasons that have nothing to do with our social contract
(and probably violate 4.).

> unless something substantial comes up that bug can be close right away.

   Wow, thanks for listening to the users.

Regards,
-- 
Sam.