This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Notes from stap meeting 20060803


These utrace issues are not really specific to systemtap, though of
course they are important if utrace will be used by systemtap, and
I'm glad for anyone's involvement in the utrace work.  Anyone who is
also involved in the Frysk project will be having the same
discussions with me over there.

> some effort testing utrace on s390

David Wilder and I have been working on this.  It looks like we
broke things again the other day, but things have been substantially
working already.  The main work is done.  The code is enabled in the
rawhide s390 kernel.

> need priorities  in notify structure maybe put into utrace

This is probably a reasonable addition to the interface.  I prefer
to wait until there are actually two utrace engines in the world
that can concretely vie for priority before implementing the solution.

> any request to test utrace on ppc64 from redhat?

I have a Mac G5 with Fedora and so can debug on this platform
myself, and tested and debugged the port when I did it.  But I have
not done any regular regime of testing.  I haven't tested other
kinds of ppc64 machines, or configurations with more than 2 CPUs
(nor fewer).  I have not done any heavy stress-testing.  Having
someone concerned with each platform doing regular testing on
the machine configurations of interest is certainly worthwhile.

> someone (anil?) is working on ia64 utrace

Anil Keshavamurthy and Bibo Mao have begun work on this, after some
administrative delay beyond their personal control.  We are still hashing
out the best implementation approaches for ia64, but it seems to be coming
along now.

> Need to agree on which tests to run for utrace testing

As yet the main means of regression and stress testing for the core
code is via things that use ptrace.  gdb is the only canonical free
thing with a large test suite stressing ptrace, of which I am aware.
I can separately supply technical info on using gdb to test the
kernel behavior, for those who are going to do it.  I expect that we
will get some automated form of this put together for the Fedora
test system, but I don't know any details about that yet.  Right now
I can give instruction for developers to do one-off testing by hand.

I have a small test suite specifically for utrace.  That will get
specific regression cases as they come up, and will eventually get
to be close to exhaustive, but will probably not be stressful.  So
far it doesn't test very much, and the gdb testing is far more useful.

If other folks have existing applications (nonfree or whatever) that
exercise ptrace, then regression testing those on current rawhide
kernels should by all means be done.

In the long run, a lot of serious stress testing would be very
valuable.  That is, running numerous gdb test suites and other such
stressers simultaneously, doing that and other miscellaneous
workloads while running some pervasive, noninvasive tracing modules
monitoring those processes, etc.  

> what is plan to get utrace upstream?

I am working through this with upstream kernel folks.  Getting the
arch work still in progress into good shape is an important factor.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]