Date: Wed, 6 Aug 1997 00:56:38 -0700 (PDT) From: "Jamil J. Weatherbee" <jamil@counterintelligence.ml.org> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: Terry Lambert <terry@lambert.org>, hackers@FreeBSD.ORG Subject: Hot Swappable Kernels Message-ID: <Pine.BSF.3.96.970806004529.266A-100000@counterintelligence.ml.org> In-Reply-To: <199708060133.LAA01644@genesis.atrad.adelaide.edu.au>
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. I know that such a thing is entirely possible -- it is just a matter of software --- the only time a machine needs to reboot these days is when a piece of hardware fails or needs to be installed --- but there are solutions even for that as you well know. 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. 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) On Wed, 6 Aug 1997, Michael Smith wrote: > Terry Lambert stands accused of saying: > > > Do I take it that nobody has actually looked at the registry code > > > (documented, commented for Steven's delectation) that I mentioned > > > last week? > ... > > I saw the announcement, but have not grabbed the code. > > > > Do you have a higher level architectural overview? > > Not on paper, no. To put it very simplisitically : > > Intent: > - To provide a uniform, managed namespace for in-kernel data resources. > - To address some of the shortcomings of the sysctl mechanism, most > particularly support for more complex datatypes and method-based > access. > > Principal consumers: > - Parameter-hungry subsystems (PCI, PnP, PCCARD, network interfaces, etc.) > - User-space applications wishing to access/manipulate kernel-private > data. > > Structure: > - We have a period-delimited hierarchical namespace, with support for > lookup by name or by oid (for sysctl compatability). > - Nodes within the namespace may have attached access methods. > - Access methods are keyed by name/type, requested data type, etc., > ie. a node may have a number of access methods. > - Support is implicit for single values, arrays and pointers, as well > as methods that have no data per se. > > > For example, are you doing kernel level file I/O to implement the > > thing? > > No. At this point, I haven't gone so far as to support marking > individual nodes or methods as pageable or otherwise; if this becomes > desirable, the correct way to implement it would be with pageable > kernel memory IMHO. There are issues related to tree/chain transit as > well with pageable registry entries that I didn't want to get involved > with at this stage. > > > I've personally been working on Win95/NT style registry API's at the > > kernel level (a necessary step to support use of Win32 Ring 0 drivers > > in FreeBSD), so I've basically ignored code-level reviews of such things. > > Fair enough. I would be interested to know what sort of infrastructure > support that kind of API would require. > > > My personal preference is an LDAP database accessable from user or > > kernel space, or remotely via an LDAPd. I have not seriously pursued > > this because of the (apparent) NDBM requirements. > > Whilst LDAP is quite a desirable goal to pursue, the principal thrust > of this code is to address parameter management for subsystems which > lie too low down for LDAP lookup to be useful, eg. drivers, > fundamental network configuration, etc. > > -- > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ > ]] Genesis Software genesis@gsoft.com.au [[ > ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ > ]] realtime instrument control. (ph) +61-8-8267-3493 [[ > ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970806004529.266A-100000>