[Mesa-dev] [RFC 0/2] Alternate default config mechanism

[Sumit Semwal]

Hello everyone,

First up, my apologies on not being able to respond earlier; secondly,
thanks very much for your review.

On Wed, 15 May 2019 at 19:27, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
> Hi all,
>
> On Tue, 14 May 2019 at 08:18, Tapani Pälli <tapani.palli at intel.com> wrote:
> >
> >
> > On 5/13/19 6:52 PM, Haehnle, Nicolai wrote:
> > > This approach seems entirely incompatible with si_debug_options.h, and
> > > will be an absolute maintenance nightmare going forward for adding /
> > > removing options, because you're introducing a second location where
> > > options are defined.
> > >
> > > Quite frankly, this seems like a terrible idea as-is.
> > >
> > > If you really can't use XML for whatever reason, then please find some
> > > way of deriving both the tables here and the XML from the same single
> > > source of truth.
> >
> > I was looking at this yesterday and came up with same conclusion. We
> > should have the options in one place. Currently libexpat is statically
> > linked with Android >=O, maybe for such restricted environments we could
> > just inline the xml as is at compile time and parse that later or
> > alternatively (maybe cleaner) parse and generate default option cache
> > already during compilation?
> >
> I realise that jumping the "me too" train does not help much, so here
> are some alternative ideas.
>
> How about we first distil the reasons why this is a problem and what
> kind. Then explore independent solution for each one - as-is this
> seems like a one-size-fits-all approach.
I totally agree that this seems like a rudimentary / ugly approach,
and we can definitely improve upon it once the reasons are discussed.

> Some examples:
>  - XML file may be inaccessible - the in-driver defaults should work(tm)
> Yes there are some app specific ones, yet neither(?) of these apps is
> present on Android
>  - libexpat is not available, but libFOO is - investigate into a compat wrapper
>  - cannot use external libraries (libexpat or equivalent) - static link
>

AFAIU, in the Android space, it is a combination of some of the above:
a. current Android doesn't allow GL drivers to access config files
from the vendor partition: this is enforced via selinux policy.
b. Also, they had some concerns around how safe libexpat is vis-a-vis
dual-loading, and that's where the concern around static linking came
from.

Alistair, could you please correct me if I am wrong, and if there are
additional details on the need of this?

> -Emil

Best,
Sumit.