Quotes of the week [LWN.net]

Quotes of the week

Posted Feb 14, 2013 4:03 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: Quotes of the week by nevets
Parent article: Quotes of the week

He's right to worry about unstable tracepoints getting used by distros and then becoming de-facto ABI.

But on the other hand, if tracepoints become useful to many people it means that they ARE useful for many people. And probably should be kept that way.

I'm currently using SystemTap for instrumentation of the OOM killer (and I want to kill guys who unexported the kallsyms_lookup function, btw) - and I really like the fact that clearly defined tracepoints could be used instead of trying to patch kernel function calls. It's a low-level code and it'll be nice if it works next time I upgrade distro version, but at the same time I understand that it's not always possible, so I'd accept simple graceful failure if tracepoints are not available anymore.

to post comments

Quotes of the week

Posted Feb 14, 2013 5:46 UTC (Thu) by dlang (guest, #313) [Link] (5 responses)

The problem with tracepoints (or any other internal kernel datastructures) becoming part of the ABI is that it means that any future modifications of the kernel must support the same tracepoint, which may mean that you cannot make changes because the new implementation has a completely different algorithm and that tracepoint would make no sense.

Quotes of the week

Posted Feb 14, 2013 9:57 UTC (Thu) by epa (subscriber, #39769) [Link] (4 responses)

There have been suggestions like only activating tracepoints when you hold down the SysRq key on the local console, etc. Then they wouldn't become part of a permanent ABI.

Quotes of the week

Posted Feb 14, 2013 11:49 UTC (Thu) by Funcan (guest, #44209) [Link] (1 responses)

Completely un-helpful for e.g. servers

What ever way you turn them on, some app will make use of them then people will complain when said app breaks.

Quotes of the week

Posted Feb 14, 2013 23:21 UTC (Thu) by apoelstra (subscriber, #75205) [Link]

> What ever way you turn them on, some app will make use of them then people will complain when said app breaks.

The comment you replied to suggested that these tracepoints would be (at best) intermittently present. So anything depending on them would be broken from day 1, and wouldn't be able to blame the kernel devs for their trouble.

Quotes of the week

Posted Feb 15, 2013 4:13 UTC (Fri) by nevets (subscriber, #11875) [Link] (1 responses)

I suggested having "internal" tracepoints that would require an out-of-tree module loaded for userspace to access them.

I would even go so far as to maintain that module (under GPLv3), and expose the proper tracepoints. This will allow users and kernel developers to access them, as long as they download and install my simple module. But we will never have to worry about it becoming an ABI because we do not support out of tree module ABIs.

We have two rules:

1) Never break userspace ABI
2) Never require module ABI

Thus, the second one here will trump the first, as the first is only available via an out of tree module.

By licensing it under GPLv3, it will never be acceptable for mainline inclusion. :-)

Quotes of the week

Posted Feb 25, 2013 19:29 UTC (Mon) by andza (guest, #72692) [Link]

Sounds like _the_ plan.

The GPLv3 quirk could actually make it work rather nicely.