[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