[pulseaudio-discuss] [PATCH 11/11] pulsecore: srbchannel: Enable memfd support; pump protocol version

[Tanu Kaskinen]

On Thu, 2015-10-01 at 12:16 +0200, Ahmed S. Darwish wrote:
> Hi Tanu,
> 
> On Thu, Oct 1, 2015 at 10:02 AM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> > On Sun, 2015-09-20 at 23:39 +0200, Ahmed S. Darwish wrote:
> > > diff --git a/src/pulse/context.c b/src/pulse/context.c
> > > index ede01fa..f272cd6 100644
> > > --- a/src/pulse/context.c
> > > +++ b/src/pulse/context.c
> > > @@ -591,6 +591,8 @@ static void setup_context(pa_context *c, pa_iochannel *io) {
> > >      pa_tagstruct_putu32(t, PA_PROTOCOL_VERSION | (c->do_shm ? 0x80000000U : 0));
> > >      pa_tagstruct_put_arbitrary(t, cookie, sizeof(cookie));
> > > 
> > > +    pa_tagstruct_put_boolean(t, pa_memfd_is_supported());
> > 
> > This breaks compatibility with old servers that expect the tagstruct to
> > end after the cookie.
> > 
> 
> Hmm, I thought that backward compatibility is only maintained from
> the server toward its clients, and not also the other way around ;-)
> 
> > The "memfd supported" bit could be added to the version field like the
> > "shm supported" bit. Another approach would be to do add a new command
> > to do memfd negotiation before enabling srbchannel. Abusing the version
> > field is ugly, adding another negotiation adds more connection setup
> > overhead. I don't know which approach we should choose.
> > 
> 
> The daemon should support all older clients as a form of ABI. This
> is maintained in the patch (even for srbchannels), and would be
> even more important with the arise of xdg-app containers and the like.
> 
> But why should a new client library version support an older daemon?

For example, think about the glorious future with xdg-app: the Gnome
runtime provides libpulse, but the server is provided by the operating
system. Nothing guarantees that the Gnome runtime won't get updated
with a new libpulse version before the operating system provider
upgrades to a new server version.

-- 
Tanu