Re: Hurd server introspection and tracing

[Justus Winter]

Quoting Richard Braun (2014-10-25 17:07:11)
> 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 ?

Well, never mind then :)

> 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 ?

I'm not sure.  I thought it was a clever idea, so that diagnostic
tools won't get blocked forever.  If there is a better alternative
please let me know.

Justus