Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

["Rafael J. Wysocki" <rjw@sisk.pl>]

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.

Greetings,
Rafael
-
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/