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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to