Subject: Re: linux-next: add utrace tree - msg#00254

Previous Message by Date:

Re: linux-next: add utrace tree

On Thu, 21 Jan 2010, Andrew Morton wrote: > > ptrace is a nasty, complex part of the kernel which has a long history > of problems, but it's all been pretty quiet in there for the the past few > years. More importantly, we're not ever going to get rid of it. Quite frankly, judging my all past history we have ever seen in kernel interfaces, new an non-portable interfaces simply are never used. The whole question whether they are nicer or not is entirely immaterial. I'm personally very dubious that there are any merits to utrace that outweigh the very clear disadvantages: just another layer that adds a new level of abstraction to the only interface that people actually _use_, namely ptrace. But I haven't followed utrace. I doubt _anybody_ has, except for the utrace people themselves. Linus

Next Message by Date:

Re: linux-next: add utrace tree

Hi - On Thu, Jan 21, 2010 at 05:32:47PM -0800, Linus Torvalds wrote: > [...] > > To the extent the discussion is colored by the new features enabled > > from this refactoring, well, there is Oleg's list which may or may not > > have mentioned enabling systemtap's user-space probing. > > Let's face it, system tap isn't going to be merged, so why even bring it > up? It was certainly not meant to derail the discussion about the merits of utrace as a useful cleanup API in its own right, but rather to be an example of what kinds of things become straightforward in its presence. You may be aware of nascent efforts to bring the same uprobes infrastructure to perf. > Every kernel developer I have _ever_ seen agrees that all the new > tracing is a million times superior. [...] And that is fine. We believe there is plenty of space in the problem domain for different approaches. > ... considering how little the system tap people ever did for the kernel. Less passionate analysis would identify a long history of contribution by the the greater affiliated team, including via merged code and by and passing on requirements and experiences. We have been trying to share as much as you have been willing to take. While systemtap's current codebase may not (and need not) have a future inside the kernel, chances are good that improvements in common infrastructure will allow systemtap to shrink and change enough that the question becomes moot. - FChE

Previous Message by Thread:

Re: linux-next: add utrace tree

Hi - On Thu, Jan 21, 2010 at 05:05:41PM -0800, Andrew Morton wrote: > [...] ptrace is a nasty, complex part of the kernel which has a > long history of problems, but it's all been pretty quiet in there > for the the past few years. This leads one to expect that a > rip-out-n-rewrite is a high-risk prospect. So, quite reasonably, > one looks for a good reason for taking such risk. [...] To the extent the discussion is colored by risk avoidance, then the answer to that would consist of code reviews, and of course a look at the actual historical reliability of this code. While some might enjoy reminding us about the brief kerneloops incident in 2008, let's keep in mind that versions of this code has been deployed in fedora and rhel for several *years*, with millions of users. It's not some rickety experiment. To the extent the discussion is colored by the new features enabled from this refactoring, well, there is Oleg's list which may or may not have mentioned enabling systemtap's user-space probing. More details can be furnished on demand. Several of the use examples were constructed in good faith upon request from the kernel community asking for more and more. But what's enough? Who knows, really? - FChE

Next Message by Thread:

Re: linux-next: add utrace tree

Hi - On Thu, Jan 21, 2010 at 05:32:47PM -0800, Linus Torvalds wrote: > [...] > > To the extent the discussion is colored by the new features enabled > > from this refactoring, well, there is Oleg's list which may or may not > > have mentioned enabling systemtap's user-space probing. > > Let's face it, system tap isn't going to be merged, so why even bring it > up? It was certainly not meant to derail the discussion about the merits of utrace as a useful cleanup API in its own right, but rather to be an example of what kinds of things become straightforward in its presence. You may be aware of nascent efforts to bring the same uprobes infrastructure to perf. > Every kernel developer I have _ever_ seen agrees that all the new > tracing is a million times superior. [...] And that is fine. We believe there is plenty of space in the problem domain for different approaches. > ... considering how little the system tap people ever did for the kernel. Less passionate analysis would identify a long history of contribution by the the greater affiliated team, including via merged code and by and passing on requirements and experiences. We have been trying to share as much as you have been willing to take. While systemtap's current codebase may not (and need not) have a future inside the kernel, chances are good that improvements in common infrastructure will allow systemtap to shrink and change enough that the question becomes moot. - FChE