On Tue, 24 Apr 2007, Pavel Machek wrote:
> >
> > If the code just moved somewhere else, it's not "less code".
>
> It is not "just moved". It is in userspace, where we can use liblzf /
> gcrypt / ( and vbetool for s2ram/s2both) as libraries. We have about
> 7000 LoC of userland code (that is not libraries).
If it's in user land, we also have
- communication difficulties between two parts, and all the *crap* that
tends to entail (ie legacy interfaces forever, and upgrading one
without the other etc)
- people who work on the kernel part are working "blind" (ie they are at
the mercy of whatever userland does, and it's not a "contained"
subsystem). This just ends up becoming worse when you then interact
with ten different versions of the user-land stuff, thanks to small
tweaks by five different vendors, and a hundred random people.
And don't tell me that doesn't happen. Maybe it doesn't happen _now_,
because people who use it all get the patches from one place, but the
moment we start talking about integration into the standard kernel, that
means that the kernel needs to work regardless of whether somebody uses
SuSE, RH, Fedora, Ubuntu or cooked his own distro entirely using some
development version of the suspend user-space tools.
This is why I don't believe in the whole kernel-line-counting thing. I'm
personally 100% convinced that it's better to have ten times as many lines
in the kernel, if it means that you can just forget about version skew and
bad user-space interfaces etc.
So if you want to enumerate "good" points, you'd damn well also face the
_problems_.
This is why there's a lot to be said for
echo mem > /sys/power/state
and being able to follow the path through _one_ object (the kernel) over
trying to figure out the interaction between many different parts with
different versions.
> I believe uswsusp user/kernel separation is clean enough. Kernel
> provides "snapshot image" and "resume image". (Thanks go to Rafael for
> very clean interface).
Now, *that* is the kind of argument that matters.
Quite frankly, if you want to convince me, it's not by "lines of kernel
code", but by talking about easy-to-understand interfaces that actuually
do one thing and do it well (and by "one thing", I mean "one _whole_
thing"). Because I care a lot less about lines of code than about
"maintainable interfaces that people can think about and debug".
I absolutely detest all suspend-to-disk crap. Quite frankly, I hate the
whole thing. I think they've _all_ caused problems for the "true" suspend
(suspend-to-ram), and the last thing I want to see is three or four
different suspend-to-disk implementations. So unlike Ingo, I don't think
"let's just integrate them all side-by-side and maintain them and look who
wins" is really a good idea.
How many different magic ioctl's does the thing introduce? Is it really
just *two* entry-points (and how simple are they, interface-wise), and
nothing else?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
