Jon Smirl wrote:
On Sun, 31 Oct 2004 19:41:03 +0100, Thomas Hellström
<unichrome@shipmail.org> wrote:
  
 
     /* For now the mapping works by using a fixed size defined
     * in the SAREA header
     */
     if (sizeof(XF86DRISAREARec)+sizeof(VIASAREAPriv) > SAREA_MAX) {
     xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
             "Data does not fit in SAREA\n");
     return FALSE;
     }
     pDRIInfo->SAREASize = SAREA_MAX;
 
 So if locks are going to be squeezed in somewhere I'd either have to fit
them in the  XF86DRISAREARec or put them into every driver's private area.
    

You can't put them into  XF86DRISAREARec because of code like this:
drmInfo.sarea_priv_offset = sizeof(drm_sarea_t);
drm_sarea_t is the same structure as XF86DRISAREARec.

  
Wouldn't this severely brake backwards binary compatibility with dri clients compiled with the old size of drm_sarea_t?

Are the locks generic enough that all hardware needs them?
  
The idea was that if such an implementation exists and works, It could be
used by any driver that found a potential gain.

The generic part would be just a number of locks sitting there if somebody wanted
to use them. Each driver would have to assign a certain meaning to each lock used.
For each lock there would be a way to resolve contention and to clear the lock if the holder dies.

Still I'd have to make a working trial implementation for the VIA driver. The important thing at this stage is to get the basic thoughts right.

/Thomas

You can extend VIASAREAPriv (drm_via_sarea_t) without messing up the
above check. drm_via_sarea_t is much smaller than SAREA_MAX.

You will still need to negotiate an interface version since some
servers will know about the extended locks and others won't. You'll
have to revert to the big lock if all of the clients don't know about
the new lock scheme.

  
/Thomas