Date: Tue, 21 Jun 2011 23:40:52 +0300 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Russell Cattelan <cattelan@thebarn.com> Cc: freebsd-hackers@freebsd.org Subject: Re: kexec or similar for FreeBSD Message-ID: <20110621204052.GA10649@tops> In-Reply-To: <4DFACB99.1030707@thebarn.com> References: <4DFA4C47.8060503@digitalelves.com> <20110616200616.GA67011@tops> <4DFACB99.1030707@thebarn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On (16/06/2011 22:35), Russell Cattelan wrote: > On 6/16/11 3:06 PM, Gleb Kurtsou wrote: > > On (16/06/2011 13:32), Russell Cattelan wrote: > >> I have been contacted about possibly implementing a fast reboot > >> 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 > >> for comments. > >> > >> Has anybody looked at doing something like kexec? > > I was working on similar project some time ago. First of all you have to > > 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 > > possible. > What were your goals beyond booting a new kernel? I think getting back > 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. Yes it's required to be able load device drivers once again. I had to 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. > >> Is it the right thing to do for FreeBSD. I'm concerned that the way > >> FreeBSD handles early kernel modules (loaded via the boot loader) > >> vs linux which does everything via initrd is going to be a problem. > > I find loader code easy work with. You could write dummy filesystem > > 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 > > imho. > > > So it is possible to get back to the loader once the kernel is booted? > So the running kernel could load the new kernel / modules and then jump > back to the loader to start the boot process. I meant that you can allocate memory and load new kernel and modules 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. 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. > > >> Thanks for any help on this. > >> > >> -Russell Cattelan >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110621204052.GA10649>