Hi
On Mon, Apr 10, 2017 at 9:33 AM Amarnath Valluri <amarnath.vall...@intel.com>
wrote:
>
>
> On 07.04.2017 18:11, Marc-André Lureau wrote:
>
> Hi
>
> On Fri, Apr 7, 2017 at 4:41 PM Daniel P. Berrange
>
> > + .name = "data-path",
> > + .type = QEMU_OPT_STRING,
> > + .help = "Socket path to use for data exhange",
> > + },
> > + {
> > + .name = "ctrl-path",
> > + .type = QEMU_OPT_STRING,
> > + .help = "Socket path to use for out-of-band control messages",
> > + },
>
> I'm still not convinced by the need for 2 separate UNIX sockets, unless
> there's a performance reason, but that looks unlikely.
>
>
> We would also need something more than an implementation of the protocol
> that qemu is going to rely on as an external dependency. A protocol
> specification would help to start the discussion.
>
> I would agree with you, Can we adopt the current swtpm's control interface
> as initial proposal.
>
>
Perhaps, but I think it would be a mistake to rely on it without some
review.
> Alternatively, I would suggest to not rely on a public protocol,
>
> What do you mean by public protocol here, can you please help me
> understanding this.
>
>
By "public protocol", I mean qemu communication with a foreign project,
swtpm or other.
If qemu grows new needs, or if the protocol is found limited or buggy, it
may change. Subtle interactions may break between various implementations.
The minimum would be some versioning or capabilities. A document describing
the states and messages allowed/denied & effects would be quite necessary.
Otoh, there doesn't seem to be other users of this protocol, or other
implementations. So it may make sense to make it qemu-specific, and thus
"private": the protocol and implementation can evolve without risk to break
other users. This gives 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).
--
Marc-André Lureau
