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.
