On Tue, 2017-11-07 at 09:23 +, 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 +, Daniel P. Berrange wrote:
> > > I can see the argument about it making QEMU easier to use, and
> > >
e socketpair, then it would
> be nice to improve QIOChannelCommand
Yes, that would be better. But before touching too many different files
and thus increasing the risk of merge conflicts (which is an issue when
maintaining the patch downstream) I'd like to get a feeling for whether
it'
do that only on demand? I haven't checked what triggers that
code. It might be useful to only spawn the command when actually needed
by some frontend. Perhaps then the command can also be spawned multiple
times. Right now it gets spawned exactly once when creating thechardev.
--
Best
already also work with the qemu device backend that is
getting discussed here?
In other words, are protocol changes needed? I know that TPM 2 has
changed the commands, but I don't know whether that affects also the
lower layers.
--
Best Regards, Patrick Ohly
The content of this message is
having to write and maintain more than just the glue code between
the two projects.
--
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.
s us a lot more flexibility and
> control, and doesn't have to be very strictly documented (although it
> is still better to be strict, but requires more effort).
... I suspect it falls into this camp. I can't think of any users of the
protocol besides swtpm itself and now qemu. Stefa
one process, as before, and just need to pass some additional
parameters.
Can we agree that both usage models are valid and thus support both?
--
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 mak
om the parent. It shouldn't be hard to
add that as an alternative to the existing spawning code.
I can think of one use case: spawning swtpm in advance under debugging
tools like gdb or valgrind. Is that enough justification for adding more
code?
--
Best Regards, Patrick Ohly
The content of
