1 |
On Mon, Jul 01, 2013 at 09:36:21PM -0400, Richard Yao wrote: |
2 |
> On 07/01/2013 03:23 PM, Greg KH wrote: |
3 |
> > On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote: |
4 |
> >>>> Q: What about my stable server? I really don't want to run this |
5 |
> >>>> stuff! |
6 |
> >>>> |
7 |
> >>>> A: These options would depend on !CONFIG_VANILLA or |
8 |
> >>>> CONFIG_EXPERIMENTAL |
9 |
> >>> |
10 |
> >>> What is CONFIG_VANILLA? I don't see that in the upstream kernel tree |
11 |
> >>> at all. |
12 |
> >>> |
13 |
> >>> CONFIG_EXPERIMENTAL is now gone from upstream, so you are going to |
14 |
> >>> have a problem with this. |
15 |
> >> |
16 |
> >> Earlier I mentioned "2) These feature should depend on a non-vanilla / |
17 |
> >> experimental option." which is an option we would introduce under the |
18 |
> >> Gentoo distribution menu section. |
19 |
> > |
20 |
> > Distro-specific config options, great :( |
21 |
> > |
22 |
> >>>> which would be disabled by default, therefore if you keep this |
23 |
> >>>> option the way it is on your stable server; it won't affect you. |
24 |
> >>> |
25 |
> >>> Not always true. Look at aufs as an example. It patches the core |
26 |
> >>> kernel code in ways that are _not_ accepted upstream yet. Now you all |
27 |
> >>> are running that modified code, even if you don't want aufs. |
28 |
> >> |
29 |
> >> Earlier I mentioned "3) The patch should not affect the build by |
30 |
> >> default."; if it does, we have to adjust it to not do that, this is |
31 |
> >> something that can be easily scripted. It's just a matter of embedding |
32 |
> >> each + block in the diff with a config check and updating the counts. |
33 |
> > |
34 |
> > Look at aufs as a specific example of why you can't do that, otherwise, |
35 |
> > don't you think that the aufs developer(s) wouldn't have done so? |
36 |
> |
37 |
> I am accquainted with the developer of a stackable filesystem developer. |
38 |
> According to what he has told me in person offline, the developers on |
39 |
> the LKML cannot decide on how a stackable filesystem should be |
40 |
> implemented. I was told three different variations on the design that |
41 |
> some people liked and others didn't, which ultimately kept the upstream |
42 |
> kernel from adopting anything. I specifically recall two variations, |
43 |
> which were doing it as part of the VFS and doing it as part of ext4. If |
44 |
> you want to criticize stackable filesystems, would you lay out a |
45 |
> groundwork for getting one implemented upon which people will agree? |
46 |
|
47 |
I was not criticising stackable filesystems at all, nor the aufs code, |
48 |
which I personally run on some of my own systems. |
49 |
|
50 |
I agree that the upstream kernel development of stackable filesystems |
51 |
has been all over the place, with seemingly not much guidance on how to |
52 |
get things merged properly. Being that I am not part of the subset of |
53 |
the kernel development community, I am in no position to lay any |
54 |
groundwork out at all. |
55 |
|
56 |
And note, this is totally off-topic from this thread. |
57 |
|
58 |
My main point is that if Gentoo wants to start maintaining out-of-tree |
59 |
kernel patches, and modifying them, the maintenance nightmare is going |
60 |
to be huge. Been there, done that, have way too many t-shirts |
61 |
commemorating it, and never want to do it again. |
62 |
|
63 |
> > The goal of "don't touch any other kernel code" is a very good one, but |
64 |
> > not always true for these huge out-of-tree kernel patches. Usually that |
65 |
> > is the main reason why these patches aren't merged upstream, because |
66 |
> > those changes are not acceptable. |
67 |
> |
68 |
> I was under the impression that there were several reasons for patches |
69 |
> not being merged upstream: |
70 |
> |
71 |
> 1. Lack of signed-off |
72 |
|
73 |
No distro will accept code that does not have a signed-off-by line, |
74 |
otherwise they might get into trouble, as that implies the patch is not |
75 |
properly licensed, right? |
76 |
|
77 |
> 2. Code drop that no one will maintain |
78 |
|
79 |
Agreed. |
80 |
|
81 |
> 3. Subsystem maintainers saying no simply because they do not like |
82 |
> <insert non-technical reason here>. |
83 |
|
84 |
That is very rare and usually the subsystem maintainer can be poked to |
85 |
resolve this. |
86 |
|
87 |
> 4. Risk of patent trolls |
88 |
|
89 |
I know of no kernel patches outside of the tree because of this, do you? |
90 |
|
91 |
> 5. Actual technical reasons |
92 |
|
93 |
That's the majority of the reasons patches aren't accepted. |
94 |
|
95 |
> Only some of the patches were rejected. Others were never submitted. The |
96 |
> PaX/GrSecurity developers prefer their code to stay out-of-tree. As one |
97 |
> of the people hacking on ZFSOnLinux, I prefer that the code be |
98 |
> out-of-tree. |
99 |
|
100 |
There's also a small legal issue with the zfs code that might prevent it |
101 |
from being merged :) |
102 |
|
103 |
> That is because fixes for other filesystems are either held back by a |
104 |
> lack of system kernel updates or held hostage by regressions in newer |
105 |
> kernels on certain hardware. |
106 |
|
107 |
I have never heard this being a reason for keeping code upstream, what |
108 |
do you mean by it? |
109 |
|
110 |
> With that said, being in Linus' tree does not make code fall under some |
111 |
> golden standard for quality. There are many significant issues in code |
112 |
> committed to Linus' the kernel, some of which have been problems for |
113 |
> years. Just to name a few: |
114 |
|
115 |
<bug reports snipped> |
116 |
|
117 |
The fact that bugs happen in 16 million lines of kernel code, moving at |
118 |
a rate that is orders of magnitude faster than any other software |
119 |
development project, is not news to anyone, it's a fact of life. |
120 |
|
121 |
The fact that we fix them when they are found is the important thing, |
122 |
don't you agree? |
123 |
|
124 |
And of course, any recommendations on how we can find these bugs before |
125 |
they are merged is _always_ accepted. |
126 |
|
127 |
> Being outside Linus' tree is not synonymous with being bad and being bad |
128 |
> is not synonymous with being rejected. It is perfectly reasonable to |
129 |
> think that there are examples of good code outside Linus' tree. |
130 |
|
131 |
Being outside of Linus's tree puts the maintenance and support burden on |
132 |
you, and you are working against a body of code that is going faster |
133 |
this week than it did last week, so your work is constantly increasing. |
134 |
That is why it should be merged, to save yourself work. |
135 |
|
136 |
> Furthermore, should the kernel kernel choose to engage that out-of-tree |
137 |
> code, my expectation is that its quality will improve as they do testing |
138 |
> and write patches. |
139 |
|
140 |
What do you mean by this? |
141 |
|
142 |
thanks, |
143 |
|
144 |
greg k-h |