Here are a few comments about how I see the new devPrivates scheme working with XSELinux. Note that the current implementation is sub-optimal when XSELinux is enabled -- the XSELinux private keys get initialized late in the game and end up increasing the size of all of the private records with big chunks of wasted space between their highest other private index and the XSELinux private index.
The new privates scheme allows for some of the private keys to remain 'global', useful in all objects with privates. That's how the old private implementation worked, so this provides an obvious replication of that functionality. It's not what XSELinux actually needs though. XSELinux uses privates in: client window pixmap gc cursor colormap device extension selection property It doesn't need privates in screen cursor_bits dbe_screen dbe_window damage glyph glyphset picture So, the first obvious optimization is to simply not provide private space for 'PRIVATE_ALL' in these objects. Renaming this 'PRIVATE_XSELINUX' might be prudent though. The second optimization should be to sort the PRIVATE_ALL data below all of the other private data. That way you'll get the shared PRIVATE_ALL fields first in privates with the per-object data stacked on top without any gaps. Because we've got pointers to every key, it should be easy to adjust the offsets when a PRIVATE_ALL key is registered. It's convenient that XSELinux doesn't need a screen private as that is the only serious special case in the current privates code. Finally, the subjectKey is only needed in clients and devices, and in each case the XSELinux code knows which object it is dealing with. So, creating separate keys for each of those objects would save space in all of the other objects. With those changes, the XSELinux privates should be more efficient than they are today. However, it seems like someone who can actually run the code should be involved in the process. Should I code some stuff up and let others get it working? Or just sit around waiting for someone else to submit fixes? -- [email protected]
pgpSJp1eBjApK.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
