New handling of privates [was: Re: xf86-video-intel 2.5 release planning]

[Tomas Carnecky]

Eamon Walsh wrote:
> Attached is a privates.c where dixLookupPrivate has been reduced to a 
> test + array index.
> The problem is that it needs to store the array index into the memory 
> referenced by the "key" pointer.  Currently there is no requirement on 
> "key" other than being a unique value.
> 
> So committing this requires some refactoring first.  Basically turning 
> "static DevPrivateKey foo = &foo" into "static int blah; static 
> DevPrivateKey foo = &blah".  After it's done it can be committed.  Maybe 
> even backported.

The way I read your code, each DevPrivateKey is a unique index, no two 
keys can can have the same index, is that correct? While I corrected the 
DevPrivateKey usages throughout the code, I saw that many extensions 
allocate one private key per object type (eg. one key for screens, one 
key for windows, one key for pixmaps etc). There are more then 160 (just 
a quick grep) private keys, so there is the possibility that each 
PrivateRec array will be 160 pointers long and only sparsely occupated.

Compiz does the private handling nicely, it keeps a per-object-type list 
of indices. But that approach would have to change large parts of the API.

tom