Fixing devPrivates

[Keith Packard]

On Thu, 29 Apr 2010 17:34:47 +0300, Tiago Vignatti <tiago.vignatti at nokia.com> wrote:

> Reviewing your proposal made me think if we really need devPrivates mechanism
> at all.

Yeah, some of my patch was actually to remove devPrivate usage in DIX.

> It only exists to not change ABI all the time on data structures. But hey, is
> this a _real_ problem? I mean, for who cares about ABI, we have a way to track
> the control changes just going to xf86Module.h and bumping ABI_*.

The key use of devPrivates is to hold driver- and extension- specific
data associated with core data structures. Because each driver may need
slightly different data, it's very useful to have a general place to
hold that which is managed with the same lifetime as the underlying
object.

In the case of extensions, we gain the benefit of not paying for the
extension unless it's activated. Many distributions build with SELinux
support, but want the option of eliminating the cost of that when it
isn't in use.

> There's also the readability of the code which is really really really
> terrifying using such mechanism.

Agreed.

> So why do not remove entirely devPrivates?

We should try to reduce their use, that's for sure. The core server
shouldn't be using privates at all, even hw/xfree86 should get a serious
look.

> I started one standalone Xorg and here are the results:
> 
> - with current devPrivates: 5008 kB
> - with new proposed devPrivates: 5032 kB

Ok, sounds like I need to do some actual measurements then.

Note that your (irc reported) change to the xf86cmap private will have a
huge impact on memory usage as it is the only PRIVATE_ALL in
use. Reworking PRIVATE_ALL to not cost so much seems fairly important
once we have the basic mechanism working.

-- 
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/2f362287/attachment.pgp>