| 1 |
On 07/01/2013 11:29 PM, Richard Yao wrote: |
| 2 |
> On 07/01/2013 09:56 PM, Greg KH wrote:> On Mon, Jul 01, 2013 at |
| 3 |
> 09:36:21PM -0400, Richard Yao wrote: |
| 4 |
>>> That is because fixes for other filesystems are either held back by a |
| 5 |
>>> lack of system kernel updates or held hostage by regressions in newer |
| 6 |
>>> kernels on certain hardware. |
| 7 |
>> |
| 8 |
>> I have never heard this being a reason for keeping code upstream, what |
| 9 |
>> do you mean by it? |
| 10 |
> |
| 11 |
> This is an issue that end users tend to encounter where changes in a |
| 12 |
> newer kernel break stuff that they need. One example is nouveau kexec |
| 13 |
> support. Another is that the nouveau in the first two RCs of Linux 3.7 |
| 14 |
> (if I recall) broke my display completely. |
| 15 |
|
| 16 |
I probably should clarify that this issue keeps some users from |
| 17 |
obtaining bug fixes in key components (e.g. their filesystem). That is |
| 18 |
why I prefer the situation where code lives out-of-tree and works on a |
| 19 |
variety of kernels over the situation where it is bundled with the |
| 20 |
kernel for in-tree builds. |
Archives