[PATCH 4/5] compositor: Version the backend configuration structures

Pekka Paalanen ppaalanen at gmail.com
Thu Apr 14 09:01:09 UTC 2016


On Wed, 13 Apr 2016 11:38:37 -0700
Bryce Harrington <bryce at osg.samsung.com> wrote:

> On Wed, Apr 13, 2016 at 02:47:06PM +0300, Pekka Paalanen wrote:
> > On Tue, 12 Apr 2016 21:44:10 -0700
> > Bryce Harrington <bryce at osg.samsung.com> wrote:
> >   
> > > On Wed, Apr 06, 2016 at 11:43:54AM +0300, Pekka Paalanen wrote:  
> > > > On Mon, 21 Mar 2016 23:11:29 +0100
> > > > Benoit Gschwind <gschwind at gnu-log.net> wrote:
> > > >     
> > > > > Hello,
> > > > > 
> > > > > I think that struct_version and struct_size should not be belong
> > > > > compositor.h. I think those versioning should be back-end detail, and
> > > > > each back-end should provide a major version number through #define in
> > > > > the backend header.    
> > > > 
> > > > Hi!
> > > > 
> > > > No, the struct fields do belong in compositor.h. These fields are
> > > > common to all backend-specific structs, and must be handled the same
> > > > everywhere, so they make perfect sense in compositor.h, in the
> > > > definition of struct weston_backend_config.
> > > > 
> > > > However, you are right in that backends must define the struct_version
> > > > values in a backend-specific header. That #define can (only) be used for
> > > > build time compatibility checks in #if directives in main.c.    
> > > 
> > > Agreed.  How should this #define be named?  
> > 
> > Hi,
> > 
> > umm... WESTON_DRM_BACKEND_CONFIG_VERSION?  
> 
> But we have a major/minor version.  WESTON_DRM_BACKEND_CONFIG_MAJOR_VERSION?
> Or is that too long?

We do? Isn't minor one size, not minor?

The size does not need a #define at all, it is by definition
sizeof(struct ...).

Either way is fine.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160414/01a930c4/attachment.sig>


More information about the wayland-devel mailing list