Date: Wed, 6 Aug 1997 10:46:32 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jamil@counterintelligence.ml.org (Jamil J. Weatherbee) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, hackers@FreeBSD.ORG Subject: Re: Hot Swappable Kernels Message-ID: <199708061746.KAA14339@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.96.970806004529.266A-100000@counterintelligence.ml.org> from "Jamil J. Weatherbee" at Aug 6, 97 00:56:38 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I know this may sound kind of lame: > > I was thinking last night of what would be required to have a hot > swappable kernel.. i.e. being able to compile the kernel binary (probably) > modules and then insert it into a running system while maintaining its > running status --- to my knowledge kernel recompiles are the only reason a > perfectly rebooting system needs to come down every once in a while. > > 1. The kernel would obviously have to be broken into smaller pieces with > well documented dependencies on any kernel structures. > > 2. Programs that look directly into /kernel would obviously need to be > modernized. > > 3. The kernel installation process would need to have knowledge of any > changed data structures and how to move that data to new structures i.e. > version numbers on kernel data structures. Also device drivers might also > need to be able to do a hot reinitialization. You could not replace code in the paging path without a heavy architectural penalty (ie: copy to real RAM, shut code down, replace the code). If you excepted the paging path, what you describe is pretty much what I want to do. Any device that is not necessary for getting a kernel module replaced can be a replacable kernel module. This means automatic address/io/interrupt space wiring, etc.. These are already a requirement for PNP/PCI/PCMCIA/DOCK hot-swap, which is a stated goal. > The only thing I can think that > might be stubborn are some things like network cards that can be put into > unknown states if not handled properly. Some ISA probes are problematic, as well, since they are destructive. Eventually, all such hardware must be orphaned. > 5. An alternative to making the kernel dynamically sized would be to leave > a margin for hot swaps, like if you know your kernel needs 1.5mb then > reserve 3 of that type of memory for future swaps. At very least most > system calls should be able to be replaced on the fly -- especially > considering that these days it is taking longer and longer for machines to > boot up (you should see the boot time on my micron ppro, I have know Idea > what that thing does for the 2 minutes it sits there booting up) A margin is, or should be, unnecessary in a clean design. The kernel virtual address space can be relocated, as long as it is possible to identify relocation critical code, and leave it alone. This is a very tiny portion of the KVA space. This is the same technique I have suggested to allow post-boot physically contiguous memory range allocation for things like DVD/MPEG/QuickCam drivers. This approach requires the ability to set an attribute on a per page basis as to whether or not it is physically relocatable; this would require that the page attributes be specifiable at the object level, at a minimum -- section attribution, as in ELF/OLF object formats. In addition to relocatability, pages not containing code or data necessary for paging could also be marked pageable, and LRU'ed out, leaving more real memory for user programs. A pageable kernel would drop the FreeBSD memory footprint significantly: it would probably be runnable (though not pretty) in 1M of memory. Or less. The resulting system would *certainly* be higher performance in, for example, a 4M footprint, than the current system. FreeBSD CE for ROM'ing in palmtop computers, anyone? Additional optimizations fall into both the "obvious" and "non-obvious" categories. For example, it's pretty obvious that you could put probe code in a seperate section (assuming sections were page aligned), and discard those pages when the kernel was not actively engaged in probing for hardware. This would let you throw away dirty data pages from the probe process as well, since they may be discarded without damaging the ability of the kernel to reload and use the probe code, or to run following a successful probe. It's less obvious that you could do some things for "lightweight" footprint implements (like the aforementioned FreeBSD CE). For example, you could replace large portions of the kernel drivers with ROM calls to offload the memory footprint into already existing ROM. Etc. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708061746.KAA14339>