On Wed, 2007-03-21 at 08:09 +0100, [EMAIL PROTECTED] wrote: > Implementing the possibility of attaching rpctrace to running processes, > is one possible thing that could be done. But there are many others, > like adding ability to rpctrace to show the names of the parameters > (needs rpctrace and mig changes); adding some tool(s) that allow logging > the interactions between several processes, to help understanding > complex problems and/or doing system profiling; interactive RPC > debugging tools (possibly as GDB extension); and so on.
These are all good ideas. The difficulty is, the SoC lasts only three months, and "most students need the first month just to get their bearings and actually start producing code".[0] It's important to choose a project/set of tasks that fit within that timeframe. I personally would be hesitant about trying to write a whole new debugging tool over the summer - even with a good mentor. The rpctrace ideas are my personal favourites at the moment - they have well-defined ends - you know when and whether you've finished. The only question then is, can you finish in eight weeks? I'm trying to get a feel for how large these tasks are, before committing to any of them. [0] http://code.google.com/p/google-summer-of-code/wiki/AdviceforMentors -- Tim Retout <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
