How to unbreak LTTng
How to unbreak LTTng
Posted Apr 21, 2020 13:28 UTC (Tue) by mfuzzey (subscriber, #57966)In reply to: How to unbreak LTTng by ncultra
Parent article: How to unbreak LTTng
Generally excluding duplicate functionality seems to be a good idea for long term maintenance and code size surely.
When competing solutions exist the best bits of each can be, and often are it seems to me, merged to make a better in tree solution.
And in this particular case Steve Rostedt was quoted in the article as being open to including LTTng
> In-tree status is unrealistic for many free kernel modules
Why? For non-free ones sure but you explicitly said free modules.
> to punish out-of-tree developers.
Why? Sure some decisions may make there life harder but "punish" implies an "intention to hurt". What makes you think this is the case rather than just trying to do what is best for the kernel as a whole (even if that makes things harder for out of tree modules)?
> with the lack of a stable kernel API
The reasons for this are well documented and make sense to many. This is really part of the Linux philosophy today I'd say. No one forces anyone to use Linux.
Posted Apr 21, 2020 14:09 UTC (Tue)
by Paf (subscriber, #91811)
[Link] (2 responses)
It’s (in many cases) a huge amount of ongoing work, requiring not only commitment and effort but persuasion of others that you have commitment and effort.
The idea is that not everything that exists is up to the standards for mainline inclusion, and not everything that exists is going to avoid duplication to the level that’s appropriate for the mainline.
This is “let a thousand flowers bloom” stuff - it’s about being open to a world of stuff beyond the domain of what’s good enough to be a permanent part of mainline. Hobby projects (that still have outside users), small stuff, differing approaches to existing functionality that are not clearly better in general (see LTTTNG for an example of that) but are preferred by some users, etc.
I recognize this is a sticky issue (well, sort of), but this is still a choice to be more closed.
Posted Apr 28, 2020 21:35 UTC (Tue)
by ecree (guest, #95790)
[Link] (1 responses)
Maintaining an in-tree module is *way* less work than maintaining an out-of-tree one. Heck, most of the time you just have to say "Ack" on the patches that the person changing some kernel infrastructure _writes for you_ to keep your module working. Whereas out-of-tree you end up with elaborate compatibility scripts, that you have to keep updated without any outside help, unless you're happy for your module to either only build on the latest kernel, or be tied to 2.6.32 forever 'cos that's what was ubiquitous when you started the project.
If it's tight enough with the kernel to be a module (rather than a userspace executable, using the APIs that are actually designed to be stable), then it belongs in the upstream tree; and if it's not good enough quality to be upstream (even in staging or behind a 'default n' kconfig) then it doesn't belong anywhere.
Posted Apr 28, 2020 22:06 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link]
Posted Apr 21, 2020 16:10 UTC (Tue)
by nilsmeyer (guest, #122604)
[Link]
What about SELinux and AppArmor (and Smack and TOMOYO)? There are probably a lot of other examples. It often feels arbitrary to the outside observer,
Posted Apr 22, 2020 14:42 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
Because there's evidence that some kernel maintainers, at least, do not make these decisions based on technical evidence, but on how much grief it's going to cause people that these maintainers perceive as "bad actors".
The fact that it causes a lot of grief to innocent bystanders does not get taken into account.
Cheers,
How to unbreak LTTng
How to unbreak LTTng
How to unbreak LTTng
How to unbreak LTTng
How to unbreak LTTng
Wol