Hi! On Thu, 9 May 2013 01:55:56 +0200, Samuel Thibault <samuel.thiba...@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
pgpo5E5PyFEKN.pgp
Description: PGP signature
