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 D2D7E1381F3 for ; Wed, 3 Jul 2013 15:21:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3E9A8E0980; Wed, 3 Jul 2013 15:21:46 +0000 (UTC) Received: from jacques.telenet-ops.be (jacques.telenet-ops.be [195.130.132.50]) by pigeon.gentoo.org (Postfix) with ESMTP id F30B2E0973 for ; Wed, 3 Jul 2013 15:21:44 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by jacques.telenet-ops.be with bizsmtp id vrMk1l0092khLEN0JrMk0g; Wed, 03 Jul 2013 17:21:44 +0200 Date: Wed, 3 Jul 2013 17:18:36 +0200 From: Tom Wijsman To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Proper distribution integration of kernel *-sources, patches and configuration. Message-ID: <20130703171836.69e9f446@TOMWIJ-GENTOO> In-Reply-To: <20130703165237.27144e4a@sf> References: <20130701164149.131490f8@TOMWIJ-GENTOO> <20130702103634.0e70b9f8@sf> <20130702211607.5aeafeba@sf> <20130703150607.09eb9d1c@TOMWIJ-GENTOO> <20130703165237.27144e4a@sf> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.19; 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_/pp_6b+EF4z07kCS7yb/QM/V"; protocol="application/pgp-signature" X-Archives-Salt: 909f3e4c-eb92-41eb-a2a3-6d4465901849 X-Archives-Hash: 31fde2ab02fc344c696484fb43858754 --Sig_/pp_6b+EF4z07kCS7yb/QM/V Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 3 Jul 2013 16:52:37 +0300 Sergei Trofimovich wrote: > On Wed, 3 Jul 2013 15:06:07 +0200 > Tom Wijsman wrote: >=20 > > 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. >=20 > 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. Make check doesn't work there. A distro default config option does. > Let's consider real-world examples: >=20 > 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. Stage3 contains the upgraded udev these days. > > > 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. >=20 > '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 >=20 > One-liner, no? We don't want to change DEVTMPFS itself, because not everyone whom uses genpatches wants DEVTMPFS itself enabled by default; we instead plan to provide it as a distribution specific option that enables it. https://lkml.org/lkml/2012/7/13/369 > > > Why 'hide' it? It's very counterintuitive. > >=20 > > What is being hidden? >=20 > You plan to have it visible only when something gentoo-specific needs > to be disabled. No, I did not state such thing. > [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 >=20 > AFAIU I won't allow deselecting option until you deselect > gentoo-specific bit. Then you disable the bit and deselect it, I don't see a problem here. > If you plan to upstream everything, then ok, no distro-specific hacks. I don't see how providing distro default options as described is a hack. > > > 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. >=20 > Yeah, the opening post one. > Suppose, tomorrow's udev requires CONFIG_CGROUPS=3Dy. > What are your actions to save user's box? If it's along the lines of what's proposed, add it as well. > Issue new gentoo-sources and pray user will install/boot it > before new udev? See my first two examples. That's what news items are for; we're not trying to deal with this short term case, but rather with the long term case after that. --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/pp_6b+EF4z07kCS7yb/QM/V Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJR1EDQAAoJEJWyH81tNOV98WIIAIqMLAHCgoimq0ccMRsXhWrb EoiVpSJE1ge5W9kdmamFWMMMOPbPmtNeQSB3QYpFPVCxnN6N/1VbJaXt/iW8ILWp uUd+SdLh2+qN/0Cvib9sVdsrTxckMoPHliJ6rT1vhtPWaeAEvpkcBXcaReeKVFeC ZwzIgTYUfGkq2V5Cbt/li/8YsQg1rq+uRHO+YnDXjDDlu3RKevvQBsFHFDNOF2EF mKPrEEbpVThswDBlAFTeaA40jvPXmB8xeinT0mguSI8Rjyq+S6i8yfDOKL7zx9JU Xbrg52OqG+MFdRsm5uXlxWwTfpHpWfCgLcTtkvX0pzPkDV4+cdGyhqQp+5YxAuQ= =BNBB -----END PGP SIGNATURE----- --Sig_/pp_6b+EF4z07kCS7yb/QM/V--