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