[PATCH 17/36] privates: remove asserts that stop dynamic increasing of privates size.

[Dave Airlie]

On Mon, Jul 2, 2012 at 10:10 PM, Adam Jackson <ajax at nwnk.net> wrote:
> On 7/2/12 6:13 AM, Dave Airlie wrote:
>>
>> From: Dave Airlie <airlied at redhat.com>
>>
>> These asserts stop us increasing the size of privates after create screen
>> resources has been called, however for dynamic screens we need to be able
>> to increase private size as new drivers are loaded.
>>
>> In theory any object allocated by an older driver won't try and use newer
>> privates and any object allocated by a new driver should be okay.
>
>
> I... don't know if I believe this.  What objects did you find that had this
> property?
>

When I say older/newer driver I mean, loaded at startup, secondary
loaded drivers btw.

So far the modesetting driver is the only thing to exercise this, for
its offload stuff
it needs a pixmap private allocated, so I hit this problem and the
subsequent one.

Now if we allocate 20 pixmaps before the second driver is loaded,
they'll look like

PixmapHeader + privates + pixmap data. the privates will have been handed out
to the current list of keys register on PRIVATE_PIXMAP.

Now we bump the size, and we allocate pixmap 21,
PixmapHeader + privates + newpriv + pixmap data. Now the new driver
will never get to see pixmaps 1->20 since there is no way it should ever
see pixmaps allocated on the other drivers, and pixmap 21 and future
pixmap will work fine. If driver 2 unloads the pixmaps 21 etc should
all be destroyed, and in that case we probably should decrease the
total pixmap size again.

but privates have always longed remained something I run away screaming from
everytime I see them.

Dave.