Cc: Andrew Morton <akpm@...>, <nigel@...>, Pavel Machek <pavel@...>, Huang, Ying <ying.huang@...>, Jeremy Maitin-Shepard <jbms@...>, <linux-kernel@...>, <linux-pm@...>, Kexec Mailing List <kexec@...>
There needs to be an implementation of hibernation based on kexec with
return yes.
That interface should be running kernel -> user space -> target kernel.
Not direct kernel to kernel.
initramfs. We already seem to have that interface. And distros
seems to do a pretty decent job of using it to configure systems.
Yes.
Not to be callous but that really is a user space and distro issue.
I agree. I'm still not quite convinced it will do a satisfactory job.
But I think it does make sense to implement a general kexec with
return and see if that can reasonably be used for handling hibernation
issues. If done cleanly and with care the implementation won't be
hibernation specific.
Frankly this looks like the best way I can see to implement a general
mechanism for calling silly firmware/BIOS/EFI services after we
have a kernel up and running. It's a little bit like allowing
X to call iopl(3) and do inb/outb directly.
The configuration issues you raise pretty much exist for kexec on
panic, and they seem to be being resolved for that case in a
reasonable way. I do agree that the current kexec+return effort seems
to be one of those unfortunate cases where we give every mechanism in
the kernel to do something in user space and then no one actually
implements the user space. That doesn't do any one any good.
For hibernation we don't have the absolute need to step outside of the
current kernel that we do in the kexec on panic approach. However we
have this practical fight about mechanism and policy, and kexec with
return has this seductive allure that it appears to be the minimal
necessary mechanism in the kernel.
No one has yet attacked the hard problem of coming up with separate
hibernate methods for drivers. This should be the hard part of the
puzzle, and the recurring work from a kernel maintenance point of
view. There is some reason to hope that things will be a maintenance
will be a little simpler because you can get at all of the distinct
pieces of the puzzle.
Currently kexec with return appears to require the minimal amount of
mechanism in the kernel and leaves the policy to someplace else, plus
the code is not hibernation specific. We could use it to make runtime
EFI calls, or to implement cooperative multitasking between kernels.
My current opinion is that the patches are starting to get close
enough that it isn't a waste of my time reviewing them. But there
is still a fair amount to be done before this code is in shape for
us to merge it into the kernel.
At 500 or so lines I don't feel bad about pushing back until all of
the core user interface issues are resolved, and we have the code
calling the proper driver methods.
Eric
-
