[libvirt] [PATCH v2 4/5] bhyve: implement bhyve argument parser

Roman Bogorodskiy bogorodskiy at gmail.com
Fri Jun 24 13:19:42 UTC 2016


  Fabian Freyer wrote:

> > 
> > 	       Extra break;
> >> +            break;
> >> +        case 'I':
> >> +            /* While this flag was deprecated in FreeBSD r257423, keep checking
> >> +             * for it for backwards compatibility. */
> >> +            def->features[VIR_DOMAIN_FEATURE_APIC] = VIR_TRISTATE_SWITCH_ON;
> >> +            break;
> >> +        case 'u':
> >> +            if ((caps & BHYVE_CAP_RTC_UTC) != 0) {
> >> +                def->clock.offset = VIR_DOMAIN_CLOCK_OFFSET_UTC;
> >> +            } else {
> >> +                virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
> >> +                               _("Installed bhyve binary does not support "
> >> +                              "UTC clock"));
> >> +                goto error;
> >> +            }
> > 
> > I'm wondering if it actually makes sense to throw an error here? I mean,
> > if a user had this flag, most likely it's supported by that bhyve binary
> > and in unlikely case if it's not, there will be an error thrown anyway,
> > but at the later stage.
> 
> True, but why not? I'm guessing a potential use case for this might not just
> be using native command strings from the same host, but I may be mistaken.

This way we actually do the same job twice (because we're required to do
this when starting a domain anyway).

I think we should not try to be very smart here and just try to parse
as much args as we know to build a complete XML. 

Also, we cannot even be sure what user is going to do with this XML,
maybe they'll run it on some other hosts with different caps. So I think
we need to leave caps check to the start code and don't do it twice. 

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


More information about the libvir-list mailing list