On 08/30/2010 09:11 PM, Mark Kettenis wrote:
From: =?utf-8?q?Rami=20Ylim=C3=A4ki?=<rami.ylim...@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

_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to