On 11/27/2017 03:13 PM, Halil Pasic wrote:
On 11/27/2017 02:19 PM, Cornelia Huck wrote:
On Mon, 27 Nov 2017 14:11:57 +0100
Halil Pasic <pa...@linux.vnet.ibm.com> wrote:
On 11/27/2017 01:56 PM, Cornelia Huck wrote:
On Fri, 24 Nov 2017 17:39:04 +0100
Halil Pasic <pa...@linux.vnet.ibm.com> wrote:
On 11/24/2017 05:15 PM, Cornelia Huck wrote:
(Unless we simply make this a "default cssid" prop after all - then it
would be more than just a simple indication for libvirt...)
We are now talking about the "cssid-unrestricted" property. The default
cssid is not something I would like to do any time soon.
What's so bad about this? As said above, I think it would be much more
useful. If libvirt can detect r/o vs. r/w for properties, we can simply
start out with a r/o variant now...
I'm not sure I understand you. Are you proposing the following:
Drop the restriction, but don't indicate this via a read only
"cssid-unrestricted" device property but via a "default-css"
read only machine property.
Libvirt then should know that if "default-css" is present then
we don't have this virtual into 0xfe and non virtual into 0xfd
restriction any more.
Yes.
@Boris:
Does this work for you? Technically it's equivalent to having
"cssid-unrestricted" at machine level.
I don't really like the idea of indicating unrestricted via
something mostly unrelated (at least for me it ain't obvious that
having the id of the default css exposed means we got rid of the
limitation.). But I'm tied of discussing this, so I'm willing to
compromise.
Halil
I agree with Christian that we should not throw the "setting of a
default cssid" together with "unrestricted cssid" and than use read/only
and read/write to distinguish between the two!
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
