[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    [gentoo-dev] Re: Re: eselect init
From:       "Steven J. Long" <slong () rathaus ! eclipse ! co ! uk>
Date:       2013-06-25 4:53:20
Message-ID: 20130625045320.GA18277 () rathaus ! eclipse ! co ! uk
[Download RAW message or body]

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 ;-)

[prev in list] [next in list] [prev in thread] [next in thread]