Re: RFC for patch to add task_{set,get}_name RPC

[Thomas Schwinge]

Hi!

On Thu, 9 May 2013 01:55:56 +0200, Samuel Thibault <samuel.thibault@gnu.org> 
wrote:
> Roland McGrath, le Wed 08 May 2013 16:47:24 -0700, a écrit :
> > > When it helps a huge lot to debug some things, it surely is a way to
> > > debug.  I was able to debug quite a few spurious port deallocations as
> > > soon as I was able to print from the kernel which process was doing
> > > it.  I don't see how to do the same kind of debugging through the proc
> > > server.
> > 
> > You can implement some debug-only logging that shows you the mappings you
> > want to see.
> 
> But the point is that I don't know which mapping I want to see.  I just
> happen to notice from the kernel that a given task does a erroneous
> thing.  From there, how to continue debugging without knowing which
> userland process was doing that?

I understand correctly that the microkernel is just the keeper but itself
has no use for the information set with task_set_name.  Thus, that
information is free-form, for any kind of debugging/logging only (the
intent being to set it to the executable's filename that constitutes a
task).  Then, to what extent are the proposed new RPCs just a specialized
variant of the generic "port info" RPC that we have been musing about,
<http://darnassus.sceen.net/~hurd-web/open_issues/translate_fd_or_port_to_file_name/>,
in particular the log from IRC, freenode, #hurd, 2013-03-07?  To me it
would make sense to follow the latter route, so be able to store with
every generic port some bits of debugging/logging information (perhaps
literally, like the proposed 32 characters, or perhaps switch to
dynamically allocated upon setting the information and released once the
port itself is deallocated), and that could then be tied to some new
--enable-debugging configure switch (or simply pinned to --enable-kdb),
which, if not specified will turn these into MIG_BAD_ID stubs.


Grüße,
 Thomas

pgpcHr0tYzes_.pgp
Description: PGP signature