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
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
