72
Christoph Hellwig <[email protected]> wrote on 21/03/2006 12:15:50:
> > I think you'll find it happened the other way round. Sun openly
references
> > my white papers. They even stole the name of an ancestor to kprobes.
But
> > who cares, it not relevant or particularly interesting whether the
chicken
> > or the egg came first.
>
> I know your papers, too. In fact dprobes' RPN program downloads are a
far
> better design than systemtap's generation of kernel code. it's a pity
that
> you gave up on dprobes instead of applying the required work to it and
> integrate it with other bits of a tracing framework.
Fascinating, gave up on dprobes, not really! I thought the kernel community
felt it was the wrong implementation. We did remove all the RPN stuff to a
loadable kernel module and left behind a minimal API set - krpobes - which
comprised the kernel probing mechanism, user-space probes extensions and
watchpoint probes extension. The result was identical functionality to the
original dprobes but with a minimal patch to the mainline kernel. But in
addition it provided a very much more generalized interface that would
allow other utilities to exploit the kernel interface, which they have. In
this sense dprobes still exists and can be used on top of krpobes. What
would you recommend be retained from dprobes? And what further
modifications?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
