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 :|