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 23FDD1381F3 for ; Wed, 3 Jul 2013 13:55:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DA245E09C1; Wed, 3 Jul 2013 13:54:55 +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 E421BE0931 for ; Wed, 3 Jul 2013 13:54:54 +0000 (UTC) Received: from sf (unknown [178.120.3.9]) (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 0CF3E33E842 for ; Wed, 3 Jul 2013 13:54:52 +0000 (UTC) Date: Wed, 3 Jul 2013 16:52:37 +0300 From: Sergei Trofimovich To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Proper distribution integration of kernel *-sources, patches and configuration. Message-ID: <20130703165237.27144e4a@sf> In-Reply-To: <20130703150607.09eb9d1c@TOMWIJ-GENTOO> References: <20130701164149.131490f8@TOMWIJ-GENTOO> <20130702103634.0e70b9f8@sf> <20130702211607.5aeafeba@sf> <20130703150607.09eb9d1c@TOMWIJ-GENTOO> 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_/siECj3/AW6OkT6PkcRxggpJ"; protocol="application/pgp-signature" X-Archives-Salt: 3c290bdc-52d4-4f1a-90d4-e60eb148030b X-Archives-Hash: b4024a5d4d9e8300f05d3f7612cd264a --Sig_/siECj3/AW6OkT6PkcRxggpJ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 3 Jul 2013 15:06:07 +0200 Tom Wijsman wrote: > On Tue, 2 Jul 2013 21:16:07 +0300 > Sergei Trofimovich wrote: >=20 > > udev's case: > > It's _not_ the kernel which upgrade breaks user's system. Why do you > > try to "fix" it? If you want to save user's box - make check at > > pre-install time. Otherwise it will break. >=20 > Won't work for stage3's case, where this check won't run. Non-issue. - stage3 does not work out of the box. you can't boot or run it - stage3 does not work at all in containers w/o devtmpfs kernel. no matter what you try to force on newly built kernel. Let's consider real-world examples: My friend at cloud hosting company decided to try gentoo on a xen hypervisor box (3.0.6 host w/o devtmpfs). unpacked old stage3, which worked; merged new stuff there and rebooted. No kernel change, old xen 3.0.6. Guess what happened when he upgraded udev afterwards. Another my friend unpacked stage3 on his handheld with android kernel. 2.6.3x-something w/o accept4() syscall. Original stage3 worked, upgrade broke system. > > kernel's case: > > CONFIG_DEVTMPFS needs 'default yes', right? One-liner to > > gentoo-sources. >=20 > It's not as simple as a one-liner, because we need to respect people > that want to build a kernel without that; not everyone who uses > genpatches runs a Gentoo system, and note every other OS needs that > variable to enabled. 'default yes' is a Kconfig option. It picks a value if user didn't pick it explicitely. linux/drivers/base/Kconfig: config DEVTMPFS bool "Maintain a devtmpfs filesystem to mount at /dev" depends on HOTPLUG + default y One-liner, no? > > Why 'hide' it? It's very counterintuitive. >=20 > What is being hidden? You plan to have it visible only when something gentoo-specific needs to be disabled. [from origina post] > This is why I think it would be handy to add a Gentoo section to the > kernel, along the lines as described by Linus. >=20 > https://lkml.org/lkml/2012/7/13/369 AFAIU I won't allow deselecting option until you deselect gentoo-specific b= it. If you plan to upstream everything, then ok, no distro-specific hacks. > > What will you do with all-those-required-to-boot-properly > > - root filesystem > > - disk controller > > - USB keyboard drivers > > ? > > Include them all unless CONFIG_DONT_REMOVER_OR_WONT_BOOT > > option? >=20 > These don't fall under options that need to be enabled for everyone. >=20 > From what I see on chat and forums, people often set all these fine; > yet they not always enable CONFIG_DEVTMPFS and similar variables. >=20 > We deal with the absolutely necessary, not spoon feed every option. >=20 > > I'm afraid I don't see how it's a solution.=20 > > Suppose, tomorrow's udev will require CONFIG_foo, and glibc will > > require CONFIG_bar. How will you save user with your mechanism? >=20 > I don't see how we don't save them; but well, I'm not entirely sure if > you're talking about the opening post mechanism or another one here. Yeah, the opening post one. Suppose, tomorrow's udev requires CONFIG_CGROUPS=3Dy. What are your actions to save user's box? Issue new gentoo-sources and pray user will install/boot it before new udev? See my first two examples. --=20 Sergei --Sig_/siECj3/AW6OkT6PkcRxggpJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlHULKgACgkQcaHudmEf86oatwCffcPfxFq3zLt2J1owtWlcdkhl OM8Ani07rMss7OX8VN5kZuOhgdUB2UFb =EYFy -----END PGP SIGNATURE----- --Sig_/siECj3/AW6OkT6PkcRxggpJ--