[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hurd server introspection and tracing

From: Richard Braun
Subject: Re: Hurd server introspection and tracing
Date: Sat, 25 Oct 2014 17:07:11 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]