Werner Almesberger wrote:
> - if the probe target is an instruction long enough, replace it with
>a jump or call (that's what I think the kprobes folks are working
>on. I remember for sure that they were thinking about it.)
I heard about this years ago, but I don't know that anything cam
[ 3rd try. Apologies to Karim, Thomas, and Roman, who apparently also
received my previous attempts. For some reason, one of my upstream
DNS servers decided to send me highly bogus MX records. ]
Karim Yaghmour wrote:
> Might I add that this is part of the problem ... No personal
> offence inte
Werner Almesberger wrote:
>>From all I've heard and seen of LTT (and I have to admit that most
> of it comes from reading this thread, not from reading the code),
Might I add that this is part of the problem ... No personal
offence intended, but there's been _A LOT_ of things said about
LTT that
>From all I've heard and seen of LTT (and I have to admit that most
of it comes from reading this thread, not from reading the code),
I have the impression that it may try to be a bit too specialized,
and thus might miss opportunities for synergy.
You must be getting tired of people trying to red
Thomas,
Thomas Gleixner wrote:
> Yes, I did already start cleaning
>
> cat ../broken-out/ltt* | patch -p1 -R
:D
If it gives you a warm and fuzzy feeling to have the last
cheap-shot, then I'm all for it, it is of no consequence anyway.
And _please_ don't forget to answer this very email with
so
On Mon, 2005-01-17 at 18:57 -0500, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
> > If we add another hardwired implementation then we do not have said
> > benefits.
>
> Please stop handwaving. Folks like Andrew, Christoph, Zwane, Roman,
> and others actually made specific requests for changes
Thomas Gleixner wrote:
> If we add another hardwired implementation then we do not have said
> benefits.
Please stop handwaving. Folks like Andrew, Christoph, Zwane, Roman,
and others actually made specific requests for changes in the code.
What makes you think you're so special that you think yo
On Mon, 2005-01-17 at 15:34 -0500, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
> > Thats the point. Adding another hardwired implementation does not give
> > us a possibility to solve the hardwired problem of the already available
> > stuff.
>
> Well then, like I said before, you know what you
Thomas Gleixner wrote:
> Thats the point. Adding another hardwired implementation does not give
> us a possibility to solve the hardwired problem of the already available
> stuff.
Well then, like I said before, you know what you need to do:
http://www-124.ibm.com/developerworks/oss/linux/projects
On Sun, 2005-01-16 at 20:54 -0500, Karim Yaghmour wrote:
> If you really want to define layers, then there are actually four
> layers:
> 1- hooking mechanism
> 2- event definition / registration
> 3- event management infrastructure
> 4- transport mechanism
>
> LTT currently does 1, 2 & 3. Clearly
Thomas Gleixner wrote:
> This implies to seperate
>
> - infrastructure
> - event registration
> - transport mechanism
Like I said in my first response: we can't be everything for everbody,
the requirements are just too broad. ISO tried it with OSI. Have a
look at net/* for the result.
Current
On Sat, 2005-01-15 at 23:23 -0500, Karim Yaghmour wrote:
> > Well, that's really a core problem. We don't want to duplicate
> > infrastructure, which practically does the same. So if relayfs isn't
> > usable in this kind of situation, it really raises the question whether
> > relayfs is usable a
Hello Roman,
Roman Zippel wrote:
> On Sat, 15 Jan 2005, Karim Yaghmour wrote:
>>In addition, and this is a very important issue, quite a few
>>kernel developers mistook LTT for a kernel debugging tool, which
>>it was never meant to be. When, in fact, if you ask those who have
>>looked at using it
Hi,
On Sat, 15 Jan 2005, Karim Yaghmour wrote:
> In addition, and this is a very important issue, quite a few
> kernel developers mistook LTT for a kernel debugging tool, which
> it was never meant to be. When, in fact, if you ask those who have
> looked at using it for that purpose (try Marcelo
Hello Thomas,
I don't mind having a general discussion about instrumentation, but
it has to be understood that the topic is so general and means so
many different things to different people that we are unlikely to
reach any useful consensus. Believe me, it's not for the lack of
trying. More below
On Fri, 2005-01-14 at 15:22 -0800, Tim Bird wrote:
> but not 1) supporting infrastructure for timestamping, managing event
> data, etc., and 2) a static list of generally useful tracepoints.
Both points are well taken. Thats the essential minimum what
instrumentation needs.
I'd like to see th
16 matches
Mail list logo
