Re: kexec or similar for FreeBSD
- From: Gleb Kurtsou <gleb.kurtsou@xxxxxxxxx>
- Date: Wed, 22 Jun 2011 10:52:53 +0300
On (21/06/2011 16:05), Warner Losh wrote:
On Jun 21, 2011, at 2:40 PM, Gleb Kurtsou wrote:The project I've mentioned was about implementing a solution similar to
On (16/06/2011 22:35), Russell Cattelan wrote:
On 6/16/11 3:06 PM, Gleb Kurtsou wrote:Yes it's required to be able load device drivers once again. I had to
On (16/06/2011 13:32), Russell Cattelan wrote:What were your goals beyond booting a new kernel? I think getting back
I have been contacted about possibly implementing a fast rebootI was working on similar project some time ago. First of all you have to
mechanism for FreeBSD similar to kexec on Linux.
I have just started looking into how this accomplished so I figured
a note to freebsd hackers would also be a good place to ask
Has anybody looked at doing something like kexec?
leave hardware in known good state for a new kernel. Reseting devices
can be generally accomplished by unloading corresponding kernel modules
(even if they are compiled in kernel). The biggest problem for me was
timers and programmable interrupt controller. I didn't make it work
properly, but my goals where much wider than replacing with another
FreeBSD kernel. Aim was to restore initial BIOS state as much as
to a known BIOS state is kinda required to get a kernel through the boot
process. From what I can tell the main goal of kexec is to avoid the process
of re-initializing the hardware via BIOS.
get back BIOS USB support, both USB HID devices and USB mass storage
access with int 13h. Which is not documented by BIOS vendors. So
decision was made not to boot full OS, but to extend loader and boot
FreeBSD kernel only if necessary rebooting afterwards.
Well, if it is really kexec, wouldn't the kernel be able to use its
drivers to load the stuff, rendering the BIOS state irrelevant? Or
were you kexecing /boot/loader, which would be a lot harder...
kexec-loader, it boots Linux kernel and uses kexec to boot another
loader or Linux kernel. Linux kernel execution starts in real mode(!)
unlike FreeBSD. The project was very different from FreeBSD-kexec I
describe. I'd like to avoid running /boot/loader booting FreeBSD kernel
directly and to use full-fledged OS to load new kernel and modules.
I meant that you can allocate memory and load new kernel and modulesSo it is possible to get back to the loader once the kernel is booted?Is it the right thing to do for FreeBSD. I'm concerned that the wayI find loader code easy work with. You could write dummy filesystem
FreeBSD handles early kernel modules (loaded via the boot loader)
vs linux which does everything via initrd is going to be a problem.
implementation for libstand. So that customized loader will load both
kernel and modules yet while running FreeBSD. Your "reboot" procedure
wouldn't even use any BIOS io interrupts. Linux boot is a real mess
So the running kernel could load the new kernel / modules and then jump
back to the loader to start the boot process.
still while running original FreeBSD kernel, i.e. reuse loader code to
load elf objects, pass boot args to kernel, etc. That would require very
specific memory layout and proper BIOS memory map (SMAP). Unload all
drivers, disable timers and interrupt controller. Then you can start new
kernel directly without going to loader, thus avoiding real mode crap,
finding original boot device BIOS number and boot0+boot altogether.
Yea, what he said :)
I'm not even sure int 13h will always be functional after device was
claimed by FreeBSD driver. It's not the case for USB, ATA should work,
booting from anything else is likely to be a problem.
Yup. Once you're in the kernel, all bets are off on BIOS functions on amd64 (you can't go back to a state where you can call the BIOS without resetting the CPU aka rebooting). Many bets are off on i386.
freebsd-hackers@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"