Quotes of the week

We already had an issue with exposed tracepoints, which will be finally resolved in 3.9.

http://lwn.net/Articles/442113/

Funny, and here I thought that fraction of kernel developers among the users of tracepoints is going to be higher than that among the users of syscalls...

And no, I don't have a problem with sane syscalls being introduced - see e.g. open-by-fhandle story. What I *do* have a problem with is review-free channels for introducing new ABIs. Somebody will end up paying the price anyway; I have zero sympathy for people complaining about the cost of introducing a new syscall - all that <gasp> review, dealing with objections, etc., because if they do not pay it, we will. And we'll be paying it forever - desktop crowd feels free to play the ABI incompatibility of the week games, but kernel-side it's not going to be acceptable.

FWIW, I have learnt (and quite painfully at that) that

* optional stuff isn't. "It's optional, don't enable it if you don't like it" as an excuse for getting a shitty code in has grown very old. It might be optional at the moment of introduction, but once it's in, it's granted all the stability warranties and by the time somebody comes and makes it very much non-optional it's far too late to do it right.

* single-consumer APIs suck. "It's just for our project" tends to be a codeword for "we make tons of assumptions about the way it'll be used", with everything that follows from that. C.f. dnotify and samba. Or adjtimex(2) and ntp (don't look at the structure being passed or biarch issues caused by it unless you want to take the second look at your dinner). Et sodding cetera - the ugliest crap comes from the stuff with small group of projects in control of the interface.

* hooks belong in tender bits of anatomy of those who are trying to introduce them. "Oh, just have our code executed every time you go here" suffers from a simple defect - very few things are naturally expressed that way. Odds are, whatever analysis of the code they are inserting the hooks into is (a) incomplete; (b) not shared with maintainers of that code; (c) makes very subtle assumptions about e.g. locking environment. Sure, for short-term debugging they are wonderful - who hadn't done "call this function here, here and here" while debugging some crap? Fine as long as you don't expect to carry that set (and those of hell knows how many other people) in your tree for years...

* interfaces that are easy to use do exist; they are hellishly hard to get right, though, and most of the candidates are seriously oversold. "Oh, it's easy to deal with refcounting problems - just use kref". Right. Except that a _lot_ of kref users are seriously racy - e.g. when object can be found (and reference acquired) in some search structure, removing it from there in destructor callback requires exclusion between the final put and lookups. Textbook stuff, right? Now go grep for kref_put callbacks and see how many of them step into it. I'm not saying that forcing everyone to reinvent that wheel would be better - in this particular case it was more about lacking primitives. I'd ended up adding one such thing (kref_put_mutex()), but we still lack e.g. spinlock equivalent. And I'm very sure that we still have unfixed races on kref_put().

Tracepoints *are* easy to use. They have their problems, but they are fine as debugging tools, etc. - after all, if the code you are trying to debug/instrument/etc. changes its structure, your instrumentation-related needs are going to change. Locking change affects consistency warranties about some data? You want to change the points where you observe it anyway. Didn't get all the data you want to collect? No problem, it's easy to change the sucker. And yes, they are easier to keep track of than their open-coded equivalents. Wonderful as a tool for kernel development, actually. But exact same properties make them recipe for disaster as soon as they are treated as userland-stable interfaces. And tracepoints reaching the mainline kernel become userland-grade ABIs...