Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)

Linus Torvalds
2007-04-24T20:43:06Z

On Tue, 24 Apr 2007, Pavel Machek wrote:
>
> Well, current uswsusp code can do most of stuff suspend2 can do, with
> 20% (or so) of kernel code.

Btw, this is a totally inane argument.

If the code just moved somewhere else, it's not "less code".

You compare complete subsystems against complete subsystems, OR YOU DON'T
COMPARE THEM AT ALL!

This whole notion that "kernel lines of code" is somehow different is a
stupid and idiotic _disease_ that is spread by microkernel people and
people who have been brainwashed by them.

Code is code, and sometimes it's better in the kernel, sometimes it's
better in user space, and you cannot say "we only have 10 lines of kernel
code", if that is then combined with a million lines of user space code
that actually is the only reason for the 10 lines of code in the first
place.

Separation of code often makes things *harder* to understand and debug. A
few prime examples of this f*cking idiotic stupid disease of discounting
user level code because it somehow "doesn't matter" is:

- the old 16-bit pcmcia layer that did all the "policy" in user space,
and only the "device access" in kernel space, and as a result _neither_
actually knew what the hell they were actually doing, and debugging was
a nightmare.

We've become a *lot* better off with a device layer that actually knows
and understands what it is doing, and having the code in one place,
rather than having two broken pieces.

And we became better exactly by doing *more* in the kernel, and havign
a *higher* level of abstraction. This is a BIG ISSUE. Abstraction is
good, but abstraction is good only if it is at a high enough level to
make sense and matter, and give the abstraction level a choice in how
to implement the lower layers.

- the old module loader was also split into user/kernel space, and yes,
we made the kernel part "larger" by moving some parts into the kernel,
but in doing so, we actually made the *combined* code smaller, and a
hell of a lot more maintainable.

It also automatically (again, because of a higher level of abstraction)
meant that the new module loader infrastructure was not only more
maintainable, but could actually *do* more. Suddenly you can do things
like check for cryptographic signatures etc, because you know what
you're actually doing, as opposed to getting a ready-made "binary blob"
that you don't know anything about, that has been pre-linked etc.

So stop blathering about "less kernel code". That's the *least* of any
worries. The only thing that matters is the end result, and trying to say
that magically only one part counts is just dishonest and stupid.

In general, the kernel should be self-sufficient and *understand* what it
is doing. If the kernel cannot understand the bigger picture, nobody can
ever maintain the kernel, because the kernel is just a broken piece
bobbing around in a mindless churning sea during a thunderstorm. You
cannot have purpose, and you cannot improve yourself if you don't actyally
understand your lot in life. That's as true of kernels as it is of people.

User-space should set high-level policy, but if the kernel doesn't know
what it's all about, the kernel can never do anything smarter and can
never *fix* itself. That was the case in both PCMCIA and in kernel module
loaders.

I have not a frigging clue whether that is the case in suspend2 vs
uswsusp, but I object to this idiotic argument of counting "kernel code".
That's simply not a valid argument. It never was.

Linus