[PATCH 0/3] xserver: Client ID tracking

Rami Ylimäki rami.ylimaki at vincit.fi
Tue Aug 31 01:35:31 PDT 2010


  On 08/30/2010 09:11 PM, Mark Kettenis wrote:
>> From: =?utf-8?q?Rami=20Ylim=C3=A4ki?=<rami.ylimaki at vincit.fi>
>> Date: Mon, 30 Aug 2010 16:29:30 +0300
>>
>> Hi,
>>
>> These patches add a simple framework for determining client related
>> IDs such as PID and process name within X server. After these changes
>> have been reviewed and accepted, the XRes extension will be modified
>> to use the framework and provide client ID information for clients
>> with a new protocol request.
> How useful is this really, given that information from remote clients
> isn't available, or at least cannot be trusted?

We have used this kind of code repeatedly in X server to identify local 
clients that are behaving badly either by allocating too much memory and 
resources in the server or by executing deprecated requests. Maintaining 
private code to do this simply doesn't make sense anymore. Having the 
code in X server by default would speed up development and debugging 
time for us and also ease our maintenance burden.

We want to make also it possible to identify local clients outside of X 
server. That's why we need a new request to query the PID information 
reliably. It should be possible to easily track down problems on a 
release version of a distribution without having to recompile a debug 
version of X server first. Ultimately we want to use cnee to identify 
clients that are executing deprecated requests and xrestop to identify 
clients allocating too much resources. Currently there is no reliable 
way to do this.

You are right in that we mainly care about local clients, because in 
practice on our system all clients will be local. But I think that 
having a good way to identify local clients is still very important even 
though we wouldn't be able to reliably identify remote clients. We don't 
mind if information about clients can't be trusted in a rogue 
environment, because the framework would be used mainly to improve the 
overall system quality and as an development aid, not as a secure client 
framework for finding out which clients are trusted.

-- Rami



More information about the xorg-devel mailing list