[Mesa-dev] [RFC] Deprecating old DRI loaders/drivers

[Timothy Arceri]

On 17/05/17 02:38, Ian Romanick wrote:
> What *actual* problem are you trying to solve?  Honestly, it seems like
> you're just trying to find stuff to do.  We have a mechanism to make
> this work, and it's not that hard.  Introducing a deprecation period and
> everything that involves will make it more work, not less.

To be fair aren't we in a stage in Mesa's life-cycle where the focus is 
on tidying-up / optimisations. It's not like there are large spec 
updates in the pipeline.

> 
> On 05/16/2017 06:05 AM, Emil Velikov wrote:
>> Hi all,
>>
>> As many of you know the current DRI interface provides backwards
>> compatibility between old loaders and new drivers, and vice-versa.
>>
>> Sometimes issues cannot be addressed with the existing extensions and
>> we need to bump the version or provide an alternative extension.
>> In such cases we still preserve the old buggy code path.
>>
>> Even when that's not the case, we still end up with highly divergent
>> code, as some features are exposed only when the extension criteria is
>> met.
>>
>>
>> At the moment we claim to support any loader <> driver combination in
>> existence, while in reality components from different Mesa versions
>> are rarely tested.
>> One noticeable exception is the legacy DRI1 drivers. Therefore this
>> proposal does _not_ cover any DRI1 specific changes.
>>
>> To straighten the code flow and remove much of the unused code, I'm
>> proposing the following:
>>
>> 1) Establish deprecation period - keep in mind the DRI loader in Xserver.
>> 2) Any extension that is supported on both driver and loader gets deprecated.
>>    A) Drivers and loaders are annotated to emit a warning when used
>> with 'too old' counterpart.
>>    B) If applicable extensions are moved out of dri_interface.h to
>> another header.
>> 3) At the end of deprecation period:
>>    A) Cleanup all the dead code.
>>
>> Personally, 1 year sounds reasonable, as that constitutes of four Mesa
>> major releases.
>> For the other actions, I have patches around that I could polish and
>> sending to the list.
>>
>> I would greatly appreciate any input, esp. from distribution maintainers.
>>
>> Should my proposal seem unsuitable, I would strongly encourage people
>> to provide brief action plan alongside the obstacles they see.
>>
>> Thanks
>> Emil
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>