On Út 25-04-06 16:13:41, David Brownell wrote:
> On Tuesday 25 April 2006 2:41 pm, Pavel Machek wrote:
> 
> > > Well, if we had a pm_should_I_spin_down_drives() it would make sense to me
> > > that it return FALSE during kernel_restart_prepare() too ... surely kexec
> > > users have the same issues!
> > 
> > pm_should_I_spin_down_drives() is incredibly ugly hack, sorry.
> 
> The name was chosen to be ugly.  I'd expect someone to make it prettier;
> maybe draw ponies around the name or somesuch.  ;)

:-).

> However, by the way your pm_message_t changes removed all information about
> system states, you've forced that family of approach in every driver that 
> needs
> to know about such states in order to behave correctly.  For example, "don't
> turn off clock X in PM_STANDBY" ... since no driver has a standard way to know
> about PM_STANDBY, it needs some function accessing state set up by 
> pm_ops.prepare
> or else it's not going to be able to behave right.

Or you can simply adds flags field to pm_message_t.

> You still haven't come up with a response to my point that starting up a
> new kernel via swsusp snapshot resume is a system restart in exactly
> the

After kexec, you hit device-init path, while after swsusp resume, you
hit... well resume(). That's quite different.

> same way as it is for kexec() ... at this point, there is no better fix
> for the problem than my original patch, AND you haven't actually identified
> a single real problem with it.

You identified that problem yourselves: it will break drivers.

Add flags field and be done with it... please?
                                                                Pavel
-- 
Thanks for all the (sleeping) penguins.


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to