Re: [Xen-devel] [RFC PATCH v2 02/17] libxl: Add "stubdomain_version" to domain_build_info.

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Oct 16, 2018 at 05:43:34PM +0100, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 02/17] libxl: Add 
> "stubdomain_version" to domain_build_info."):
> > Actually, with patch 04/17 you can set explicit stubdomain path, so
> > stubdomain_version is only another way (redundant to
> > device_model_version) to signal what protocol to communicate with
> > stubdomain should be used. Right now each qemu version have only one
> > stubdomain protocol:
> >  - qemu-xen-traditional - "mini os" one
> >  - qemu-xen - "linux" one - see cover letter
> 
> I'm not sure why you need introduce a stubdomain_version variable
> internally, or the corresponding stubdomain_version config option, at
> all.
> 
> Do we expect to have qemu trad on Linux ?  Seems unlikely.  We have
> been trying to do modern qemu on minios or rump kernels or something
> for years and gotten nowhere.
> 
> So maybe what we should have is an internal macro or inline function
> called stubdomain_is_linux, so we can add new variants later
> internally.
> 
> But I don't see the need for this to be in the public and stable libxl
> ABI.  Unless I'm missing something.

I imagine there may be more stubdomain versions in the future,
especially when the stubdomain path can be easily set in domain config.
But it's ok to add such field only if/when we'll actually have multiple
of them supported in upstream libxl. As long as the code will be clear
about what it "qemu-xen specific" and what is "linux stubdomain
specific". But stubdomain_is_linux macro should be enough.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel