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

[Juergen Gross <jgross@xxxxxxxx>]

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. The new features
should always be on top of the existing functionality.

> However, it seems unlikely to me that someone will switch to a xenstore-stubdom 
> on a whim because there are also scalability concerns (one ring to rule all 
> connections). So I think it would be fair to say that your application may need 
> to be tweak if you are not using the same feature as the system.
No, this should never be the case IMO. See above.

> > > At which point, it would be easy to say "I don't want this feature" when 
> > > using a socket.
> > I don't see the value of that. If you don't want a feature, just don't use it.
> This is not that simple. Your assumption is the feature will not change the 
> behavior exposed to the application.
Correct.

> I don't think we have such feature today but I don't see what prevents us to do 
> that.
Compatibility prevents us doing that.

If we want different behavior, we need to use different or extended commands
(e.g. like the additional "depth" parameter of SET_WATCH).


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature