lkml.org 
[lkml]   [2007]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)


    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-04-24 22:45    [W:4.052 / U:0.524 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site