Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

On Friday, 13 July 2007 20:15, Alan Stern wrote:

On Fri, 13 Jul 2007, Eric W. Biederman wrote:

quoted

quoted

I doubt that re-probing devices will work.  The probe routine won't 
expect there to be any registered children, so it will try to 
re-register them.

So really unregister the children.  All we really need to do is disassociate
the drivers from the devices (to reuse the existing code) we don't
need to rescan for the devices.  The associating the device drivers
with devices takes human measurable amount of time.  The only thing
that takes time is waiting on hardware.  Maybe things will suck
and associating the drivers with the device tree with take a whole
second on a bad day, I don't think that is enough time to add
complicated new code paths for the drivers to maintain.

This would be even worse!

Suppose you unbind (or unregister, either way) a disk driver.  It's 
unbind method will unregister the gendisk structure, thereby deleting 
all the partitions and block devices associated with the disk.  This 
will leave any and all memory mappings dangling in the breeze.  When 
the kernel resumes from hibernation, nothing will work.

quoted

quoted

On the other hand, post_restore methods could be written to expect 
something like this.

Please Please Plaese do not start with the existing software suspend
to disk code and thinking.

Ha!  Gotcha.  You evidently haven't been reading the linux-pm mailing 
list for the last few months.  :-)

     1. post_restore isn't "existing software suspend to disk code"
	(you're supposed to call it "hibernation" now, BTW).

     2. post_restore isn't new.  It has already been proposed and
	generally accepted.  It is part of the movement to untangle
	and separate the suspend and hibernate code paths.

     3. post_restore hasn't been implemented yet.  It's barely past
	the proposal stage.

     4. Maybe _you_ like to discuss complicated issues such as this
	one without thinking, but the rest of us prefer a little 
	cerebration.

quoted

 We are not implementing suspend to ram
here or anything like it.

One of the topics in this discussion has been "suspend-to-both", which
includes suspend-to-RAM.  

But anyway, so what?  I wasn't talking about suspend-to-RAM; I was
talking about hibernation.

quoted

 We already have proven code paths that
know how to quiesce hardware.  We already have proven code paths
that know how to take quite hardware and make it run.  Please let's
just use them.  At least until we can see that they are insufficient
to the task.

Was this request directed at me or at Rafael?  It's hard to tell.

Yeah.

Anyway, IMO, unregistering of devices in the hibernated kernel won't work,
because it doesn't know how to register them back after the restore.  Sure,
we can teach it do do that, but I think it's simpler to just keep devices
registered and have a .post_restore() or .reprobe() callbacks for handling
the reinitialization of hardware.

And yes, we've discussed this in detail for many times on linux-pm.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth