1 |
Rich Freeman posted on Mon, 22 Sep 2014 08:53:44 -0400 as excerpted: |
2 |
|
3 |
> On Mon, Sep 22, 2014 at 8:47 AM, Harry Holt <harryholt@×××××.com> wrote: |
4 |
>> |
5 |
>> On Mon, Sep 22, 2014 at 2:00 AM, Duncan <1i5t5.duncan@×××.net> wrote: |
6 |
>>> |
7 |
>>> Rich Freeman posted on Sun, 21 Sep 2014 22:34:23 -0400 as excerpted: |
8 |
>>> |
9 |
>>> And Linus and the other kernel devs are constantly pointing out that |
10 |
>>> if they break userspace, report it as soon as possible so it can be |
11 |
>>> fixed. |
12 |
>> |
13 |
>> There are, in fact, a number of things that systemd breaks, and that |
14 |
>> the devs refuse to fix, that even Linus has complained about. To |
15 |
>> quote: |
16 |
> |
17 |
> Duncan was talking about linux, you're talking about systemd. If Kay |
18 |
> broke the kernel Linus wouldn't be complaining about it, he would be |
19 |
> doing something about it. |
20 |
|
21 |
Exactly. If a kernel change broke userspace, by Linus' definition, that |
22 |
kernel change is broken, full-stop. |
23 |
|
24 |
If they find out about it in the same kernel cycle, it's reverted, and |
25 |
that's about as hard and fast a rule as it gets. (The only exception |
26 |
would be if there's a break of userspace either way and no way to finesse |
27 |
it, in context, if that break was fixing a previous break, then Linus |
28 |
gets to call which break to fix.) |
29 |
|
30 |
But of course it can only be found out about in the same kernel cycle if |
31 |
someone affected is testing kernel rcs and reporting breakage. |
32 |
|
33 |
If the breakage is found later, it's still breakage and still subject to |
34 |
revert. Only by then some other userspace may be depending on the new |
35 |
behavior, in which case there's a problem. Obviously this is more likely |
36 |
the longer the "broken" behavior has remained in the kernel. They'll try |
37 |
to finesse this case and it really is amazing sometimes the extents |
38 |
they'll go to do it (one case was a special-casing of the behavior to the |
39 |
specific usage in question, they were able to detect that specific usage |
40 |
and special-case the specific otherwise broken behavior around it), but |
41 |
if that's not possible and it has only been a kernel cycle (people only |
42 |
tested the release, not the rcs, so only the single release kernel has |
43 |
that behavior), they'll probably still revert it, in part because there's |
44 |
relatively little released userspace that will depend on it that quickly |
45 |
and very likely it'll not have made a major distro release yet. |
46 |
|
47 |
But if the broken behavior isn't reported for several kernel cycles, say |
48 |
a year (about five kernel cycles), then it really is a tough call, |
49 |
particularly when there's established and widely used software already |
50 |
depending on the new behavior. |
51 |
|
52 |
Again, bottom line, report kernel breakage of userspace, the same kernel |
53 |
cycle that breakage happens if at all possible, which means testing an |
54 |
early enough kernel rc (rc3 is good), and it'll normally either be fixed |
55 |
or the commit introducing the change reverted. The longer you wait |
56 |
beyond the kernel cycle it was introduced, the more likely other |
57 |
userspace depends on the new behavior, with a revert becoming |
58 |
correspondingly more problematic. |
59 |
|
60 |
And again, if it's not reported, was it a break in the first place? Just |
61 |
make sure it's reported! |
62 |
|
63 |
-- |
64 |
Duncan - List replies preferred. No HTML msgs. |
65 |
"Every nonfree program has a lord, a master -- |
66 |
and if you use the program, he is your master." Richard Stallman |