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: tapset quality


Frank Ch. Eigler wrote:
Hi -

I am concerned that the quality of our tapsets is failing to improve,
and in some cases we regress in terms of documentation and testing
coverage.  This cannot continue.

Agreed! It would be useful to clearly state how we measure tapset quality. I attempted to capture some of that in the Tapset Developer's Guide, but I'm sure we can come up with more.



There have been suggestions of formal code reviews on the mailing list to help improve the situation. Perhaps it is time to consider this idea more seriously.

I think it's time. More people with varying degrees of systemtap experience are checking in code now. It would be beneficial to use a formal review process. Some of that is happening already, but it's not being done consistently.


Perhaps it is simly a matter of reminding people
to please reread and follow the guidelines in src/HACKING and
src/tapset/DEVGUIDE.

How about requiring that all tapsets have owners/maintainers? It seems like tapsets only get attention based on interest and when a test fails. A tapset like NFS gets little attention because it has no tests and no owner. I filed a bug against the missing NFS tests some time ago, but we still have no tests. We can ask people to reread and follow the guidelines, but that doesn't help if no one is responsible for applying those guidelines to a particular tapset.




There are some *technical* means we can take to help the situation.
Please share your ideas too.

Will Cohen's script coverage code in the translator lets one identify
which parts of the tapset are not even compiled.  We need someone to
bootstrap an ongoing process to take this data and create some buildok
tests for as many of them as possible.  Any volunteers, please?  If
the coverage generator is fast enough now to keep it on, I'll change
the test suite to report on its own coverage at the conclusion of a
test run.

Automatically extracted documentation has come up a few times, and
Mike Mason kindly prototyped this a few months ago.  I promised to
make an alternative proposal, so here it is.  Instead of using an
external tool to process script source files, how about extending the
translator to consume documentation strings - like emacs-lisp?  We
could extend the grammar to accept string literals in a few more
places.  How about:

probe foo "DESCRIPTION-STRING"
          "MORE-BLAH" {
  var "DESCRIPTION" = EXPR
}
function bar "DESCRIPTION" (var:long "DESCRIPTION" , ...) { }
global baz "DESCRIPTION"


Hmm... I like the idea of extending the translator to interpret documentation strings, but embedding descriptions in the middle of assignment statements doesn't seem right. I'll comment more on this later.


Mike

The translator would associate the description strings with the
objects (probes/functions/variables).  It could synthesize additional
ones for e.g. dwarf probes, to provide metadata such as PC addresses,
probe alias chains.  Most importantly, with a new option or two, the
translator could spit out the documentation in an organized fashion
(on the command line, kind of like dtrace -l but better; as man pages
for installation).




- FChE


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