lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 23 Oct 2006 20:06:38 +0200
From:	Pavel Machek <pavel@....cz>
To:	Andrew Morton <akpm@...l.org>
Cc:	rjw@...k.pl, ncunningham@...uxmail.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Freeze bdevs when freezing processes.

Hi!

> > > > > I'm trying to prepare the patches to make swsusp into suspend2.
> > > > 
> > > > Oh, I see.  Please don't do that.
> > > 
> > > Why not?
> > 
> > Last time I checked, suspend2 was 15000 lines of code, including its
> > own plugin system and special user-kernel protocol for drawing
> > progress bar (netlink based). It also did parts of user interface from
> 
> That's different.
> 
> I don't know where these patches are leading, but thus far they look like
> reasonable cleanups and generalisations.  So I suggest we just take them
> one at a time.

Well, some do look okay, but for example this one complicates
freezing... and gains nothing now. It would allow some badly-designed
parts of suspend2 to be merged in future, but I doubt we want them.

> > OTOH, that was half a year ago, but given that uswsusp can now do most
> > of the stuff suspend2 does (and without that 15000 lines of code), I
> > do not think we want to do complete rewrite of swsusp now.
> 
> uswsusp seems like a bad idea to me.  We'd be better off concentrating on a
> simple, clean in-kernel thing which *works*.  Right now the main problems
> with swsusp are that it's slow and that there are driver problems. 
> 
> Fiddling with the top-level interfaces doesn't address either of these core
> problems.

No ammount of changes in kernel/power will fix driver problems, that's right.

> Apparently uswsusp has gained support for S3 while the in-kernel driver
> does not support S3.  That's disappointing.

Well, uswsusp also gained support for compression, splash screen and
RSA-encryption. While S3 support for (kernel) swsusp would be
reasonably easy/non-intrusive, is there a point? I'd really prefer
people wanting to do swsusp+S3 to use uswsusp.

My goal is to keep in-kernel swsusp simple and reliable. fast would be
nice, too. But having all the features is not the goal.

[swsusp+S3 would need some userland support, anyway, because userland
is needed for video card re-initialization. So you'd need utility
similar to s2ram...]
									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 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ