Hi. On Wednesday 08 February 2006 01:09, Rafael J. Wysocki wrote: > Hi, > > On Tuesday 07 February 2006 02:05, Nigel Cunningham wrote: > > On Tuesday 07 February 2006 10:44, Pavel Machek wrote: > > > Are you Max Dubois, second incarnation or what? > > > > > > > Well, given that the kernel suspend is going to be kept for a while, > > > > wouldn't it be better if it was feature full? How would the users be > > > > at > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > a disadvantage if they had better kernel based suspend for a while, > > > > > > ~~~~~~~~~~~~~~~~ > > > > > > > followed by u-beaut-cooks-cleans-and-washes uswsusp? That's the part I > > > > don't get... > > > > > > *Users* would not be at disadvantage, but, surprise, there's one thing > > > more important than users. Thats developers, and I can guarantee you > > > that merging 14K lines of code just to delete them half a year later > > > would drive them crazy. > > > > It would more be an ever-changing interface that would drive them crazy. So > > why don't we come up with an agreed method of starting a suspend and > > starting a resume that they can use, without worrying about whether > > they're getting swsusp, uswsusp or Suspend2? /sys/power/state seems the > > obvious choice for this. An additional /sys entry could perhaps be used to > > modify which implementation is used when you echo disk > /sys/power/state > > - something like > > > > # cat /sys/power/disk_method > > swsusp uswsusp suspend2 > > # echo uswsusp > /sys/power/disk_method > > # echo > /sys/power/state > > > > Is there a big problem with that, which I've missed? > > Userland suspend is driven by the suspending application which only calls > the kernel to do things it cannot do itself, like freezing (the other) > processes, snapshotting the system etc. We use the /dev/snapshot > device and the ioctl()s in there, so no sysfs files are needed for that. > It's independent and can coexist with the existing sysfs interface > just fine. Yes, but how are you going to get it started from (say) klaptop, which only knows "echo disk > /sys/power/state" as the way of starting a suspend? I'm suggesting that we create a means whereby the issue of how to start a cycle could be separated from what implementation is used to do the work. That is, a simple extension at the start of the disk specific code that starts swsusp, uswsusp or suspend2 depending upon what you want. Maybe I should just prepare a patch. Regards, Nigel -- See our web page for Howtos, FAQs, the Wiki and mailing list info. http://www.suspend2.net IRC: #suspend2 on Freenode
Attachment:
pgpIUSFWfB8tm.pgp
Description: PGP signature
- Follow-Ups:
- References:
- [ 00/10] [Suspend2] Modules support.
- From: Nigel Cunningham <[email protected]>
- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- From: Nigel Cunningham <[email protected]>
- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- From: "Rafael J. Wysocki" <[email protected]>
- [ 00/10] [Suspend2] Modules support.
- Prev by Date: [PATCH] Complain if driver reenables interrupts during drivers_[suspend|resume] & re-disable
- Next by Date: Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- Previous by thread: Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- Next by thread: Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)
- Index(es):
 |