| 1 |
On Mon, 1 Jul 2013 12:23:24 -0700 |
| 2 |
Greg KH <gregkh@g.o> wrote: |
| 3 |
|
| 4 |
> > Earlier I mentioned "3) The patch should not affect the build by |
| 5 |
> > default."; if it does, we have to adjust it to not do that, this is |
| 6 |
> > something that can be easily scripted. It's just a matter of |
| 7 |
> > embedding each + block in the diff with a config check and updating |
| 8 |
> > the counts. |
| 9 |
> |
| 10 |
> Look at aufs as a specific example of why you can't do that, |
| 11 |
> otherwise, don't you think that the aufs developer(s) wouldn't have |
| 12 |
> done so? |
| 13 |
> |
| 14 |
> The goal of "don't touch any other kernel code" is a very good one, |
| 15 |
> but not always true for these huge out-of-tree kernel patches. |
| 16 |
> Usually that is the main reason why these patches aren't merged |
| 17 |
> upstream, because those changes are not acceptable. |
| 18 |
> |
| 19 |
> So be very careful here, you are messing with things that are rejected |
| 20 |
> by upstream. |
| 21 |
|
| 22 |
It sounds to me like some of those developers don't care about |
| 23 |
providing an option yet; because they would introduce it as an |
| 24 |
afterthought, based on its need and not just because they can. |
| 25 |
|
| 26 |
I don't see why this would be problematic, embedding it in config |
| 27 |
checks as well as checking whether the patch introduces non-conditional |
| 28 |
code are trivial to implement; why do you think this is not always true? |
| 29 |
|
| 30 |
Thank you for making us aware, feedback on this is nice. |
| 31 |
|
| 32 |
-- |
| 33 |
With kind regards, |
| 34 |
|
| 35 |
Tom Wijsman (TomWij) |
| 36 |
Gentoo Developer |
| 37 |
|
| 38 |
E-mail address : TomWij@g.o |
| 39 |
GPG Public Key : 6D34E57D |
| 40 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |
Archives