Using external C programs from SSH

[nyh]

Currently, when running an external C program ("run ...", or even "ifconfig") via ssh, the output goes to the console instead of ssh (the input too, of course). This needs to be fixed. The "ifconfig" problem can be fixed by rewriting it in Java (probably a good idea anyway), but the general problem of running arbitrary C code needs to be fixed.

Normal C code written for Linux will use file descriptor 1 (stdout) and 0 (stdin) for their output and input. In OSv, this is currently always the serial console and/or the VGA, even if you log in through ssh, which is not very useful.

What we need to do is this: Our "run" command (used to run netperf) needs to open two pipes [1] and replace file descriptors 0, 1, 2, with halves of these two pipes [2]. Now netperf will not write or read from the serial console or VGA, but rather write and read to these pipes. Netperf will be run in a separate thread, and the original thread doing the "run" will just read from the pipe and use crash's Java "write" to output it (so it will go to the ssh layer as appropriate), and similarly, will read input with Java (coming from ssh) and write it to the other pipe going into netperf.

I would hope that Crsh already has some command to "run" external commands on Linux, which already should be doing something similar to what I described above (opening pipes, etc.), otherwise even on Linux, Crsh would only be useful for running builtin commands implemented in Java. But even if it doesn't, what I described above, using pipes, is pretty straightforward to implement (I can elaborate if something isn't clear).

[1] Linux has the notion of a "pty" (pseudo-terminals) which improves on this and supports stty, line discipline, etc, but we don't support ptys yet, so can start with ordinary pipes, and this will be good enough in most cases. I can add pty support later if there's interest - this mostly means moving some of the code in console.cc to a separate pty layer.

[2] Initially, we can replace fd 0, 1, 2 with the pipe-ends using a simple close() and dup(). This will work but effect the entire OSv, so one will not be able to use two ssh sessions in parallel. If we need to support parallel ssh being able to run external commands, we can do what I suggested in issue #90 in osv.gt, which is a simple per-thread file descriptor feature: File descriptors 0, 1, 2 to behave differently on different threads (all other file descriptors will be shared, as usual on a process-less system).

[tzach]

IMHO its better to invest on a run API rather than the CRaSH CLI.
Output of the program should be pushed into the log
See #46

[dorlaor]

On Sun, Apr 13, 2014 at 12:38 PM, Tzach Livyatan
[email protected]:

IMHO its better to invest on a run API rather than the CRaSH CLI.
Output of the program should be pushed into the log

The best way is to combine the suggestion - send the in/out streams through
the api to be consumed by
a local CLI running on the client machine. It needs Nadav's changes and
later when we have the api we can move
to it too

Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-40303510
.