[RFC] Making tracing/debugging of client requests easier

[Tiago Vignatti]

Hi Rami. Sorry for the late reply here.

On Fri, Aug 20, 2010 at 12:32:41PM +0200, ext Rami Ylim�ki wrote:
> 
> I'm starting work on improving the client tracking capabilities of X 
> server now. At this point I'd like to implement the client side PID 
> tracking first and leave more sophisticated information gathering out in 
> order to keep things simple. When the basic infrastructure for 
> collecting client PIDs is in place, it's easier to start making more 
> debugging information available (like a list of most recent requests 
> executed by the client).

nice! 

 
> I'll next describe how I'm going to implement this based on the RFC 
> review comments that I have received. The work is divided into a small 
> server side interface/extension

nitpick: I think "extension" isn't a good name for an internal X server
component. In X context, extension means things going through the wire
protocol.


> to provide client PIDs internally within 
> X server and modifications of some existing extension (XRES) to provide 
> the PID information for clients.
> 
> 
> 1. Server side implementation
> 
> 
> The IA extension provides some general purpose code for this that could 
> be extracted out. I think it's best to create a new internal 
> interface/extension (e.g. CI for client information) based on some code
> in IA, that would pretty much be used for sharing functionality and data 
> needed by other extensions. Other extensions like IA, XRES and SELINUX 
> (all need to map client to a PID) could then use this internal 
> interface/extension to get the client information that they need.

right.


> In 
> other words, the purpose of CI for the time being would be to only hold 
> common data and functionality needed in higher level extensions. 
> Currently this interface/extension doesn't require any new protocol 
> requests (XRES can be used),

I'm confused now. In the end of this email you said about XResQueryClientID...


> so the implementation doesn't have to 
> reside in Xext but can be located elsewhere in the server as well (maybe 
> in os?).

I don't know where. But registry code (dix/registry.c) is something that would
go together (and moved out from dix, because shouldn't belong there).


> At first, CI would offer only the PID and command line string for 
> clients. The following interface would be available only inside X server:
>     pid_t getClientPID(ClientPtr client);       /* 0 on error    */
>     const char *getClientCMD(ClientPtr client); /* NULL on error */
> 
> CI needs to initialize the PID and command line data in 
> ClientStateCallback, just like IA and SELINUX are doing it. When IA and 
> SELINUX are later modified to use CI to get the data, they need to get 
> notifications about its validity. Therefore CI has to provide new 
> callbacks for IA and SELINUX to indicate when a new PID is available and 
> when an old PID is about to be invalidated:
>      CallbackListPtr getClientDataAllocatedCB();
>      CallbackListPtr getClientDataReleasedCB();
> 
> IA and SELINUX need to register to these callbacks instead of/in 
> addition to ClientStateCallback. The first callback is called by CI 
> after new PID and command line data have been allocated for a client 
> (client connect). The latter one is called before the data is about to 
> be released (client disconnect). These callbacks indicate when 
> getClientPID and getClientCMD may succeed for local clients.
> 
> The actual mechanism for storing the data hasn't been mentioned yet but 
> using a client private makes again sense because that's what IA and 
> SELINUX are currently doing.
> 
> The patches for implementing this server side interface will be sent to 
> the mailing list soon, so please object as soon as possible if you don't 
> like the plans. When the CI interface patches have been integrated, we 
> are ready to modify XRES and SELINUX server side extensions to start 
> using it. Also IA can be modified to use the common code.
> 
> 
> 2. Client side implementation
> 
> 
> After the internal CI interface has been incorporated into X server, we 
> would have to introduce a new protocol call to get a client PID based on 
> its XID. The best candidates for the new call seem to be XFIXES or XRES. 
> I prefer XRES because its existing interface is already operating with a 
> lot on XIDs. A call querying information related to a XID would look a 
> little out of place in XFIXES. For example, XRES already provides 
> XResQueryClients for gettings the XIDs of clients. It makes sense to add 
> a call querying client based PID information into the same place.

XRes seems good for me.

 
> It was also discussed whether we need a general extensible call to ask 
> any client based properties. It turned out that there really isn't so 
> many properties that a general call would be needed. For the time being, 
> XRES is extended with only one specific protocol request:
>     ClientId XResQueryClientID(ClientIdType, XID client);
> 
> The patches for implementing the client side functionality and 
> documentation are sent after the server side implementation has been 
> reviewed by others.
> 
> 
> 3. Fixing clients
> 
> 
> Finally after the XRES modifications have been integrated, we'll start 
> sending patches against applications that would benefit from the new 
> request. At least xrestop and xnee come to mind right now.

\o/

Before you go and start to implement, would be nice to get a draft of the
XRes protocol diff, so everyone could take a look (just like Gesture Extension
and Xi 2.1 is being done).

Thanks for the work, Rami!

             Tiago