White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
Posted May 23, 2024 12:35 UTC (Thu) by mb (subscriber, #50428)In reply to: White paper: Vendor Kernels, Bugs and Stability by tlamp
Parent article: White paper: Vendor Kernels, Bugs and Stability
We had such a deprecation list under Documentation, but I think it got removed a couple of years ago.
It was not very useful and suffered from major bitrot.
Posted May 23, 2024 13:20 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (5 responses)
Far better to do it in the kernel itself. Probably not easy, but move all deprecated stuff into a (or several) modules behind an option "deprecated-6.8" or whatever. Bleeding edge sets all these to "no", and either someone steps up and supports it (removing the deprecated option), or it bitrots until someone says "oh, this broke ages ago, let's delete it".
And then, if there's stuff you really want to get rid off but people need it, every year or so it gets upgraded to "deprecated latest kernel", so hopefully people stop using it and it finally drops out of sight ...
Cheers,
Posted May 23, 2024 14:45 UTC (Thu)
by mb (subscriber, #50428)
[Link] (4 responses)
It would change nothing.
>let's delete it
And that is exactly when people will first start to notice.
Posted May 23, 2024 20:56 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (2 responses)
Except it changes everything
> Every distribution and everyone building their kernel will just enable this option, because stuff will break without enabling it.
You just said it!
The distributions are enabling something that is disabled by default? They're accepting responsibility for keeping it working.
Developers are enabling something that is disabled by default? They're accepting the associated risks.
People are enabling something that is marked "deprecated"? They're being placed on notice that it's being left to bit-rot.
The fact that people have to actively enable something that developers clearly don't want activated means that anybody using it will have three choices - migrate their code away, take over maintenance, or do an ostrich and bury their heads in the sand. Users will still be able to be complain "I didn't know", but their upstream won't have that excuse.
Cheers,
Posted May 23, 2024 21:01 UTC (Thu)
by mb (subscriber, #50428)
[Link] (1 responses)
Do you realize, that most kernel options are disabled by default?
>The fact that people have to actively enable something that developers clearly don't want activated means
It means that developers don't have a clue what people (users!) actually want and need.
Closing your eyes won't make the demand go away, unless you are less than three years old.
Posted May 23, 2024 22:41 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
And how many of those options have "deprecated" in their name? Surely that's a massive red flag.
> It means that developers don't have a clue what people (users!) actually want and need.
And how many developers are employed by (therefore are) users? I believe Alphabet employs loads. Meta employs loads. Most of the kernel developers I have contact with are employed by large end users. It's a little difficult to be oblivious of your own needs. (Some people manage, I'm sure ...)
How difficult is it - to set a "not enabled" flag that cannot be accessed without some sort of warning that this flag will enable deprecated functionality Surely it's not beyond the wit of your typical kernel developer? That's ALL that's required.
Cheers,
Posted May 24, 2024 8:15 UTC (Fri)
by tlamp (subscriber, #108540)
[Link]
I don't think so, mostly because my spitballed proposal was not targeted at solving the "distros get never hurt by deprecation", as IMO that cannot be solved, besides not doing any deprecation at all anymore which hardly is a good solution. Rather, I wanted to target the "how things get communicated and noticed" part and having ab extra compile option with something like "deprecated-6.8-removal-6.12" in the name could actually be quite good for that. The build configs are often tracked and even diffed, and as simple single file can be easily grep'ed against _DEPRECATION_ and then diffed for ones that would trigger soon or new ones, probably even by a CI like systemd uses.
I.e., the status quo is having warnings for deprecation, which can be brittle and are not easy to digest/parse, having that info in an easier to digest manner would help a lot as tools/distros that depend on such options can easily find out when a used one will vanish soon(ish), then they also have no excuse about being unprepared.
> And that is exactly when people will first start to notice.
If their distro or tooling did not do their work then yes, but it wouldn't be the fault of the kernel having a messy deprecation process. IME most bigger distros or big projects like systemd want to avoid that, so if they'd have the definitive information required to do so in just somewhat digestible way, then I really think that most would actually act on that.
White paper: Vendor Kernels, Bugs and Stability
It was not very useful and suffered from major bitrot.
Wol
White paper: Vendor Kernels, Bugs and Stability
Every distribution and everyone building their kernel will just enable this option, because stuff will break without enabling it.
Just like everybody enabled the - how was it called? - EXPERIMENTAL option.
Such options are useless.
And there is not much anybody can do about that *except* to not break/deprecate stuff.
White paper: Vendor Kernels, Bugs and Stability
Wol
White paper: Vendor Kernels, Bugs and Stability
White paper: Vendor Kernels, Bugs and Stability
Wol
White paper: Vendor Kernels, Bugs and Stability
> Every distribution and everyone building their kernel will just enable this option, because stuff will break without enabling it.
> Just like everybody enabled the - how was it called? - EXPERIMENTAL option.
> Such options are useless.