Re: [PATCH v3 5/5] tools/xenstore: add migration stream extensions for new features

[Julien Grall <julien@xxxxxxx>]

Hi Juergen,

On 12/08/2022 11:56, Juergen Gross wrote:
> On 12.08.22 11:13, Julien Grall wrote:
> > Hi Juergen,
> >
> > On 08/08/2022 12:31, Juergen Gross wrote:
> > > On 08.08.22 13:00, Julien Grall wrote:
> > > > > This would break the use of xenstore-stubdom for such a setup.
> > > > I am not sure why it would break the use of xenstore-stubdom. An 
> > > > application will already need to cope with the case Xenstored 
> > > > doesn't support a feature.
> > > Someone relying to be able to switch off a feature on a socket 
> > > connection
> > > might get into trouble trying to do the same when running with 
> > > xenstore-stubdom.
> > This is not very different from an application that was built against 
> > an old Xenstored and would not be capable to talk properly with the 
> > new Xenstored if the feature is enabled. I understand that...
> > > Switching a feature off will either not work, or switch the feature 
> > > off for all
> > > dom0 connections (which is a single one, of course).
> > ... when using xenstore-stubdom xenstored it means that the feature 
> > will have to be disable for all dom0 connections.
> Wait, I don't think we can ever add features which will change the 
> behavior of
> Xenstore when those new features aren't being used actively.
That would be fine if you know that your client can support it. Reading 
the rest of the e-mail, AFAIU your aim is to use SET_FEATURES to 
indicate which features is supported by Xenstored. This may or may not 
be supported by the client.
When I replied, I had a different idea in mind for SET_FEATURES. But I 
think it wouldn't work in a generic setup because an handshake would be 
necessary (the client would need to advertise the features it supports).
Anyway, now I understand your point and agree with you the we want to 
only have the field 'features' for ring connection.
Thanks for the clarification!

Cheers,

--
Julien Grall