Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
As far as I'm concerned, *the* *only* interface stability
warranties in VFS are those for syscalls. Which means that no
tracepoints are going to be acceptable there. End of story.
— Al Viro
Hey ARM!
— Luc Verhaegen
We are not going away, we are here to stay. We cannot be silenced or stopped anymore, and we are becoming harder and harder to ignore. It is only a matter of time before we produce an open source graphics driver stack which rivals your binary in performance. And that time is measured in weeks and months now. The requests from your own customers, for support for this open source stack, will only grow louder and louder. So please, stop fighting us. Embrace us. Work with us. Your customers and shareholders will love you for it.
Yeah, a plan, I know it goes against normal kernel development
procedures, but hey, we're in our early 20's now, it's about time
we started getting responsible.
— Greg Kroah-Hartman(Log in to post comments)
Quotes of the week Posted Feb 14, 2013 3:40 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Maybe it's just me, but it looks like Al Viro is hostile to _anything_ that might be useful to anybody except kernel developers?
Quotes of the week Posted Feb 14, 2013 3:56 UTC (Thu) by nevets (subscriber, #11875) [Link]
It's also very useful for kernel developers, but Al has a right to be hostile. Exposing tracepoints to userspace makes it a hard coded ABI if some application comes to depend on a specific tracepoint. That means those tracepoints become a permanent fixture in the kernel and a maintenance burden for the maintainers (namely Al).
We already had an issue with exposed tracepoints, which will be finally resolved in 3.9.
Quotes of the week Posted Feb 14, 2013 4:03 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
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.
Quotes of the week Posted Feb 14, 2013 5:46 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
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]
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 (subscriber, #44209) [Link]
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]
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
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 (subscriber, #72692) [Link]
Sounds like _the_ plan.
The GPLv3 quirk could actually make it work rather nicely.
Quotes of the week Posted Feb 14, 2013 23:05 UTC (Thu) by Anssi (subscriber, #52242) [Link]
Interesting. I thought tracepoints weren't part of the ABI, especially since e.g. i915 changed their exposed tracepoints in 2011:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...
Quotes of the week Posted Feb 15, 2013 1:05 UTC (Fri) by chris.wilson (subscriber, #42619) [Link]
Were you using the garbage that they reported before?
Quotes of the week Posted Feb 15, 2013 1:08 UTC (Fri) by Anssi (subscriber, #52242) [Link]
Powertop did (and still does if run on such a kernel), for the GPU ops/sec count.
Quotes of the week Posted Feb 15, 2013 4:06 UTC (Fri) by nevets (subscriber, #11875) [Link]
Linus stated that they can change as long as nobody complains that the change breaks their tools.
Quotes of the week Posted Feb 16, 2013 4:55 UTC (Sat) by viro (subscriber, #7872) [Link]
*snort*
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...
Quotes of the week Posted Feb 16, 2013 5:50 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
>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...
It's a userspace interface, after all.
>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.
So it's understandable that some developers might not want to even start interacting with the kernel community. For example, I'd added several ugly hacks in the OOM killer to get OOM event notification functionality for our internal project. It was done in a couple of weekends and it works just fine (except that the kernel often crashes by itself in OOM conditions, but that's another story). I don't even want to contemplate getting it into the mainline kernel - I lose all desire to do it just by reading about the past attempts.
Certainly, Linux is a very successful project. But it still might be worthwhile to look at the cases where there's a significant friction between kernel developers and their downstream users. Developers who speak in absolutes (like "I'll NAK all tracepoints") certainly don't help there.
Quotes of the week Posted Feb 20, 2013 4:25 UTC (Wed) by daniel (subscriber, #3181) [Link]
"Certainly, Linux is a very successful project."
Linux is indeed a successful project, arguably the most successful operating system in history. That does not mean that Linux is completely free of crap design or pathetically subpar implementations, or that certain high profile contributers never indulge in a little hubris from time to time.
Quotes of the week: "Hey ARM" Posted Feb 20, 2013 8:07 UTC (Wed) by speedster1 (subscriber, #8143) [Link]
Luc gives some pretty stunning news for anybody who cares about the future of free software on ARM... the first non-binary-blob ARM video driver is reaching a level of performance and rendering accuracy for practical use! Awesome achievement for a graphics driver (so far) entirely based on reverse-engineering.
Quotes of the week: "Hey ARM" Posted Feb 20, 2013 8:46 UTC (Wed) by Fowl (subscriber, #65667) [Link] Yes, this is amazing news! Mali is in /lots/ of devices.This talk from FOSDEM 2013 give some great background.
|
|||||||||||||