This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
initial suggestions re. compiler server (bug #6565)
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Dave Brolley <brolley at redhat dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Thu, 29 May 2008 13:40:25 -0400
- Subject: initial suggestions re. compiler server (bug #6565)
Hi, Dave -
(Background: we're prototyping a compile server split of stap, to
allow a central network server to perform arbitrary script translation
and compilation for a machine without local debuginfo nor compiler.
It'll be useful later for unprivileged user-space probing too. Some
prototype code is in bug #6565.)
Here are some suggestions about the prototype code.
* The code might as well get checked into git and be developed there;
it does not need to be make-install'd or systemtap.spec'd until
later.
* The scripts are not #! /bin/sh but rather technically #! /bin/bash.
* The wire protocol can probably do everything based on two
unidirectional bits of communication: one client->server tar.gz
file to encode the arguments, given tapsets, the script; and one
server->client tar.gz file to encode the results (.ko/.c files,
stdout, stderr).
* It should be testable now even without networks via dejagnu making
two named pipes ("mknod p FOO.1; mknod p FOO.2") and then starting
the server & client scripts with redirected stdout/stdin.
* The networking aspect of it need not go through xinetd. If we can't
find a suitable shell-script-invokable tool to create/attach-to
listening sockets, then perhaps a few-liner perl script could do the
job. That same perl script can use avahi-publish-service to push
the actual (random) listening port number into mdns, so that 65000
number need not be hardcoded anywhere. Clients would find the
server by abstract type (not _http._tcp but something like
_systemtap._tcp) and name, and particularly with some cleverly
chosen TXT description that should identify the server's assigned
cross-compilation target.
* The client is not using the right avahi search entry points AFAIK.
The avahi-discovery gui can pick up the full address/txt bits, and
those are what the client will need to choose its favorite server.
There must be some other command-line tool for that.
- FChE