[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 16:01:35 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Oct 23, 2014 at 05:16:38PM +0200, Justus Winter wrote:
> this patch series adds introspection and tracing facilities to the
> Hurd servers using libports.  This isn't ready yet, but I'd like to
> give everyone a chance to complain early on.  Some notes:
> * I use Machs `Inherited Ports' mechanism to install a receive right
>   at a well-known location to serve introspection requests.  This is
>   by choice orthogonal to the usual mechanism used in the Hurd, as I
>   want it to be as universal as possible (e.g. I want to be able to
>   use it on the proc server).

I was initially not sure about that, since I prefer such things to be
explicit, but it's a very pragmatic choice that I approve.

> * Servers can label port buckets and classes, and install a function
>   that creates a human-readable description of an object.  This
>   information is then presented to the user doing portinfo
>   --query-process, a feature that is hinted to by a #if 0ed option in
>   portinfo.c.

Do we agree that, when saying "install a function", you mean providing
a RPC to answer introspection requests ? In which case this would mean
no reply if e.g. a deadlock occurs (although your work on reference
counting should make deadlocks less frequent). Not flaming here, just
making sure.

> * rpctrace can now attach to cooperating servers that just relay
>   messages to the tracing process.  To that end, a footer is attached
>   to the message to preserve original remote and local port, all
>   rights are turned into mere names, and the msgt_deallocate flag is
>   cleared so that out-of-band data isn't deallocated when we resend
>   the message.
> * A new library, libintrospection, handles the introspection port
>   registration and lookup, and the message wrapping/unwrapping.

Well, one big step towards lsof-like tools and easier debugging.

As usual, very good job :).

Richard Braun

reply via email to

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