[PATCH] wayland-server: Version check requests

Alexander Larsson alexl at redhat.com
Fri May 24 01:22:02 PDT 2013


On tor, 2013-05-23 at 15:58 -0500, Jason Ekstrand wrote:
> 
> On Thu, May 23, 2013 at 3:20 PM, <alexl at redhat.com> wrote:
>         From: Alexander Larsson <alexl at redhat.com>
>         
>         If an interface has any messages and its version is larger
>         than 1
>         then we emit a method counts array which lists the number of
>         methods
>         for each version of the interface. This can be used in
>         addition
>         to the normal method_count to reject requests that the
>         server doesn't support. This allows the wayland server library
>         to be upgraded and still safely run oler compositors that
>         don't
>         implement the new requests.
>         
>         Since there is no other space in the wm_interface we add the
>         method count array at the end of the events array. We then
>         add some warnings to the event sending code so that we never
>         accidentally trigger these events.
> 
> 
> Would it possibly be better to use the upper bits of method_count (or
> method_count < 0) to signal that a method_counts array is appended to
> methods?  This keeps methods with methods and also allows us to
> optionally do the same thing with events client-side to protect
> clients from broken newer-version compositors.

It depends on what kind of guarantees we want to make. My hack is 100%
backwards compatible in that a library that generates protocol
descriptions using the scanner will still work with an older
libwayland-server. If the scanner starts producing method_counts with
the high bit set then old versions of libwayland-server will handle
these as if there was a lot of methods and break the check for invalid
requests.

Of course, for the case of the core wayland protocol this is not a
problem as they are in the same library as the dispatcher. However, one
could imagine e.g. weston or libEGL being built with a newer version of
scanner and then deployed on an older libwayland-server. Or we could
just ignore this case...




More information about the wayland-devel mailing list