Re: [gentoo-dev] Proper distribution integration of kernel *-sources, patches and configuration.

[Tom Wijsman]

On Wed, 3 Jul 2013 16:52:37 +0300
Sergei Trofimovich <slyfox@g.o> wrote:

> On Wed, 3 Jul 2013 15:06:07 +0200
> Tom Wijsman <TomWij@g.o> wrote:
>
> > On Tue, 2 Jul 2013 21:16:07 +0300
> > Sergei Trofimovich <slyfox@g.o> 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  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D