froggy status 2008-09-09

[Chris Moller]

Last week:

    More or less completed migrating to Roland's new utrace API--in test
    mode now.  I've made no effort to keep froggy compatible with both
    the new API and the old one--the new version won't compile or run
    with other than a rawhide kernel.  Since I've no idea when
    F10--presumably what's rawhide now--or the more-or-less equivalent
    RHEL will be available, I've been reluctant to commit changes to the
    existing froggy, thereby breaking it for F9/RHEL5 kernels.   I guess
    I could just tag the old-API version, but I think it might be easier
    all around if I just created a new froggy2--especially if it becomes
    necessary to backport functional changes made for the new API back
    to the original API version.

Next week.

       1. Refactor relevant parts of froggy-test.c--those parts dealing
          directly with the module interface--to a callable interface
          lib.  This will hide some of the messy and/or dangerous bits,
          e.g., getting out of sync in the transport stream.  I think it
          was Frank who once expressed a concern for maintaining access
          to the file descriptor for use in select()/poll(), and I'll
          make sure that happens, but I do want to have a clean i/f.
       2. Hack together an strace-like demo that exercisees
          report_syscall callbacks.
       3. Hack together a graphical pstree-like utility that exercises
          life-cycle callbacks (report_clone, report_exec, report_death,
          report_reap).   This, BTW, brings up an exposure: for such a
          utility or, for that matter, an original-frysk whole-system
          monitor thingy, user-space processes probably have to be able
          to attach system processes, but it would be a remarkably bad
          idea for them to be able to control those processes.  My
          thought was to add some code that will limit user-space (or
          perhaps all) clients to only passively attaching system
          processes, letting them get report_* callbacks, but inhibiting
          any action--quiescing, tinkering with signals, etc.--that
          would actually affect the processes.

    Comments welcome.

-- 
Chris Moller

  I know that you believe you understand what you think I said, but
  I'm not sure you realize that what you heard is not what I meant.
      -- Robert McCloskey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/utrace-devel/attachments/20080909/32ff921d/attachment.sig>