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. 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. > > 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. > > 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. > > https://lkml.org/lkml/2012/7/13/369 AFAIU I won't allow deselecting option until you deselect gentoo-specific bit. 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? > > 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? Issue new gentoo-sources and pray user will install/boot it before new udev? See my first two examples. -- Sergei
signature.asc
Description: PGP signature
