1 |
On Mon, 1 Jul 2013 11:17:49 -0700 |
2 |
Greg KH <gregkh@g.o> wrote: |
3 |
|
4 |
> > Meet CONFIG_DEVTMPFS; ... |
5 |
> |
6 |
> This is not the only build option that users must enable to get a |
7 |
> booting system by far. So why single this one out? |
8 |
|
9 |
Because it is an example. Later on I explicitly mention "There are a |
10 |
small set of other variables in this nature, ..."; I'm talking about |
11 |
configuration options not present in the defconfig, specifically those |
12 |
that everyone who runs a Gentoo based system (@system set + stage3) |
13 |
wants to have enabled. |
14 |
|
15 |
> > Q: What about my stable server? I really don't want to run this |
16 |
> > stuff! |
17 |
> > |
18 |
> > A: These options would depend on !CONFIG_VANILLA or |
19 |
> > CONFIG_EXPERIMENTAL |
20 |
> |
21 |
> What is CONFIG_VANILLA? I don't see that in the upstream kernel tree |
22 |
> at all. |
23 |
> |
24 |
> CONFIG_EXPERIMENTAL is now gone from upstream, so you are going to |
25 |
> have a problem with this. |
26 |
|
27 |
Earlier I mentioned "2) These feature should depend on a non-vanilla / |
28 |
experimental option." which is an option we would introduce under the |
29 |
Gentoo distribution menu section. |
30 |
|
31 |
> > which would be disabled by default, therefore if you keep this |
32 |
> > option the way it is on your stable server; it won't affect you. |
33 |
> |
34 |
> Not always true. Look at aufs as an example. It patches the core |
35 |
> kernel code in ways that are _not_ accepted upstream yet. Now you all |
36 |
> are running that modified code, even if you don't want aufs. |
37 |
|
38 |
Earlier I mentioned "3) The patch should not affect the build by |
39 |
default."; if it does, we have to adjust it to not do that, this is |
40 |
something that can be easily scripted. It's just a matter of embedding |
41 |
each + block in the diff with a config check and updating the counts. |
42 |
|
43 |
> > In other words, genpatches stay as stable as before; unless you |
44 |
> > explicitly toggle options that intentionally make it unstable. |
45 |
> |
46 |
> As pointed out above, this is not always true. |
47 |
|
48 |
Under the above condition (3), it is always true. |
49 |
|
50 |
> Also, as others stated, the "hardened" patches also don't always only |
51 |
> touch areas covered by non-config-selected portions of the kernel. |
52 |
|
53 |
Yes, it seems wise to keep hardened-sources separated. |
54 |
|
55 |
> Mix and match your external kernel patches at your own risk, what you |
56 |
> are suggesting does make it "easy" for users, but I bet it will be a |
57 |
> huge support issue for the already-overworked gentoo kernel |
58 |
> developers, the combinations just are too big to test and guarantee |
59 |
> working. |
60 |
|
61 |
I'm waiting for you to push new kernels to kernel.org. |
62 |
|
63 |
Joking aside; users are doing this anyway, it is better to know about |
64 |
it. Who knows some of the bugs we have is the result of our unawareness. |
65 |
|
66 |
Agreed, we have to watch out how far we push this though; which is why |
67 |
we should start with just those patches that appear the most in other |
68 |
sources, carefully meeting our goal over time. Not mimic geek-sources |
69 |
all at once, I believe it took him some time to reach that point... |
70 |
|
71 |
-- |
72 |
With kind regards, |
73 |
|
74 |
Tom Wijsman (TomWij) |
75 |
Gentoo Developer |
76 |
|
77 |
E-mail address : TomWij@g.o |
78 |
GPG Public Key : 6D34E57D |
79 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |