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 _______________________________________________ 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