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.
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
