[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC for patch to add task_{set,get}_name RPC
From: |
Thomas Schwinge |
Subject: |
Re: RFC for patch to add task_{set,get}_name RPC |
Date: |
Thu, 9 May 2013 18:42:18 +0200 |
User-agent: |
Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu) |
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
- Re: RFC for patch to add task_{set,get}_name RPC, (continued)
- Re: RFC for patch to add task_{set,get}_name RPC, Roland McGrath, 2013/05/08
- Re: RFC for patch to add task_{set,get}_name RPC, Samuel Thibault, 2013/05/08
- Re: RFC for patch to add task_{set,get}_name RPC, Roland McGrath, 2013/05/08
- Re: RFC for patch to add task_{set,get}_name RPC, Samuel Thibault, 2013/05/08
- Re: RFC for patch to add task_{set,get}_name RPC, Roland McGrath, 2013/05/08
- Re: RFC for patch to add task_{set,get}_name RPC, Samuel Thibault, 2013/05/08
- Re: RFC for patch to add task_{set,get}_name RPC, Roland McGrath, 2013/05/08
- Re: RFC for patch to add task_{set,get}_name RPC, Samuel Thibault, 2013/05/08
- Re: RFC for patch to add task_{set,get}_name RPC, Samuel Thibault, 2013/05/09
- Re: RFC for patch to add task_{set,get}_name RPC, Barry deFreese, 2013/05/09
- Re: RFC for patch to add task_{set,get}_name RPC,
Thomas Schwinge <=
- Re: RFC for patch to add task_{set,get}_name RPC, Samuel Thibault, 2013/05/09
- Re: RFC for patch to add task_{set,get}_name RPC, Richard Braun, 2013/05/10
- Re: RFC for patch to add task_{set,get}_name RPC, Richard Braun, 2013/05/10