XSELinux and the new devPrivates

Keith Packard keithp at keithp.com
Thu Apr 29 14:48:04 PDT 2010


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?

--
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100429/7580a6cf/attachment.pgp>


More information about the xorg-devel mailing list