Re: Hurd server introspection and tracing

[Richard Braun]

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