On Wed, 3 Jul 2013 16:52:37 +0300 Sergei Trofimovich <[email protected]> wrote:
> On Wed, 3 Jul 2013 15:06:07 +0200 > Tom Wijsman <[email protected]> wrote: > > > On Tue, 2 Jul 2013 21:16:07 +0300 > > Sergei Trofimovich <[email protected]> wrote: > > > > > 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. > > > > 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. Make check doesn't work there. A distro default config option does. > 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. Stage3 contains the upgraded udev these days. > > > kernel's case: > > > CONFIG_DEVTMPFS needs 'default yes', right? One-liner to > > > gentoo-sources. > > > > 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? 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. > > > > What is being hidden? > > 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. > > > > https://lkml.org/lkml/2012/7/13/369 > > 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? > > > > These don't fall under options that need to be enabled for everyone. > > > > From what I see on chat and forums, people often set all these fine; > > yet they not always enable CONFIG_DEVTMPFS and similar variables. > > > > We deal with the absolutely necessary, not spoon feed every option. > > > > > I'm afraid I don't see how it's a solution. > > > Suppose, tomorrow's udev will require CONFIG_foo, and glibc will > > > require CONFIG_bar. How will you save user with your mechanism? > > > > 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=y. > 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. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : [email protected] GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
