This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #7 from Josh Stone <jistone at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #5)
> So we could have that stapsh -d option (renamed --stdio or --persistent
> or --multiplex?) modify the handshake so that stapsh identifies itself as
> "stapsh-d VERSION ...." to stap, at which point they both go into the
> explicitly-multiplexed mode.

Unfortunately, in this case stapsh::set_child_fds() is too picky about what it
receives.  We could relax that, but old staps will still be an issue.

    // stapsh VERSION MACHINE RELEASE
    vector<string> uname;
    tokenize(reply, uname, " \t\r\n");
    if (uname.size() != 4 || uname[0] != "stapsh")
      throw runtime_error(_("failed to get uname from stapsh"));

We could have stap explicitly ask for this multiplexing, assuming it knows this
is a connection that would need it.  (e.g. used for a "vm:..." scheme, or maybe
even all "unix:" needs this.)  This can be a new option command, like "option
data" for stdout/err encapsulation, enabling "quit" at that time too since it
depends on encapsulation.  I can also imagine something like "option compress"
being useful in the future, and maybe "option dyninst" to make the run command
use stapdyn for PR14711.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]