> > In other words given reboot/trap hooks can kexec happily live
> > as a standalone module ?
You could probably skip the system call to set it up. Example: I could
imagine a bizarre set of pseudo-devices:
# insmod kexec
# cat bzImage > /proc/kexec/next-image
# echo "root=805" > /proc/kexec/next-cmndline
# echo 1 > /proc/kexec/reboot
and hide away that dirty little sequence with a nice kexec(3) library
The Two Kernel Monte trick (that rewrote when insmod'ed the kernel's
function pointers for sys_reboot) was also effective, but that
apparently isn't an option any longer.
> 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.
I'll 2nd that sentiment, and add another big one: fixing (apparent)
problems with drivers and chipset-munging code, so that devices can be
reliably re-probed/re-inited/etc. after the reboot.
Long term, I think it would be advantageous to be able to avoid SCSI and
other time consuming device probes for the common and simple reboot case
of 1) the currently running kernel is being rebooted, and 2) no changes
to the device configuration have occured. Shouldn't we be able to "save
away" what is in sysfs, and then re-inject that state after a fast
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/