On Sat, Oct 25, 2014 at 04:57:18PM +0200, Justus Winter wrote: > No, I was referring to these two new functions: > > /* Label BUCKET with LABEL. */ > void ports_label_bucket (struct port_bucket *bucket, const char *label); > > /* Label CLASS with LABEL. Use DEBUG_INFO to format human-readable > information about a given object belonging to CLASS into an buffer, > or the default formatting function if DEBUG_INFO is NULL. */ > void ports_label_class (struct port_class *class, const char *label, > error_t (*debug_info) (const void *, char *, > size_t)); > > This information is made available using the new > `hurd_port_debug_info' RPC: > > /* Return a compact, human-readable description of the object related > with the receive right NAME. > > This description is meant for debugging purposes and should include > relevant internal state. If possible, it should include > information that is meaningful in other contexts (like a file name, > or the inode number). > > Return EINVAL if NAME does not denote a receive right managed by > the port-to-object mapper. */ > routine hurd_port_debug_info ( > introspection: mach_port_t; > name: mach_port_name_t; > waittime timeout: natural_t; > RPT > out debug_info: string_t);
Hum, but isn't that what I described ? On the other hand, I can see a timeout at the client side. Why a timeout instead of letting the user interrupt the process, or automated tools use a higher-level monitoring scheme ? -- Richard Braun
