Re: [RFC weston 4/5] drm: Move backend to libweston

[Quentin Glidic]

On 13/02/2016 11:22, Benoit Gschwind wrote:
 >
 > [snip]
 >
> Following a comment from Quentin Glidic on IRC, I read wrong the
> snprintf (I readed printf ... a shame, my apology). Which make the patch
> valid if output->base.name is not too long.

output->base.name is managed in the backend and is fixed-sized already.
The size I used is even way too large for the possible values here.

> But I keep the following:
>
>>
>> This case show that this approach is not very good, In that case the
>> developer must give a list of unbound outputs setup and key/value is not
>> well suited for that case. (there is some workaround, like using key
>> pattern).
>>
>> This case also leave me to add that section/key/value is not a good
>> choice and you should stick to key/value.
>>
>> I still prefer the opaque configuration structure with function to set
>> the structure content.

I am not sure how to understand that part (even with your precision on 
IRC) but I think it is relevant to remind something that I find really 
important (and not only for that specific comment):

We are designing the *backend* configuration API.
We agreed already that backends will be an internal implementation 
detail of libweston. As such, I (as a future libweston-based compositor 
writer) consider them as trusted, which means:
- They would not use getters to grab random parts of my configuration
- They should keep the options set “small” enough for end-users to write 
it in any text-based configuration format the compositor would like to 
use (Weston is currently using a KeyFile, which is a really common 
format and not really fitting for complex structures). I expect backends 
needing a really complex configuration to provide a GUI program, or use 
their own configuration file.
DRM is probably the most complex backend we will have for quite a long 
time (I consider any future “hardware-based” backend will have similar 
needs), and it fits well in the INI/KeyFile format.


In the current form, my patch has one little (IMO) 
non-backward-compatible change: it does not use a duplicated name 
"[output]" for the section with the "name=" key as the selector.
It is entirely doable if it is a requirement for this patch to be 
considered, but in this design, backends should use unique section 
names, since KeyFile parser (like GLib’s) can merge duplicate sections.


Cheers,

-- 

Quentin “Sardem FF7” Glidic