On Mon, Jan 28, 2019 at 11:24:38AM +0100, Andrea Bolognani wrote:
On Fri, 2019-01-25 at 14:06 +0000, Nikolay Shirokovskiy wrote:
> On 25.01.2019 16:37, Ján Tomko wrote:
> > On Thu, Jan 24, 2019 at 05:28:59PM +0300, Nikolay Shirokovskiy wrote:
> > > This interface can be used for example by firmware to print
> > > debug messages. Here is domain xml example:
> > >
> > > <channel type='file'>
> > > <source path='/var/log/libvirt/qemu/VM.firmware.log'/>
> > > <target type='debugcon-isa'/>
> >
> > IMO 'debugcon' would be enough.
>
> I followed serial chardev xml. It uses pci-serial, usb-serial etc
> for target type. I think idea is to make it possible to specify
> type when address is not specified (if it is then one can use
> address type to distinguish). Of course we have only isa-debugcon
> device yet. However I agree that for channel configuration having
> enumeration like spicevm, guesfw, debugcon-isa looks like mixing
> types and subtypes.
Should this be a <channel> at all?
We generally use <serial> for native emulated devices such as
isa-serial, which isa-debugcon seems very closely related to...
<channel> is aiming to expose application specific guest data channels.
<serial> is aiming to expose general purpose guest data channels.
To me isa-debugcon is an application specific data channels, so
<channel> feels a better fit.
Perhaps the best way to hook this up would be
<serial type='pty'>
<target type='isa-serial'>
IMHO using 'isa-serial' would be misleading for applications which
know about <serial> ports today and may well cause unexpected side
effects, especially wrt to the <console> mapping of the first <serial>
port.
<model name='isa-debugcon'/>
</target>
</serial>
CC'ing Pavel as we looked into this mess together the last time
around, so he might have an opinion on the subject :)
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|