Required backwards support level?

[Daniel Vetter]

On Sun, Apr 6, 2014 at 7:28 PM, Lauri Kasanen <cand at gmx.com> wrote:
>> Maybe you can give a better description of what you are wanting to do?
>>  Could you decide on 32b vs 64b userspace on a per 'struct drm_file'
>> basis (ie. each time /dev/dri/cardN is opened)?
>
> This is related to my memory management work. As the VRAM queue is
> global, it cannot be determined on a per-app basis. If at least one
> client is running old userspace, the new scoring cannot be used.
>
> Switching live between the two would bring additional complexity. I'd
> hope to be able to determine by the first 3d app if the userspace is
> new enough. But that depends on if it's expected to be able to run
> mixed loads.

At least thus far we've worked under the example that any
explicitly-enabled new behaviour is only enabled per-fd. That's also
useful when you install all your developer versions into a prefix, so
still have 2 versions of X driver, libdrm, mesa, everything else lying
around and want to switch at runtime even.

Can't you fake a default score somehow for all legacy userspace and
always run with the new code? Reimplementing the old interfaces in
terms of the new ones also allows you to kick out duplicated code
(usually) compared to having both old and new code around.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch