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

[Nigel Cunningham]

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: pgp00000.pgp
Description: PGP signature