Re: [Qemu-devel] RFC: connecting chardev to a command forked by qemu

[Patrick Ohly]

On Tue, 2017-11-07 at 09:23 +0000, Daniel P. Berrange wrote:
> On Mon, Nov 06, 2017 at 10:02:05PM +0100, Patrick Ohly wrote:
> > On Mon, 2017-11-06 at 17:26 +0000, Daniel P. Berrange wrote:
> > > I can see the argument about it making QEMU easier to use, and
> > > those
> > > who care about security aren't forced to use this new feature. It
> > > none the less has a cost on maintainers and existance of these
> > > features does reflect on QEMU's security reputation even if many
> > > don't use it.
> > 
> > With Yocto we really don't have much choice: we need a patch like
> > this
> > because the alternative (introducing support for spawning and
> > stopping
> > swtpm and then passing the right parameters to QEMU) is way more
> > complex. So if this patch isn't acceptable to QEMU upstream, then I
> > will keep it as simple as possible and propose it as a local patch
> > in
> > Yocto.
> 
> I don't really buy this argument. Any distro's core job is the
> ability to start/stop/manage processes. Saying yocto is unable to
> manage runing of swtpm is really dubious - it is simply a choice to
> declare that it is QEMU's job. 

Yocto isn't really a distro. It's mostly a build system and meta data
that can be used to build custom distros.

The use of qemu+swtpm is during testing on whatever distro the
developer has chosen for his build machine. Yocto could build libvirt
for that host to manage QEMU, but given the choice between that or
enhancing the Yocto QEMU support code and patching QEMU, patching IMHO
is the easier and cleaner solution - for Yocto, at least.

I'll proceed with proposing the patch as a Yocto-specific modification
for QEMU.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.