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

[Tapani Pälli]

On 5/21/19 4:53 PM, Sumit Semwal wrote:
> 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.

For point a, vendors can (and should) define their own policy rules 
regarding what file access and ioctl's are required. This is done by 
setting BOARD_SEPOLICY_DIRS in BoardConfig.mk file. That directory then 
contains all the necessary rules required for the particular driver to 
work. As example:

BOARD_SEPOLICY_DIRS += device/samsung/tuna/sepolicy

If a vendor wanted to use xml based configuration for Mesa it should be 
possible by setting a sepolicy rule so that particular library is able 
to access such file. Looking at Android Celadon selinux files, 
'file_contexts' is probably the place to do it.

> 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?
> 

// Tapani