Alan Cox wrote:
> Let me ask the same dumb question - what does kexec need that a dumper
> doesn't.
kexec needs:
- a system call to set it up
- a way to silence devices (difference to dumper: kexec normally
operates under an intact system, so it's more similar to, say,
swsusp. But I expect that cleaning up device power management
would also clear the path for more reliable dumpers.)
- a bit of glue, e.g. to switch to "real mode", etc. AFAIK, none
of this touches other code, but there are of course some
assumptions here on what other codes provides or does.
- device drivers that can bring silent devices back to life
(normally, device drivers do this already, but kexec may
uncover dormant bugs in this area)
Since recent kernels already preserve memory areas with BIOS data,
kexec is actually quite a bit less intrusive than bootimg was.
> In other words given reboot/trap hooks can kexec happily live
> as a standalone module ?
"Module", as in "software package": yes, the main problem spot
would be the system call allocation, which is also inconvenient
for other developers. By the way, kexec does not tap into the
kernel's reboot process, so no such hooks are needed. If LKCD
wants to use kexec, it can do whatever it does to be invoked at
the time of a crash, and then call kexec directly.
"Module", as in "loadable kernel module": I think so, although
it's currently "bool", not "tristate". Also, you'd have the
system call issue again.
So not merging it is mainly inconvenient to use, adds the system
call allocation as a continuous annoyance, and makes it a little
harder to work on the related infrastructure. But then, despite
being somewhat obscure, bootimg and kexec have been in use for
years, the design is about as lean as it can get, and it's cool.
What more could you ask for ? :-)
What kexec needs now is more exposure, so that the BIOS
compatibility issues get noticed and fixed, it is ported to other
architectures, and that more people can start figuring out how to
use it, and how to build a boot environment. Then, maybe in a
year or two, we can send "Methuselah" LILO and "nice little OS"
GRUB off to their well-deserved retirement.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ - 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/
This archive was generated by hypermail 2b29 : Thu Nov 07 2002 - 22:00:39 EST