Werner Almesberger <[email protected]> writes:
> [ Re-sent - seems that one of my MTAs got confused and garbled most
> of the addresses. ]
>
> Eric W. Biederman wrote:
> > - This code needs to sit in a development tree for a little while
> > to shake out whatever bugs still linger from my massive refactoring.
>
> I think there will be plenty of driver issues to address. However,
> pretty much all alternatives to kexec-based crash dumps (minus the
> firmware-based ones that reset everything but memory, of course)
> will suffer from the same problems - they may just be a little
> better at not noticing them.
Doubtless. So far I only have 1 e1000 driver issue. The IBM guys
were tracking an issue with one of the aic7xxx cards. But those kinds
of issues seem to be fairly rare right now :)
> > In the interests of full disclosure my main interesting is using the
> > kernel as a bootloader for other kernels
>
> Me too :-) I'm a bit concerned that kexec has been hovering outside
> the mainline kernel for so long. This keeps the threshold for new
> work on the boot process high, delaying experiments and, ultimately,
> progress.
To some extent. It is worth noting that the first 13 of my patches
are not core functionality they are bug fixes or feature enhancements
of code that simply have come to be associated with the work on kexec.
Which is why I put them first in the list of things so it is clear
they don't depend on the core kexec code. So some work in that
area seems to be happening and from what I have heard about ppc64
kexec support has been a motivating reason to clean up their boot
process some more.
The nice thing at this point I think one more cycle through the
development process and we should have a fairly well defined and
working mechanism for taking crash dumps. With the remaining work
left simply to porting it.
Eric
Eric W. Biederman wrote:
> To some extent. It is worth noting that the first 13 of my patches
> are not core functionality they are bug fixes or feature enhancements
> of code that simply have come to be associated with the work on kexec.
Good point. I didn't even think of the low-level parts of the boot
process. I'm more worried about the high-level side. Since GRUB,
not much seems to have happened. I think we should have a much
richer boot environment by now.
We're still not even at the level of functionality typically found
in the boot PROMs of classical Unix workstations, whereas I think
we should have been running circles around them for years already.
So if there was a vote to be cast for getting kexec into mainline
as quickly as possible, you'd certainly have mine :-)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/
Werner Almesberger <[email protected]> writes:
> So if there was a vote to be cast for getting kexec into mainline
> as quickly as possible, you'd certainly have mine :-)
The hard one there is support of arbitrary OS's. Most
of the existing interfaces that have been designed require callbacks
during booting which is the hard piece to support in a linux based
environment.
But loadlin does fairly strongly show that you can do interesting
things to load a non-native OS if you have the appropriate
environment.
I think part of the challenge is the conversation on what should
happen with bootloaders is fragmented. But that may not be
a bad thing. Most people want to implement simple boot policies,
and really don't care for the full complexity that some firmware
solutions allow. So what I have seen is people will take kexec
and implement their custom policy instead of doing something complex.
With 1MB ROMS starting to show up it using a kernel based bootloader
is starting to look like a real possibility on the LinuxBIOS front.
There is also the other use case that I have a use for as well.
Kernel upgrades. I need to get my patch into /sbin/reboot or
at least the initscripts but the ability to easily switch from
one kernel to another without going through the firmware is also
very handy. That case is the core case has been my motivating
factor lately.
And at this point the question is really not about getting
kexec into the mainline. Andrew picking it up, the syscall number
being reserved, and interface being fixed have done that. The goal
now is to build enough confidence so that we can move from the
development to the stable kernel.
Want to help?
Eric
Eric W. Biederman wrote:
> The hard one there is support of arbitrary OS's.
Bah, couldn't care less :-) If all else fails, you can fall back
to the "old-style" boot loader, and let this one boot the legacy
OS. (Well, for GRUB, you'd need the fallback extension, if this
isn't a standard feature yet.)
> Most people want to implement simple boot policies,
> and really don't care for the full complexity that some firmware
> solutions allow. So what I have seen is people will take kexec
> and implement their custom policy instead of doing something complex.
I think many of them would just be as happy with a more complex
solution, as long as it comes in a nice bundle. Of course, if
there is no nice package to start from, they'll only implement
the bare minimum.
Also, in most cases, we can probably ignore space issues for now,
leave some room for experiments, and optimize later.
> The goal
> now is to build enough confidence so that we can move from the
> development to the stable kernel.
Yes, that's what I mean with it being in "mainline". For user
space to begin making use of kexec, it really should be part of
a kernel most people can accept for regular use.
> Want to help?
Trying to, by explaining why it should move on :-) Anything else
you need ?
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina [email protected] /
/_http://www.almesberger.net/____________________________________________/