From owner-freebsd-current@FreeBSD.ORG Wed Nov 19 11:43:25 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7F6816A4CE for ; Wed, 19 Nov 2003 11:43:25 -0800 (PST) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84C9343FE5 for ; Wed, 19 Nov 2003 11:43:22 -0800 (PST) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) hAJJhKus006017; Wed, 19 Nov 2003 14:43:20 -0500 (EST) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id hAJJhJb7006016; Wed, 19 Nov 2003 14:43:19 -0500 (EST) Date: Wed, 19 Nov 2003 14:43:19 -0500 From: Ken Smith To: Bruce Evans Message-ID: <20031119194319.GB5566@electra.cse.Buffalo.EDU> References: <200311182307.hAIN7Wpm000717@dyson.jdyson.com> <20031118164905.R35009@pooker.samsco.home> <20031119141059.GA14308@madman.celabo.org> <20031119141950.GA95734@ussenterprise.ufp.org> <20031119142535.GA27610@electra.cse.Buffalo.EDU> <20031119172533.GB9066@dhcp01.pn.xcllnt.net> <20031120061110.P8759@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031120061110.P8759@gamplex.bde.org> User-Agent: Mutt/1.4.1i cc: Ken Smith cc: freebsd-current@freebsd.org cc: Marcel Moolenaar Subject: Re: Unfortunate dynamic linking for everything X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2003 19:43:25 -0000 On Thu, Nov 20, 2003 at 06:27:31AM +1100, Bruce Evans wrote: > > set init_path=/rescue/init > > If dynamic root were ready to be turned on, then /rescue/init would be > in the default init_path. I had that explained to me too. :-) There is a loop in sys/kern/init_main.c that "probes" for an init to run. But it only does what you want for cases of the files not existing or otherwise just totally not executable. It won't handle the "started but then dumped core" case the way it would need to if /sbin/init were to fail because of shared library problems. So if just relying on this mechanism it would either not work right (/sbin/init in the path before /rescue/init) or it would always start /rescue/init (/rescue/init before /sbin/init in the path). -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel |