On Sat, 2010-10-09 at 11:36 -0700, Linus Torvalds wrote: > On Sat, Oct 9, 2010 at 1:14 AM, Pierre Tardy <tardyp@xxxxxxxxx> wrote: > > On Sat, Oct 9, 2010 at 8:28 AM, Ingo Molnar <mingo@xxxxxxx> wrote: > >> > > > >> The thing is, Arjan is 100% right that a library for this is not a > >> 'solution', it's an unnecessary complication. > > Yes. sounds like overengineering. > > I also want to remind people that backwards compatibility should > always absolutely be the #1 priority. Using libraries to "hide" > differences is a totally moronic thing to do, because if you can do a > compatibility library with good interfaces, then damn it, the kernel > interface should already _be_ that good interface. > > And no, even if you interact purely with open source programs, the > backwards compatibility requirement doesn't go away. It's a damn pain > in the ass to have to recompile, and it means that you have a much > harder time mixing and matching, and just updating the kernel on top > of a standard distribution. > > So changing kernel interfaces that get exported to user space is > always a disaster. Anybody who _designs_ for that kind of disaster > shouldn't be participating in kernel development, because they've > shown themselves to be unable to understand the pain and suffering. > > Yes, we do it. Sometimes we change interfaces because not changing > them is too damn painful. But it should absolutely not be the design > model. The difference here compared to all other user interfaces, is that this interface has the sole purpose of showing what is happening inside the kernel. By saying that "we expose this to userspace, it must too be stable" is saying that all kernel internals that use trace events must never change. The big push against tracepoints/trace-markers/trace-events in the beginning was the fear that they will hinder kernel development because they become interfaces for users to see what is happening inside the kernel. When I wrote the interface, I put it in the debugfs system so people will know that this is a debug interface and can change without notice. Trace-events, unlike syscalls, may change depending on how you compiled the kernel. There's no guarantee that they will even exist on a system. If all trace-events are now stable ABI, then I suggest we stop adding any more events, and only add new ones to places that we do not expect to develop the kernel on anymore. Not sure what other solution there is. Trace points have been added way too freely, because any maintainer could add them to their system any way they felt like it. Now if they are frozen in stone, then the code that they expose must also be frozen. -- Steve _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
