From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 16 18:54:52 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E50B1106566B for ; Thu, 16 Jun 2011 18:54:52 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 916EC8FC0A for ; Thu, 16 Jun 2011 18:54:52 +0000 (UTC) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p5GIspXt056136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 11:54:51 -0700 (PDT) (envelope-from mj@feral.com) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.14.4/8.14.4/Submit) with ESMTP id p5GIspPm056133; Thu, 16 Jun 2011 11:54:51 -0700 (PDT) (envelope-from mj@feral.com) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 16 Jun 2011 11:54:51 -0700 (PDT) From: Matthew Jacob To: Russell Cattelan In-Reply-To: <4DFA4C47.8060503@digitalelves.com> Message-ID: References: <4DFA4C47.8060503@digitalelves.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [127.0.0.1]); Thu, 16 Jun 2011 11:54:51 -0700 (PDT) Cc: freebsd-hackers@freebsd.org Subject: Re: kexec or similar for FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 18:54:53 -0000 Hi Russell! Yes, I think it is. Solaris supports something like this and the idea here is that with complicated I/O subsystems it's too hard to get them and locks cleaned up in a crash, but you want to get all the forensics you can, so doing a jump to a preloaded kernel that has a small and separate running address space seems a good way to go. If I were doing this, I'd try and set up the alternate kernel to be in the same state it would be just after the loader has prelinked all the pieces together. So, you run along in the loader, and jump to the kernel where all the pieces are linked together. Perhaps you could extend the loader to preload/prelink the alternate kernel as well (or just copy and relocate the main kernel). On Thu, 16 Jun 2011, 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? > > 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. > > Thanks for any help on this. > > -Russell Cattelan > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >