[Bug runtime/13078] investigate qemu virtio-serial channel for talking to stap-sh

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=13078

--- Comment #4 from Josh Stone <jistone at redhat dot com> ---
One concern I want to document is compatibility.  I have discussed this with
jlebon on IRC, and he's already started addressing it in his prototype code. 
The gist is that we can't assume that stap on the host is the same version as
stapsh/staprun/etc on the remote target.  So both sides of the connection have
to be prepared to talk to old versions too -- a new stap still has to
understand an old stapsh, and likewise a new stapsh has to be able to talk to
an older stap.

Thankfully, this concern was foreseen enough that the initial command handshake
has always included version info by both parties.  So even though this protocol
hasn't yet been changed since its introduction, it's prepared for a version
negotiation.  Still, any changes should be carefully considered and strongly
justified, so we can keep the code dealing with compatibility as simple as
possible.

> To work around (1), we can make stapsh send a QUITTING message to stap before
> exiting. However, this would be indistinguishable from a possible output from
> staprun. One way around this is to prepend all the output from staprun with
> "staprun:" and replies/messages from stapsh (such as the OK acks) with
> "stapsh:". This would also mean always reading from /tmp/foo line-by-line
> rather than in blocks, regardless of --remote-prefix.

Beware that script output can include binary data, so treating everything
line-oriented seems problematic.  The current code on jlebon/cross-vm even
removed a note on this, without addressing the issue:

  // NB: The buf could contain binary data,
  // including \0, so write as a block instead of
  // the usual <<string.

When the user specifies --remote-prefix, we go line-oriented by their choice,
but I don't think we can get away with always doing this.  If the user wants
binary data over stapsh, it should be possible.

To handle this, I think the stapsh protocol should always treat its data
shuffling as binary.  That means your current prefix should be more like a
block header, or like the existing "file" command but in the other direction. 
Perhaps something like "data stdout SIZE\n" followed by the raw bytes.  On
stap's side it can decide to write out the raw data or use lines depending on
--remote-prefix.  There can be "data stderr SIZE" too, for both staprun's
stderr and stapsh's verbose logging, for instance.

The compatibility story is then that stapsh doesn't send any "data" header or
things like QUITTING to old stap, and stap with an old stapsh should read lines
or binary just as it did before, without expecting that "data ..." line.

I'd also suggest that stapsh just say "quit" at its end, rather than QUITTING,
mirroring the stap command.  We're basically establishing a command stream in
the stapsh->stap direction, with "data" and "quit" as the first possibilities.

I hope this idea keeps the communication a little simpler and a bit more
uniform.  Let me know what you think.

-- 
You are receiving this mail because:
You are the assignee for the bug.