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

[PATCH,HURD] add ST_NOATIME

2013-05-09 Thread Pino Toscano
Hi, a simple patch to provide the GNU-specific ST_NOATIME flag for statvfs (which is already available on Linux). Once this patch is accepted, it will follow an Hurd patch to expose this attribute in libdiskfs-based translators (such as ext2fs and tmpfs). Thanks, -- Pino Toscano Hurd: add ST_N

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