SoC tasks (was: Re: rpctrace improvement for the Google Summer of Code)
Hi, On Thu, Mar 22, 2007 at 02:16:20AM +0100, Thomas Schwinge wrote: > On Wed, Mar 21, 2007 at 08:09:31AM +0100, [EMAIL PROTECTED] > wrote: > > However, I didn't propose this so far, as tschwinge seems to have a > > perfectly opposite opinion than me on what are suitable tasks and > > what aren't. > > Huh, what's that? > > In fact, what I told you was that I wouldn't know how to wrap what you > suggested into a concise wording for a GSoC task, so that someone who > isn't familiar with all those Hurd details would know what this task > was about. I then asked you to come up with such a wording to then > install that task, but, so far, you didn't respond to that plea and > instead now accuse me to not consider your ideas worthwhile? This wasn't meant to be an accusation. Sorry if I made it sound like one. The point is that various comments you made on my proposal as well as others, made me conclude that you have totally different opinions about what is appropriate for a SoC task. As for that other proposal, your intial comment sounded very much like you do not consider it a suitable task at all; when I asked (on IRC) why you think so, you suggested I write something up, but didn't follow up on my questions. I'm still not sure what you really want, when talking about "concise wording". I don't know how the proposals are presented to the students. When we gathered ideas for GGI, we had a single sentence/wordgroup as title for each task, and one or more paragraphs explaining it: Introducing the relevant concepts, pointing out what is missing or what could be improved, and explaining what the student is supposed to do specifically. Anyways, I guess it's too late for this year anyways. Maybe next year. (Yeah, my fault -- I should have made the proposal much earlier.) -antrik- ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: rpctrace improvement for the Google Summer of Code
Hi, On Thu, Mar 22, 2007 at 10:50:49AM +, Tim Retout wrote: > 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. Well, it depends on the student. I can imagine that *some* would be able to create such a tool in three months, so I think it's not wrong to list it as a possibility -- as long as it's clear that the student is also free to choose some of the simpler suggestions. -antrik- ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: rpctrace improvement for the Google Summer of Code
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
Re: rpctrace improvement for the Google Summer of Code
Hello! On Wed, Mar 21, 2007 at 08:09:31AM +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. > > However, I didn't propose this so far, as tschwinge seems to have a > perfectly opposite opinion than me on what are suitable tasks and what > aren't. Huh, what's that? In fact, what I told you was that I wouldn't know how to wrap what you suggested into a concise wording for a GSoC task, so that someone who isn't familiar with all those Hurd details would know what this task was about. I then asked you to come up with such a wording to then install that task, but, so far, you didn't respond to that plea and instead now accuse me to not consider your ideas worthwhile? That doesn't fit. I mean, these are tasks that require a really intimate knowledge of how the components of a Hurd system interact with each other. That's not something where an ``average student'' could make any sense of. That's at least my opinion on this matter. Regards, Thomas signature.asc Description: Digital signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: rpctrace improvement for the Google Summer of Code
Hi, On Tue, Mar 20, 2007 at 11:16:13PM +0100, Richard Braun wrote: > Here is a proposal for a Google Summer of Code project : rpctrace is > one of the most useful debugging tools on the Hurd. It could help a > lot in understanding some of the bugs of the system. Unfortunately, it > can hardly be used to debug some essential translators because it > cannot be used to trace already running tasks. I don't know exactly > how this could be done, so I'm asking : is this technically feasible > as a GSoC project ? Actually, I already thought of something like this, though I would suggest making it a more generic task: Improving Hurd-specific debugging tools. 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. However, I didn't propose this so far, as tschwinge seems to have a perfectly opposite opinion than me on what are suitable tasks and what aren't. -antrik- ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: rpctrace improvement for the Google Summer of Code
At Tue, 20 Mar 2007 23:16:13 +0100, Richard Braun <[EMAIL PROTECTED]> wrote: > > [1 ] > [1.1 ] > Hello, > > Here is a proposal for a Google Summer of Code project : rpctrace is one > of the most useful debugging tools on the Hurd. It could help a lot in > understanding some of the bugs of the system. Unfortunately, it can > hardly be used to debug some essential translators because it cannot be > used to trace already running tasks. I don't know exactly how this could > be done, so I'm asking : is this technically feasible as a GSoC project ? It seems to me that this can be achieved transparently to the monitored task by using the standard Mach interfaces for a task port (you need the task port for debugging anyway). There are extensive interfaces to query and manipulate the port name space of a process, and that should allow you to retrieve all ports, create wrappers for them and insert the wrapper objects into the monitored task. You should also be able to undo the monitoring by reversing the process. Care must be taken to suspend the process while doing this, and also to modify the number of references appropriately. Please see the sections "Port Names", "Port Rights", "Ports and other Tasks" in the GNU Mach Reference Manual (gnumach/doc/mach.texi). Note that this will not allow you to debug all essential translators. Depending on your environment, debugging a critical server used by rpctrace itself indirectly would likely be hazardous. Irregardless of that, being able to attach and remove a monitor to a process at runtime is certainly useful. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
rpctrace improvement for the Google Summer of Code
Hello, Here is a proposal for a Google Summer of Code project : rpctrace is one of the most useful debugging tools on the Hurd. It could help a lot in understanding some of the bugs of the system. Unfortunately, it can hardly be used to debug some essential translators because it cannot be used to trace already running tasks. I don't know exactly how this could be done, so I'm asking : is this technically feasible as a GSoC project ? -- Richard Braun signature.asc Description: Digital signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
