[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0710021615520.3579@woody.linux-foundation.org>
Date: Tue, 2 Oct 2007 16:25:55 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Bill Davidsen <davidsen@....com>
cc: Stephen Smalley <sds@...ho.nsa.gov>,
James Morris <jmorris@...ei.org>,
Andrew Morton <akpm@...ux-foundation.org>,
casey@...aufler-ca.com, linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access
Control Kernel
On Tue, 2 Oct 2007, Linus Torvalds wrote:
>
> I don't know who came up with it, or why people continue to feed the
> insane ideas. Why do people think that servers don't care about latency?
> Why do people believe that desktop doesn't have multiple processors or
> through-put intensive loads? Why are people continuing this *idiotic*
> scheduler discussion?
Btw, one thing that is true: while both servers and desktop cares about
latency, it's often easier to *see* the issues on the desktop (or hear
them: audio skipping).
But that doesn't mean that the server people wouldn't care, and it doesn't
mean that scheduling would be "fundamentally different" on servers or the
desktop.
In contrast, security really *is* fundamentally different in different
situations. For example, I find SELinux to be so irrelevant to my usage
that I don't use it at all. I just don't have any other users on my
machine, so the security I care about is in firewalls etc. And that really
*is* fundamentally different from a system that has shell access to its
users. Which in turn is fundamentally different from one that has some
legal reasons why it needs to have a particular kind of security. Which in
turn is fundamentally different from ....
You get the idea.
It boils down to: "scheduling is scheduling", and doesn't really change
apart from the kind of decisions that are required by any scheduler (ie RT
vs non-RT etc). Everybody wants the same thing in the end: low latency for
loads where that matters, high bandwidth for loads where that matters.
It's not a "one user has only one kind of load". Not at all.
Security, on the other hand, very much does depend on the circumstances
and the wishes of the users (or policy-makers). And if we had one module
that everybody would be happy with, I'd not make it pluggable either. But
as it is, we _know_ that's not the case.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists