On Mon, 1 Jul 2013 11:17:49 -0700 Greg KH <gre...@gentoo.org> wrote: > > Meet CONFIG_DEVTMPFS; ... > > This is not the only build option that users must enable to get a > booting system by far. So why single this one out?
Because it is an example. Later on I explicitly mention "There are a small set of other variables in this nature, ..."; I'm talking about configuration options not present in the defconfig, specifically those that everyone who runs a Gentoo based system (@system set + stage3) wants to have enabled. > > 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. > > 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. > > In other words, genpatches stay as stable as before; unless you > > explicitly toggle options that intentionally make it unstable. > > As pointed out above, this is not always true. Under the above condition (3), it is always true. > Also, as others stated, the "hardened" patches also don't always only > touch areas covered by non-config-selected portions of the kernel. Yes, it seems wise to keep hardened-sources separated. > Mix and match your external kernel patches at your own risk, what you > are suggesting does make it "easy" for users, but I bet it will be a > huge support issue for the already-overworked gentoo kernel > developers, the combinations just are too big to test and guarantee > working. I'm waiting for you to push new kernels to kernel.org. Joking aside; users are doing this anyway, it is better to know about it. Who knows some of the bugs we have is the result of our unawareness. Agreed, we have to watch out how far we push this though; which is why we should start with just those patches that appear the most in other sources, carefully meeting our goal over time. Not mimic geek-sources all at once, I believe it took him some time to reach that point... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
