On 05/03/2016 10:50 AM, John Ferlan wrote: > > > On 05/03/2016 09:30 AM, Cole Robinson wrote: >> On 05/02/2016 06:30 PM, John Ferlan wrote: >>> Reformat to use <dt> elements to make it a bit easier to read. >>> >>> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> >>> --- >>> docs/formatdomain.html.in | 49 ++++++++++++++++++++++++++++------------------- >>> 1 file changed, 29 insertions(+), 20 deletions(-) >>> >>> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in >>> index 735546e..5781dba 100644 >>> --- a/docs/formatdomain.html.in >>> +++ b/docs/formatdomain.html.in >>> @@ -3010,28 +3010,37 @@ >>> >>> <p> >>> Each controller has a mandatory attribute <code>type</code>, >>> - which must be one of "ide", "fdc", "scsi", "sata", "usb", >>> - "ccid", "virtio-serial" or "pci", and a mandatory >>> + which must be one of 'ide', 'fdc', 'scsi', 'sata', 'usb', >>> + 'ccid', 'virtio-serial' or 'pci', and a mandatory >>> attribute <code>index</code> which is the decimal integer >>> describing in which order the bus controller is encountered (for >>> - use in <code>controller</code> attributes >>> - of <code><address></code> elements). The "virtio-serial" >>> - controller has two additional optional >>> - attributes <code>ports</code> and <code>vectors</code>, which >>> - control how many devices can be connected through the >>> - controller. A "scsi" controller has an optional >>> - attribute <code>model</code>, which is one of "auto", "buslogic", >>> - "ibmvscsi", "lsilogic", "lsisas1068", "lsisas1078", "virtio-scsi" or >>> - "vmpvscsi". A "usb" controller has an optional attribute >>> - <code>model</code>, which is one of "piix3-uhci", "piix4-uhci", "ehci", >>> - "ich9-ehci1", "ich9-uhci1", "ich9-uhci2", "ich9-uhci3", "vt82c686b-uhci", >>> - "pci-ohci" or "nec-xhci". Additionally, >>> - <span class="since">since 0.10.0</span>, if the USB bus needs to be >>> - explicitly disabled for the guest, <code>model='none'</code> may be >>> - used. <span class="since">Since 1.0.5</span>, no default USB controller >>> - will be built on S390. The PowerPC64 "spapr-vio" addresses do not have an >>> - associated controller. >>> - </p> >>> + use in <code>controller</code> attributes of >>> + <code><address></code> elements). Some controller types >>> + have additional attributes that control specific features, such as: >>> + </p> >>> + >>> + <dl> >>> + <dt><code>virtio-serial</code></dt> >>> + <dd>The <code>virtio-serial</code> controller has two additional >>> + optional attributes <code>ports</code> and <code>vectors</code>, >>> + which control how many devices can be connected through the >>> + controller.</dd> >>> + <dt><code>scsi</code></dt> >>> + <dd>A <code>scsi</code> controller has an optional attribute >>> + <code>model</code>, which is one of 'auto', 'buslogic', 'ibmvscsi', >>> + 'lsilogic', 'lsisas1068', 'lsisas1078', 'virtio-scsi' or >>> + 'vmpvscsi'.</dd> >>> + <dt><code>usb</code></dt> >>> + <dd>A <code>usb</code> controller has an optional attribute >>> + <code>model</code>, which is one of "piix3-uhci", "piix4-uhci", >>> + "ehci", "ich9-ehci1", "ich9-uhci1", "ich9-uhci2", "ich9-uhci3", >>> + "vt82c686b-uhci", "pci-ohci" or "nec-xhci". Additionally, >>> + <span class="since">since 0.10.0</span>, if the USB bus needs to >>> + be explicitly disabled for the guest, <code>model='none'</code> >>> + may be used. <span class="since">Since 1.0.5</span>, no default >>> + USB controller will be built on s390. The PowerPC64 "spapr-vio" >>> + addresses do not have an associated controller.</dd> >>> + </dl> >>> >> >> That "sparp-vio" bit at the end isn't relevant to the 'usb' section. In fact I >> don't even think it should be in this section, either the spapr-vio device >> address section, or dropped entirely >> > > Also have to squeeze your change in... Busy section! > > Looks like it was added by commit id 'fe7fc1617'... It perhaps should > be a note after the </dl>, such as: > > <p> > + Note: The PowerPC64 "spapr-vio" addresses do not have an > + associated controller. > + </p> > > and removed from the <usb> section. > > Does this seem better? > > John > ACK, looks good to me - Cole -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list