[PATCH 12/15] docs: Document the new <slices> sub-element of disk's <source>

Ján Tomko jtomko at redhat.com
Thu Feb 6 16:15:04 UTC 2020


On Thu, Feb 06, 2020 at 04:55:33PM +0100, Peter Krempa wrote:
>On Thu, Feb 06, 2020 at 16:49:05 +0100, Ján Tomko wrote:
>> On Thu, Feb 06, 2020 at 08:52:04AM +0100, Peter Krempa wrote:
>
>[...]
>
>> > +            <group>
>> > +              <element name='slice'>
>> > +                <attribute name='type'>
>> > +                  <value>storage</value>
>> > +                </attribute>
>> > +                <ref name="diskSourceSlice"/>
>> > +              </element>
>> > +            </group>
>> > +            <group>
>> > +              <element name='slice'>
>> > +                <attribute name='type'>
>> > +                  <value>format</value>
>> > +                </attribute>
>> > +                <ref name="diskSourceSlice"/>
>>
>> Not sure why you use groups if the only choice is between
>> the values of the type attribute.
>
>What I really wanted to express is that I wanted to allow only 0 or 1
>slice with type storage and 0 or 1 slice of type format in any order,
>but my RNG-fu was not strong enough. I forgot to optimize it after the
>attempts. :(
>
>Any ideas how to achieve the above? Otherwise I'll optimize it.

<interleave>
   <optional>
     <!-- storageSlice -->
   </optional>
   <optional>
     <!-- formatSlice -->
   </optional>
</interleave>

was my first thought, but the interleave element does not seem happy
with two slice elements.

My other idea is to enumerate all the options, which is just not worth
it IMO.

Jano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200206/b36d418b/attachment-0001.sig>


More information about the libvir-list mailing list