[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids

From: Halil Pasic
Subject: Re: [Qemu-devel] [RFC PATCH 1/1] s390x/css: unresrict cssids
Date: Fri, 24 Nov 2017 16:30:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 11/24/2017 03:58 PM, Christian Borntraeger wrote:
> On 11/24/2017 02:27 PM, Cornelia Huck wrote:
>> On Fri, 24 Nov 2017 14:01:20 +0100
>> Christian Borntraeger <address@hidden> wrote:
>>> I first liked the idea to have it as a property of the css, but 
>>> this is all pretty unclear how to do right. I start to think that going with
>>> Halils first patch (a property per virtio device) is going to be the most
>>> simple solution without causing any harm. After all as of today we only 
>>> want 
>>> to have a way to tell libvirt that devices can be everywhere. Specifying the
>>> default css might be something that we want to have in the future, but here
>>> future might even mean never.
>> I still don't like the idea of a per-device property, but I agree that
>> adding a css property would need too much discussion to get to a
>> solution in the near future.
>> Is there anything that speaks against a machine property, though? While
>> not ideal, I like it better than the per-device one.
> In theory this should work. 
> In reality it seems more complicated. A per-device property is easy and can be
> inspected on the command line (e.g. -device virtio-blk-ccw,help), while a new 
> machine property would require to change the qemu help output and 
> qemu-options 
> file (which makes it visible for all architectures).

And then we have the fun of describing, that this property is weird, and can
not be set, and it's value does not matter.

BTW one can do -machine s390-ccw-virtio-2.11,help and get a list of properties,
so the command line introspection would work similar.

I've already brought some other arguments against the machine property.
Won't repeat them here.

> Not sure if there are
> easier ways to do it. (e.g. QOM-only things, but then we have no command line
> way of doing it)
If we don't care about if it can be introspected on the command line my
trait type approach is pretty minimal. But the least surprise is probably
still the device property (IMHO).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]