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

[Anthony G. Basile]

On 07/01/2013 03:23 PM, Greg KH wrote:
> On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
>>>> Q: What about my stable server? I really don't want to run this
>>>> stuff!
>>>>
>>>> A: These options would depend on !CONFIG_VANILLA or
>>>> CONFIG_EXPERIMENTAL
>>> What is CONFIG_VANILLA?  I don't see that in the upstream kernel tree
>>> at all.
>>>
>>> CONFIG_EXPERIMENTAL is now gone from upstream, so you are going to
>>> have a problem with this.
>> Earlier I mentioned "2) These feature should depend on a non-vanilla /
>> experimental option." which is an option we would introduce under the
>> Gentoo distribution menu section.
> Distro-specific config options, great :(

I'm not sure what you mean by "distro-specific", but suppose people want 
BFQ? Why can't we have it in gentoo-sources.  It is totally disabled by 
not selecting CONFIG_BFQ.  Selecting it is no different than emerging 
pf-sources with the same other options ported over. By your logic, we 
should not distribut pf-sources either.  The truth of the matter is, 
there are forks of the vanilla kernel out there. Are you suggesting we 
distribute none of them?

NOTE: hardened-sources is its own world.  There is not level of turning 
on/off options that get you back to a vanilla kernel.

>
>>>>     which would be disabled by default, therefore if you keep this
>>>> option the way it is on your stable server; it won't affect you.
>>> Not always true.  Look at aufs as an example.  It patches the core
>>> kernel code in ways that are _not_ accepted upstream yet.  Now you all
>>> are running that modified code, even if you don't want aufs.
>> Earlier I mentioned "3) The patch should not affect the build by
>> default."; if it does, we have to adjust it to not do that, this is
>> something that can be easily scripted. It's just a matter of embedding
>> each + block in the diff with a config check and updating the counts.
> Look at aufs as a specific example of why you can't do that, otherwise,
> don't you think that the aufs developer(s) wouldn't have done so?
>
> The goal of "don't touch any other kernel code" is a very good one, but
> not always true for these huge out-of-tree kernel patches.  Usually that
> is the main reason why these patches aren't merged upstream, because
> those changes are not acceptable.
>
> So be very careful here, you are messing with things that are rejected
> by upstream.
>
> greg k-h
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA