Gentoo Archives: gentoo-dev

From: Richard Yao <ryao@g.o>
To: Greg KH <gregkh@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
Date: Tue, 02 Jul 2013 03:29:51
Message-Id: 51D24923.7080101@gentoo.org
In Reply to: Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration. by Greg KH
1 On 07/01/2013 09:56 PM, Greg KH wrote:> On Mon, Jul 01, 2013 at
2 09:36:21PM -0400, Richard Yao wrote:
3 >> On 07/01/2013 03:23 PM, Greg KH wrote:
4 >>> On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
5 >>>>>> Q: What about my stable server? I really don't want to run this
6 >>>>>> stuff!
7 >>>>>>
8 >>>>>> A: These options would depend on !CONFIG_VANILLA or
9 >>>>>> CONFIG_EXPERIMENTAL
10 >>>>>
11 >>>>> What is CONFIG_VANILLA? I don't see that in the upstream kernel tree
12 >>>>> at all.
13 >>>>>
14 >>>>> CONFIG_EXPERIMENTAL is now gone from upstream, so you are going to
15 >>>>> have a problem with this.
16 >>>>
17 >>>> Earlier I mentioned "2) These feature should depend on a non-vanilla /
18 >>>> experimental option." which is an option we would introduce under the
19 >>>> Gentoo distribution menu section.
20 >>>
21 >>> Distro-specific config options, great :(
22 >>>
23 >>>>>> which would be disabled by default, therefore if you keep this
24 >>>>>> option the way it is on your stable server; it won't affect you.
25 >>>>>
26 >>>>> Not always true. Look at aufs as an example. It patches the core
27 >>>>> kernel code in ways that are _not_ accepted upstream yet. Now you all
28 >>>>> are running that modified code, even if you don't want aufs.
29 >>>>
30 >>>> Earlier I mentioned "3) The patch should not affect the build by
31 >>>> default."; if it does, we have to adjust it to not do that, this is
32 >>>> something that can be easily scripted. It's just a matter of embedding
33 >>>> each + block in the diff with a config check and updating the counts.
34 >>>
35 >>> Look at aufs as a specific example of why you can't do that, otherwise,
36 >>> don't you think that the aufs developer(s) wouldn't have done so?
37 >>
38 >> I am accquainted with the developer of a stackable filesystem developer.
39 >> According to what he has told me in person offline, the developers on
40 >> the LKML cannot decide on how a stackable filesystem should be
41 >> implemented. I was told three different variations on the design that
42 >> some people liked and others didn't, which ultimately kept the upstream
43 >> kernel from adopting anything. I specifically recall two variations,
44 >> which were doing it as part of the VFS and doing it as part of ext4. If
45 >> you want to criticize stackable filesystems, would you lay out a
46 >> groundwork for getting one implemented upon which people will agree?
47 >
48 > I was not criticising stackable filesystems at all, nor the aufs code,
49 > which I personally run on some of my own systems.
50 >
51 > I agree that the upstream kernel development of stackable filesystems
52 > has been all over the place, with seemingly not much guidance on how to
53 > get things merged properly. Being that I am not part of the subset of
54 > the kernel development community, I am in no position to lay any
55 > groundwork out at all.
56 >
57 > And note, this is totally off-topic from this thread.
58 >
59 > My main point is that if Gentoo wants to start maintaining out-of-tree
60 > kernel patches, and modifying them, the maintenance nightmare is going
61 > to be huge. Been there, done that, have way too many t-shirts
62 > commemorating it, and never want to do it again.
63 >
64 >>> The goal of "don't touch any other kernel code" is a very good one, but
65 >>> not always true for these huge out-of-tree kernel patches. Usually that
66 >>> is the main reason why these patches aren't merged upstream, because
67 >>> those changes are not acceptable.
68 >>
69 >> I was under the impression that there were several reasons for patches
70 >> not being merged upstream:
71 >>
72 >> 1. Lack of signed-off
73 >
74 > No distro will accept code that does not have a signed-off-by line,
75 > otherwise they might get into trouble, as that implies the patch is not
76 > properly licensed, right?
77
78 That is wrong. Signed-off is an affirmation that the code is under the
79 license, but the absence of signed-off does not imply that the code is
80 not under the license. For example, I doubt you will receive signed-off
81 for PaX/GrSecurity, but is there any doubt that code is under the GPL?
82
83 To give another example, I doubt that you will receive signed off for
84 code from BSD UNIX, but is there any doubt that code is under the
85 3-clause BSD license?
86
87 >> 2. Code drop that no one will maintain
88 >
89 > Agreed.
90 >
91 >> 3. Subsystem maintainers saying no simply because they do not like
92 >> <insert non-technical reason here>.
93 >
94 > That is very rare and usually the subsystem maintainer can be poked to
95 > resolve this.
96
97 Past conversations with you have made me reluctant to try, but the next
98 time I see something like this, I will send you an email.
99
100 >> 4. Risk of patent trolls
101 >
102 > I know of no kernel patches outside of the tree because of this, do you?
103
104 There is compatibility code for DOS long filenames in fat that is no
105 longer in-tree because of this.
106
107 >> 5. Actual technical reasons
108 >
109 > That's the majority of the reasons patches aren't accepted.
110
111 Not all patches that aren't accepted are submitted to be rejected.
112
113 >> Only some of the patches were rejected. Others were never submitted. The
114 >> PaX/GrSecurity developers prefer their code to stay out-of-tree. As one
115 >> of the people hacking on ZFSOnLinux, I prefer that the code be
116 >> out-of-tree.
117 >
118 > There's also a small legal issue with the zfs code that might prevent it
119 > from being merged :)
120
121 To summarize an email from Linus, the reason people who want ZFS in the
122 main tree cannot have that is his signed-off policy. At least one of the
123 copyright holders has no interest in providing it.
124
125 >> That is because fixes for other filesystems are either held back by a
126 >> lack of system kernel updates or held hostage by regressions in newer
127 >> kernels on certain hardware.
128 >
129 > I have never heard this being a reason for keeping code upstream, what
130 > do you mean by it?
131
132 This is an issue that end users tend to encounter where changes in a
133 newer kernel break stuff that they need. One example is nouveau kexec
134 support. Another is that the nouveau in the first two RCs of Linux 3.7
135 (if I recall) broke my display completely.
136
137 >> With that said, being in Linus' tree does not make code fall under some
138 >> golden standard for quality. There are many significant issues in code
139 >> committed to Linus' the kernel, some of which have been problems for
140 >> years. Just to name a few:
141 >
142 > <bug reports snipped>
143 >
144 > The fact that bugs happen in 16 million lines of kernel code, moving at
145 > a rate that is orders of magnitude faster than any other software
146 > development project, is not news to anyone, it's a fact of life.
147 >
148 > The fact that we fix them when they are found is the important thing,
149 > don't you agree?
150 >
151 > And of course, any recommendations on how we can find these bugs before
152 > they are merged is _always_ accepted.
153
154 My point is that code in Linus' tree is not free from error. It has bugs
155 too and is by no means always better than out-of-tree code.
156
157 >> Being outside Linus' tree is not synonymous with being bad and being bad
158 >> is not synonymous with being rejected. It is perfectly reasonable to
159 >> think that there are examples of good code outside Linus' tree.
160 >
161 > Being outside of Linus's tree puts the maintenance and support burden on
162 > you, and you are working against a body of code that is going faster
163 > this week than it did last week, so your work is constantly increasing.
164 > That is why it should be merged, to save yourself work.
165
166 Then you get to be a kernel subsystem maintainer and you get to check
167 which version of the code was included in the kernel for each bug
168 report, rather than just having one codebase.
169
170 >> Furthermore, should the kernel kernel choose to engage that out-of-tree
171 >> code, my expectation is that its quality will improve as they do testing
172 >> and write patches.
173 >
174 > What do you mean by this?
175 >
176 > thanks,
177 >
178 > greg k-h
179 >
180
181 I started using ZFSOnLinux last year. Since then, I have written several
182 dozen patches. I wrote support for multiple new kernels, wrote support
183 for PaX/GrSecurity, diagnosed why swap on zvols was broken and wrote the
184 initial patches to fix it, collaborated on kernel preemption support,
185 fixed several kernel panics, etcetera. Nearly all of that work has been
186 merged by ZFSOnLinux upstream, has been rejected under mutual agreement
187 or is pending under review. If Gentoo developers begin maintaining other
188 out-of-linus'-tree kernel code in Gentoo, I imagine that similar things
189 would happen with that code as well.

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies