Notes from the LPC scheduler microconference [LWN.net]

Notes from the LPC scheduler microconference

Posted Sep 22, 2017 17:58 UTC (Fri) by nevets (subscriber, #11875)
In reply to: Notes from the LPC scheduler microconference by karim
Parent article: Notes from the LPC scheduler microconference

Unfortunately, Linus has said otherwise. If a user space tool hooks into a trace event, and depends on it being a specific way, then if the trace event were to change in a way that the tool did not expect it to, and that change breaks the tool, that change *will* be reverted.

This has already happened with powertop. We had to keep 4 bytes of zeros in *every* event because powertop hard coded the offsets. Luckily for me, that hard coding broke when you had a 32 bit powertop on a 64 bit kernel. Then I was able to fix powertop to use the proper parsing and finally remove those 4 blank bytes. But that took years to get done.

There's a wake up "success" byte in the wake up code, that is now just a hard coded 1. That can't be removed, because a lot of tools look at that to see if the wake up was successful or not, even though it is always 1.

to post comments

Notes from the LPC scheduler microconference

Posted Sep 22, 2017 18:07 UTC (Fri) by karim (subscriber, #114) [Link]

Yeah, that's a problem I think.

It would probably be better to hide the ugliness into some kind of user-space library and have the user-space tools depend on that. This way the tools wouldn't need to change as much, but they'd need to use a version of the library that understands the kernel they're running on.

Having to maintain insane padding in events just because a user-space tool misunderstood it is broken by design from my standpoint. I'm in no position to push this myself, but I really think that your time would be much better used to making tracing better than being tied to legacy issues such as this. And, more importantly, I think users would be much better off if the trace points were considered a "constant moving target".