I'm not designing yet, just looking and what I see says that it
does not very much resemble the non panic case.
> > Method 2 (For people with read only roots):
> > - /sbin/delayed_kexec /path/to/new/kernel
> > - Read in the /path/to/new/kernel into anonymous pages
>
> There's no delayed_kexec in kexec-tools 1.4, so let me gues how
> this would work: as far as I know, there's no way for regular
> user space to create a persistent unreferenced memory object, so
> you'd probably load the data, perhaps mlock the pages, and then
> fork a process that keeps the data in memory. Then, this process
> would probably call sys_kexec upon reception of a signal, or
> such.
What I was thinking is that the process would for and exec
something like "/etc/rc 6" or maybe "/etc/rc 7" to be clean.
And that script would do all of the user space shutdown.
No need to mlock any pages, or hack init, or special hacks.
Just user space cleanly shutting itself down.
>
> > I then use the following algorithm to sort the potential mess out
> > before I jump to the new code.
>
> I like this approach. It gives you complete freedom of where to
> load data. This also makes it future-proof. But I don't see the
> reason why you couldn't do the same thing with vmalloc. Using
> vmalloc may actually simplify your code a little.
Mostly it's a bird in the hand versus a bird in the bush. I simply
see nowhere that vmalloc makes my code simpler.
> > Having had time to digest the idea of starting a new kernel on panic
> > I can now make some observations and what I believe it would take to
> > make it as robust as possible.
>
> That pretty much sums it up, yes. But as I've said, this isn't
> really something that needs to be implemented at the same time
> as the basic kexec functionality. A two-phase kexec with
> unrestricted copying capabilities should be a good enough
> building block that only minor changes, if any, would be needed
> when adding kexec-on-panic.
My feel is that kexec-on-panic is a rather different problem. Which
is why I thought it all through, to see if they felt close. At the
very least you almost need to know that it is the same.
>
> > And now I go back to the silly exercise of factoring my code so the
> > new kernel can be kept in locked kernel memory, instead of in a file
> > while the shutdown scripts are run.
>
> Not silly :-)
Except for the part about getting Linus to accept it I don't see
the advantage. kexec-on-panic looks different enough that I don't
think it will help at all with that case.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/