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

2013-05-10 Thread Richard Braun
On Fri, May 10, 2013 at 05:07:52PM +0200, Richard Braun wrote: > On Thu, May 09, 2013 at 07:20:39PM +0200, Samuel Thibault wrote: > > Thomas Schwinge, le Thu 09 May 2013 18:42:18 +0200, a écrit : > > > Then, to what extent are the proposed new RPCs just a specialized > > > variant of the generic "p

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

2013-05-10 Thread Richard Braun
On Thu, May 09, 2013 at 07:20:39PM +0200, Samuel Thibault wrote: > Thomas Schwinge, le Thu 09 May 2013 18:42:18 +0200, a écrit : > > 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, > >

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

2013-05-09 Thread Samuel Thibault
Thomas Schwinge, le Thu 09 May 2013 18:42:18 +0200, a écrit : > 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, > , > in pa

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

2013-05-09 Thread Thomas Schwinge
Hi! On Thu, 9 May 2013 01:55:56 +0200, Samuel Thibault 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

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

2013-05-09 Thread Barry deFreese
Gentlemen, I don't want to get into the political or technical merits but here is an updated patch that works. I will let you decide what to do with it. :) Thanks, Barry diff --git a/include/mach/gnumach.defs b/include/mach/gnumach.defs index 7331334..b26be96 100644 --- a/include/mach/gnumac

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

2013-05-09 Thread Samuel Thibault
Samuel Thibault, le Thu 09 May 2013 01:55:56 +0200, a écrit : > 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

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

2013-05-08 Thread Samuel Thibault
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 s

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

2013-05-08 Thread Roland McGrath
> 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. Y

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

2013-05-08 Thread Samuel Thibault
Roland McGrath, le Wed 08 May 2013 16:27:53 -0700, a écrit : > > But we can't really ask the proc server from the kernel debugger. > > There are lots of things you can't do from the kernel debugger. > That doesn't mean that more state in the microkernel is the way > to debug. When it helps a huge

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

2013-05-08 Thread Roland McGrath
> But we can't really ask the proc server from the kernel debugger. There are lots of things you can't do from the kernel debugger. That doesn't mean that more state in the microkernel is the way to debug.

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

2013-05-08 Thread Samuel Thibault
Roland McGrath, le Wed 08 May 2013 15:34:59 -0700, a écrit : > > So the kernel can tell what a task is in, e.g. show tasks command, in > > memory object statistics, etc. Without this it is hard to inspect the > > whole system state without divining what task is what process. > > The proc server e

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

2013-05-08 Thread Roland McGrath
> So the kernel can tell what a task is in, e.g. show tasks command, in > memory object statistics, etc. Without this it is hard to inspect the > whole system state without divining what task is what process. The proc server exists to provide that mapping.

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

2013-05-08 Thread Samuel Thibault
Roland McGrath, le Wed 08 May 2013 14:59:47 -0700, a écrit : > What for? > If you want something like this, why does it belong in the microkernel? So the kernel can tell what a task is in, e.g. show tasks command, in memory object statistics, etc. Without this it is hard to inspect the whole syst

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

2013-05-08 Thread Roland McGrath
What for? If you want something like this, why does it belong in the microkernel?

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

2013-05-08 Thread Barry deFreese
Hi folks, I am trying to get a test environment going to test this but in the meantime if any of you care to review, here is a patch to add task_set_name() and task_get_name() RPCs to gnumach. Thanks! Barry diff --git a/include/mach/gnumach.defs b/include/mach/gnumach.defs index 7331334..b26b