On 4/29/10 8:59 AM, Keith Packard wrote:
Most of this should be fairly obvious, the one exception is probably the
'type' value. This is a fixed enumeration of all possible data
structures holding devPrivates. Let me make that a bit louder.
I AM PROPOSING TO ELIMINATE THE ABILITY TO USE THE DEV PRIVATES
INFRASTRUCTURE IN DATA TYPES DEFINED OUTSIDE THE CORE SERVER.
Almost two years ago I started looking into this very same issue (and
even wrote some code). My idea was the DevPrivate key to become a simple
offset into an array, much like your approach. However, I allowed keys
to be registered even after the first object had been created. And I
even had an API to register new object types (unlike your fixed
DevPrivateType enum).
My DevPrivateRec was basically a structure with 'int size; void *ptr',
and PrivateSet/Get functions would check if the ptr size was big enough
and realloc() it if needed. The only disadvantage I see in that is the
overhead of an occasional realloc(). Is there any other reason you chose
to allocated the array only once when the object is created?
Another difference, albeit a minor one, was that I kept my
'DevPrivateRec' structures allocated inside privates.c instead of
scattered around the source files. That allowed me to easily dump
statistics about which privates are used in which objects etc. I thought
that would be a useful feature for debugging purposes, or to simply see
how much memory is being used where.
tom
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
