From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 799971381F3 for ; Tue, 25 Jun 2013 04:52:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 873B9E09FA; Tue, 25 Jun 2013 04:52:49 +0000 (UTC) Received: from smtpout.karoo.kcom.com (smtpout.karoo.kcom.com [212.50.160.34]) by pigeon.gentoo.org (Postfix) with ESMTP id 5B9F8E09EA for ; Tue, 25 Jun 2013 04:52:47 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.87,933,1363132800"; d="scan'208";a="20007579" Received: from unknown (HELO rathaus.eclipse.co.uk) ([109.176.170.110]) by smtpout.karoo.kcom.com with ESMTP; 25 Jun 2013 05:52:09 +0100 Date: Tue, 25 Jun 2013 05:53:20 +0100 From: "Steven J. Long" To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: Re: eselect init Message-ID: <20130625045320.GA18277@rathaus.eclipse.co.uk> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <51A08A68.3020900@gentoo.org> <20130620171027.GA31429@rathaus.eclipse.co.uk> <20130620204829.GA23719@linux1> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130620204829.GA23719@linux1> X-Archives-Salt: a8d91b92-560f-4260-8b3f-76640d0b856a X-Archives-Hash: be3209f661a40383fb9b8d9358b94981 On Thu, Jun 20, 2013 at 03:48:29PM -0500, William Hubbs wrote: > On Thu, Jun 20, 2013 at 06:10:27PM +0100, Steven J. Long wrote: > > Fabio Erculiani wrote: > > > - only init is currently handled by eselect-init, which is now using a > > > very small wrapper POSIX shell script to redirect the calls to the > > > currently running init > > > > How does say, switching inittab format, work under this setup? > > I think this is a separate issue -- if busybox init's inittab is a > different format than sysvinbb's inittab, it should also use a different > file name, e.g. bb-inittab or something similar. > > bb could fall back to inittab, but I think it should look for something > liike bb-inittab first. That way eselect init wouldn't have to worry > about it at all. You're missing the point, because of your usual monomania for specific rather than general use-cases. 'Say' meant it was an example. I asked the question, because AFAICT from reading the code, the proposed approach keeps an indication of the running init, from startup, and then traps every call to that init, to check whether eselect has in the interim changed the symlink to point elsewhere. If einit instead simply checked whether there was a 'switchto' file at startup, it would be able to handle the more general problem, as well as running more efficiently and robustly, with no need to mess around with symlinks. The complexity would then be in eselect confirming, eg that the 'to' init is installed and configured, before setting the file for the next reboot. And optionally in the switcher when starting the new init at boot, if it should need anything tricky carried out, which might interact badly with a currently running init. That's a re-iteration of Duncan's idea, ofc. I'm also curious as to how an initramfs fits into the schema, given that there may be things that need to be done before pid 1 is started (or if not, I have nfc what all the discussion about replacing the kernel mechanism was in aid of.) -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)