Messages in this thread | | | Subject | Re: [lkcd-devel] Re: What's left over. | From | (Eric W. Biederman) | Date | 09 Nov 2002 20:10:51 -0700 |
| |
Werner Almesberger <wa@almesberger.net> writes: > > But ... I think you're designing too far ahead. The "load kernel on > panic" part isn't trivial, and I think it would be better to tackle > this in a second phase. For now, having a reasonably generic kexec > mechanism would be all that's needed in term of building blocks.
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/
| |