[libvirt] [PATCH v2 0/2] add debugcon-isa chardev guest interface

[Andrea Bolognani]

On Tue, 2019-02-12 at 16:07 +0100, Ján Tomko wrote:
> On Tue, Feb 12, 2019 at 02:44:05PM +0000, Nikolay Shirokovskiy wrote:
> > On 12.02.2019 17:37, Ján Tomko wrote:
> > > On Thu, Feb 07, 2019 at 02:31:47PM +0300, Nikolay Shirokovskiy wrote:
> > > > Diff from v1 [1]:
> > > > =================
> > > > - expose the device as serial device instead of channel in config
> > > > 
> > > > I use isa-debugcon name becase libvirt passes these names to qemu as-is
> > > > so I don't want to make exception for this device.
> > > 
> > > There should be no pressure to maintain the 1:1 mapping.
> > > For QEMU, the devices need to be represented in single namespace, so
> > > they have to include the bus. In libvirt, we already have the serial
> > > type and the <address> element. It does not have to be duplicated in the
> > > model name as well.

Note that the <address> element is not automatically added for
ISA devices, so that specific duplication is not present.

> > Yeah. But we already have models like isa-serial, usb-serial etc. And thus
> > we don't need map libvirt models to qemu models i.e. internally
> > we use virDomainChrSerialTargetModelTypeToString to generates names for
> > qemu. It would be odd if I start to use map just for debugcon now.
> 
> My point is that the internal implementation is not relevant here
> (we do map XML attributes to QEMU devices elsewhere, see
> qemuDeviceVideo), it's the XML that matters.
> 
> The 'usb-serial', 'pci-serial', 'isa-serial' models are all a generic
> repetition of the target type, all of those are IMO better than
> <model name='serial'/> or <model name='generic'/>
> 
> However
> <target type='isa-serial'>
>   <model name='debugcon'/>
> </target>
> looks better to me than
> <target type='isa-serial'>
>   <model name='isa-debugcon'/>
> </target>

We are consistently using the QEMU device name as the model
attribute for <serial> devices, so I don't really see a compelling
reason to start adding inconsistencies now...

-- 
Andrea Bolognani / Red Hat / Virtualization