[prev in list] [next in list] [prev in thread] [next in thread]
List: dri-devel
Subject: Re: Multiple hardware locks
From: Thomas_Hellström <unichrome () shipmail ! org>
Date: 2004-10-31 22:34:32
Message-ID: 41856878.3090505 () shipmail ! org
[Download RAW message or body]
Jon Smirl wrote:
>On Sun, 31 Oct 2004 22:54:25 +0100, Thomas Hellström
><unichrome@shipmail.org> wrote:
>
>
>>Wouldn't this severely break backwards binary compatibility with dri clients
>>compiled with the old size of drm_sarea_t?
>>
>>
>
>You can't put them in drm_sarea_t. There is definitely code that will
>break if you do. I don't see anyway to extend drm_sarea_t without
>causing binary incompatibility. drm_sarea_t was just not designed
>with binary extension in mind.
>
>I haven't located any code that will break if you put them in the card
>specific sareas. Also you only have to check the driver for the card
>if you do it this way.
>
>
>
The thing is that if I do that, and at some time in the future want to
extend the
number of locks, and at the same time have added other stuff after the
locks in the private part of the sarea, I have a problem. Using the
private part of the sarea also makes producing generic code somewhat
harder.
That's really why I wanted to allocate a separate sarea.
/Thomas
[Attachment #3 (text/html)]
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Jon Smirl wrote:
<blockquote cite="mid9e473391041031141926dba194@mail.gmail.com"
type="cite">
<pre wrap="">On Sun, 31 Oct 2004 22:54:25 +0100, Thomas Hellström
<a class="moz-txt-link-rfc2396E" \
href="mailto:unichrome@shipmail.org"><unichrome@shipmail.org></a> wrote: \
</pre> <blockquote type="cite">
<pre wrap="">Wouldn't this severely break backwards binary compatibility with dri \
clients compiled with the old size of drm_sarea_t?
</pre>
</blockquote>
<pre wrap=""><!---->
You can't put them in drm_sarea_t. There is definitely code that will
break if you do. I don't see anyway to extend drm_sarea_t without
causing binary incompatibility. drm_sarea_t was just not designed
with binary extension in mind.
I haven't located any code that will break if you put them in the card
specific sareas. Also you only have to check the driver for the card
if you do it this way.
</pre>
</blockquote>
The thing is that if I do that, and at some time in the future want to
extend the <br>
number of locks, and at the same time have added other stuff after the
locks in the private part of the sarea, I have a problem. Using the
private part of the sarea also makes producing generic code somewhat
harder. <br>
<br>
That's really why I wanted to allocate a separate sarea. <br>
<br>
/Thomas<br>
<br>
<br>
</body>
</html>
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic