Re: BUG: libxl vuart build order

[Anthony PERARD <anthony.perard@citrix.com>]

On Thu, Nov 05, 2020 at 08:29:20AM -0800, Stefano Stabellini wrote:
> On Thu, 5 Nov 2020, Anthony PERARD wrote:
> > On Fri, Oct 30, 2020 at 10:46:37AM -0700, Stefano Stabellini wrote:
> > > On Fri, 30 Oct 2020, Takahiro Akashi wrote:
> > > > === after "xl console -t vuart" ===
> > > > U-Boot 2020.10-00777-g10cf956a26ba (Oct 29 2020 - 19:31:29 +0900) xenguest
> > > > 
> > > > Xen virtual CPU
> > > > Model: XENVM-4.15
> > > > DRAM:  128 MiB
> > > > 
> > > > In:    sbsa-pl011
> > > > Out:   sbsa-pl011
> > > > Err:   sbsa-pl011
> > > > ===
> > > > 
> > > > If possible, I hope that "xl create -c" command would accept "-t vuart"
> > > > option (or it should automatically selects uart type from the config).
> > > 
> > > I think a patch to add the "-t" option to "xl create" would be
> > > acceptable, right Anthony?
> > 
> > I don't know. Why `xl' isn't able to select the vuart as the default one?
> 
> Because both consoles are still valid: when the emulated uart is
> enabled, the normal PV console is also enabled.
> 
> 
> > Maybe a long option would be better in the cases where we would like to
> > connect to a "secondary" console? I could see `xl create --console=vuart'
> > been fine, I don't know if that's possible.
> 
> That's OK for me but keep in mind that xl console already takes -t
> vuart. In other words:

I don't know why we would need the same exact option, `xl console` and
`xl create` are two different commands. Also, I usually prefer long
option for less used options as it makes it a bit easier to figure out
what a command is supposed to do (without checking the man; and when
there is both long and short options available).

> 1) xl console -t vuart    -> WORKS

-t for `xl console` kind of works well, -t could be a shortcut of "type"
of console".

> 2) xl create -c -t vuart  -> DOESN'T WORK

But here, -t would not be a "type" of console since we are creating a
VM. Also `xl create -t vuart` without -c would do nothing, right?
(create a vm but ignoring the -t).

Anyway, an option to auto-connect to a different console would be
useful.

> P.S.
> 
> Could you also take a quick look at the patch I appended to the previous
> email? Or would you prefer me to send it out separately as its own
> patch?

It's probably better to have a patch on its own when it's ready for
review rather that been embedded in an email in a long
discussion/debugging thread. That leave a better chance for others to
spot that a patch exist and review.

Cheers,

-- 
Anthony PERARD