Hi!
> > > > So what Pavel wants can be
> > > > translated as 'please use already merged code, it can already do what
> > > > you want without further changing kernel'.
> > >
> > > Like we'd want to use unreviewed, extremely new and risky code for
> > > something that happily destroy filesystems.
> >
> > You can either use suspend2 (14000 lines of unreviewed kernel code,
> > old) or uswsusp (~500 lines of reviewed kernel code, ~2000 lines of
> > unreviewed userspace code, new).
>
> I was going to keep quiet, but I have to say this: If Suspend2 can rightly be
> called unreviewed code, it's only because you've been too busy flaming etc to
> give it serious review. Personally, though, I don't think it's right
I really looked at suspend2 hard, year or so ago, when I was pretty
tired of the flamewars. At that point I decided it is way too big to
be acceptable to mainline, and got that crazy idea about uswsusp, that
surprisingly worked out at the end.
uswsusp makes suspend2 obsolete, and suspend2 now looks
misdesigned. It puts too much stuff into the kernel, you know that
already.
>From your point of view, uswsusp is misdesigned, too. It is too damn
hard to install. There's no way it could survive as a standalone patch
-- the way suspend2 survives. Fortunately, from distro point of view,
being hard to install does not matter that much. Distros already have
their own initrds, etc. And in the long term, distros matter, and I'm
quite confident I can make 90% distributions ship uswsusp + its
userland; cleaner kernel code matters, too, and maybe you'll agree
that if you only look at the kernel parts, uswsusp looks nicer.
Now, you are asking me to review 14000 lines of code. That's quite a
lot of code, and you did not exactly make reviewer's life easy. Also
reviews usually stop at first "fatal" problem, and you still drive
user interface from kernel. (Yes, drawing is done in userland, but
core user interface code is still in kernel). That is "fatal".
(Greg mentioned /proc usage being "fatal", too).
Now... moving user interface into userland, and removing /proc usage
are big tasks, do you agree? And they will mean lot of changes, and
lot of new testing.
Perhaps at this point right solution is to just drop suspend2
codebase, and do it again, this time in userland? Kernel
infrastructure is already there, and even if you wanted to replace
[u]swsusp by suspend2, you have to understand how the old code
works. (Another point you may like is that forking suspend.sf.net code
is relatively easy; so even if we disagree about coding style of the
userland parts, I can't veto it or something. And given that your only
problem is including all the possible features, I probably will not
have reason to stop you or something -- having all the features is
okay in userland).
Now... switching to uswsusp kernel parts will make it slightly harder
to install in the short term (messing with initrd). OTOH there's at
least _chance_ to get to the point where suspend "just works" in
Linux, in the long term...
(Of course, you can just ignore this and keep maintaining out-of-tree
suspend2. We'll also get to the point where it "just works"... it will
just take a little longer.)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
