John Levon <[email protected]> writes:
> > and you get data presented in a way that is just a whole lot more
> > useful than the flat text files generated by oprofile.
>
> Building a GUI around OProfile would have been welcome, but you've
> chosen to re-implement the entire stack...
The only thing I have reimplemented is a kernel module. If you remove
all the #if 0'd lines in sysprof-module.c you are left with 296 lines
of code. So it's hardly a reimplementation of the entire stack.
And in fact I don't care all that much about the kernel module. The
things I really care about, the gui and the analysis code, do not
really have an equivalent in oprofile, and those two things are the
meat of the sysprof package:
[ssp@localhost sysprof]$ cat *.[ch] | wc -l
6706
My motive is not to duplicate oprofile - I basically don't care about
the kernel level mechanism as long as it can produce stack traces that
the GUI can interprete and analyse. In fact, one of the first times I
wrote about sysprof publicly [1], I said:
It seems to me that since oprofile probably reports more and
better data than my kernel module, we should try and get the
graphical presentation from sysprof to present oprofile data.
and I still think so, but it's a fairly substantial amount of work to
get rid of 296 lines of code.
Soren
[1] http://www.redhat.com/archives/fedora-desktop-list/2004-May/msg00041.html
-
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]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |