Re: [patch] let CONFIG_SECCOMP default to n

[andrea@cpushare.com]

On Wed, Jul 12, 2006 at 10:12:15PM -0700, Linus Torvalds wrote:
> You're just in denial, and don't even listen to what people say. It also 
> has nothing to do with cpufreq, which again is a case of _some_ uses may 
> be patented, but not "_the_ use"

You know "_the_ only use" possible of transmeta.o (see the function
init_transmeta) is in connection with the CMS patented software:

	/* Print CMS and CPU revision */
	max = cpuid_eax(0x80860000);

If you can see a difference between transmeta.o and seccomp.o then I
trust you but personally the only difference I can see is that with
seccomp.o it is possible that it will be used for something else
useful too.

I never cared about transmeta.o being linked into my kernels despite I
never happened to need it so far in my life and despite it's larger
than seccomp. I'm happy to spend those hundred bytes in the transmeta
code just in case I would become a transmeta user in the future.

> I just stated that if other interfaces don't have the problem that
> their only use is patent-protected, then other interfaces are
> clearly better alternatives. IF they have users at all.

Obviously you're free to change the kernel the way you want (feel free
to nuke seccomp as well if you want), but I'm also free not to switch
to ptrace if the only reason you give me is sadly non-technical. If
seccomp is better, it is better regardless if the server side is
patent-pending (not patent-protected) or not. So even trusting you
that transmeta.o is fundamentally different from seccomp.o, and it's
all fair as you imply, it still won't make a difference to me since I
only care about technical arguments for my decisions about CPUShare.