[RFC] Making tracing/debugging of client requests easier

[Rami Ylimäki]

  Hi,


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).

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 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. 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), so the implementation doesn't have to 
reside in Xext but can be located elsewhere in the server as well (maybe 
in os?).

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.

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.


Thanks for any comments,
        Rami