On 7/11/2023 10:52 PM, Markus Armbruster wrote:
"Kim, Dongwon" <dongwon....@intel.com> writes:
On 7/10/2023 11:36 PM, Markus Armbruster wrote:
"Kim, Dongwon" <dongwon....@intel.com> writes:
On 7/9/2023 11:05 PM, Markus Armbruster wrote:
"Kim, Dongwon" <dongwon....@intel.com> writes:
On 7/7/2023 7:07 AM, Markus Armbruster wrote:
[...]
Old question not yet answered: Using a list for the mapping means the
mapping must be dense, e.g. I can't map #0 and #2 but not #1. Is this
what we want?
No, it doesn't have to be dense. In your example, you can just leave the place
for VC1 blank. For example, you could do connectors.0=DP-1,connectors.2=HDMI-1.
But in this case, VC1 won't be activated and stay as disconnected from guest's
perspective. I think this info is also needed in v2.
Have you tried this? I believe it'll fail with something like
"Parameter 'connectors.1' missing".
Just tested it. Yeah you are correct. I think I had a bad assumption. Let me
take a look to see if I can make it work as I assumed.
If sparse mappings make sense, we should provide for them, I think.
An array like '*connectors': ['str'] maps from integers 0, 1, ... It
can't do sparse (you can't omit integers in the middle).
Yeah, I understand this now. Despite of my initial intention was different, I
am wondering if we don't allow the sparse mapping in this implementation. Any
thought on that?
Repeating myself: if sparse mappings make sense, we should provide for
them, I think.
So, do they make sense? Or asked differently, could a user conceivably
want to *not* place a VC?
It should be very rare. I can't think of any valid use case other than
test cases for validating this feature. If VC is not mapped to anything
from the beginning, there is no way to get it displayed. So there is no
value to do so. So I assume provisioning a full list as a requirement
would make sense here.
The V2 patch is with that change in the description. Another thing I think is
to change QAPI design little bit to make it fill the element with null (0) if
it's not given. Would this be a feasible option?
A 'str' cannot be NULL. In fact, no QAPI type can be null, except for
'null' (which is always NULL), alternates with a 'null' branch, and
pointer-valued optionals (which are null when absent).
Instead of omitting them, we could map them to null: '*connectors':
['StrOrNull']. JSON input looks like [null, "HDMI-A-0"]. Since dotted
key syntax does not support null at this time, you'd have to use JSON.
Only an object can do sparse. However, the QAPI schema language can't
express "object where the keys are integers and the values are strings".
We'd have to use 'any', and check everything manually.
Hmm. Thoughts?
[...]
