lkml.org 
[lkml]   [2010]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-next: add utrace tree


On Thu, 21 Jan 2010, Frank Ch. Eigler wrote:
>
> 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.

The reason I'm so passionate is that I dislike the turn the discussion was
taking, as if "utrace" was somehow _good_ because it allowed various other
interfaces to hide behind it. And I'm not at all convinced that is true.

And I really didn't want to single out system tap, I very much feel the
same way abotu some seccomp-replacement "security model that the kernel
doesn't even need to know about" thing.

So don't take the systemtap part to be the important part, it's the bigger
issue of "I'd much rather have explicit interfaces than have generic hooks
that people can then use in any random way".

I realize that my argument is very anti-thetical to the normal CS teaching
of "general-purpose is good". I often feel that very specific code with
very clearly defined (and limited) applicability is a good thing - I'd
rather have just a very specific ptrace layer that does nothing but
ptrace, than a "generic plugin layer that can be layered under ptrace and
other things".

In one case, you know exactly what the users are, and what the semantics
are going to be. In the other, you don't.

So I really want to see a very big and immediate upside from utrace.
Because to me, the "it's a generic layer with any application you want to
throw at it" is a _downside_.

Linus


\
 
 \ /
  Last update: 2010-01-22 03:39    [W:0.228 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site