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 DB2F21381F3 for ; Sat, 25 May 2013 11:30:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9B828E0B68; Sat, 25 May 2013 11:30:48 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9B2B9E0B62 for ; Sat, 25 May 2013 11:30:47 +0000 (UTC) Received: from sf (unknown [178.121.57.192]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: slyfox) by smtp.gentoo.org (Postfix) with ESMTPSA id B715E33DF4C; Sat, 25 May 2013 11:30:45 +0000 (UTC) Date: Sat, 25 May 2013 14:29:12 +0300 From: Sergei Trofimovich To: gentoo-dev@lists.gentoo.org Cc: lu_zero@gentoo.org Subject: Re: [gentoo-dev] eselect init Message-ID: <20130525142913.082c2ff8@sf> In-Reply-To: <51A08A68.3020900@gentoo.org> References: <51A08A68.3020900@gentoo.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.17; x86_64-pc-linux-gnu) 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: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ZxyKv168ZArCTvP/CIja_hB"; protocol="application/pgp-signature" X-Archives-Salt: ddc9d7df-1faf-4427-92cf-1e2e8fcdefec X-Archives-Hash: 66631755c3f7c0f33c57a628942a25b3 --Sig_/ZxyKv168ZArCTvP/CIja_hB Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 25 May 2013 11:54:48 +0200 Luca Barbato wrote: > Hi, since the whole discussion got somehow sidetracked on where and if > to install for everybody the rc system specific files for everybody > (that should be an implementation detail for the specific dohelper > IMHO), I'm back to the other part of it: switching the actual init > implementation. >=20 > # WHY (not just edit your bootloader) >=20 > Since efi at least some people started to put in the kernel the bootargs > and we have at least few new options brewing for init, some are > small impact (bootchar, bb-init-openrc and runit-openrc) some are more > invasive (runit and systemd). >=20 > In those setup changing bootargs requires a kernel rebuild and some > effort, while the eselect approach stays completely transparent. >=20 > For some switch we might not have just to change the init binary bit > also to do some other changes (e.g. use a different format for inittab) If you can't change options at boot time it's very simple to get unbootable system. Just curious, who does such systems and how root filesystem (+ it's mount options) is expected to be found there? I guess EFI allows you to set bootargs via EFI UI. I'd go for init=3D/sbin/gentoo-init and make all the messy stuff there. Otherwise by breaking /sbin/init it would be hard to find proper name of, say, SYSVs /sbin/init. How would you call it? > # KEYPOINTS >=20 > - /sbin/init (or whatever linux currently calls by default with top > priority) should be either a symlink to the actual implementation or a > wrapper such as our gcc one. I like better the latter since it is > overall safer. The former might or might work since linux has some > fallback capabilities but hadn't been tested. >=20 > - init gets effectively switched only at boot/reboot, eselect init must > keep track of the current active init and make sure the current init > configuration is used till the system reboots, if we use the wrapper > approach, it would pick up what's the new init at boot and that would be > enough for simple cases, hooks on reboot are still needed for more > complex ones. >=20 > - we could try to not have the changes to the current init systems > ebuild or reduce them to the bare minimum (e.g. not overwrite /sbin/init) >=20 > # FOCUS >=20 > My interest is mostly if not all on bb-init-openrc and slightly on > runit-openrc. >=20 > There are enough people involved in systemd and since I still consider > it a dangerously frail implementation of a bad idea is better if I do > not touch it at all. >=20 > My system with stock openrc gets from linux start to graphical login in > less than 6s and I'm not using Gnome so I do not have any reason to use > it beside comparing. >=20 > lu >=20 >=20 --=20 Sergei --Sig_/ZxyKv168ZArCTvP/CIja_hB Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlGgoIwACgkQcaHudmEf86qWYQCfeWitMAkl+NWNOOLbGFhQrA/E m6cAn0hTFehBGzN5rCMMunDNtQIVEAzL =nVHy -----END PGP SIGNATURE----- --Sig_/ZxyKv168ZArCTvP/CIja_hB--