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

[fche at redhat dot com (Frank Ch. Eigler)]

Hi -

Thanks for assembling the notes and being so patient with feedback.
Overall it looks fine.  Some quibbles:


The proposed command line options are sometimes a bit baroque.  If you
excuse the bike-shedding, something like

       stap --authorize=[local|global],[add|remove]
e.g.   stap --authorize=local,remove

looks grammatically paradoxical.  Maybe fork it into
--add-auth=[local|global] and --del-auth=[local|global].  Also,
"local" vs "global" are poor names for "this user" vs. "all users".

(It may help to make the option keyword the verb and the parameter an
object of the verb.)


Re. stap --server-status=trusted, how would stap determine the
trustedness of remote servers?  Do they advertise their ssl/signing
keys?


Re. staprun server searching, I'd rather not go down that road.
staprun is setuid, and thus by itself argues for minimal function
rather than growth.


Some suggestions:

The stap --daemon option should support invocation via inetd (i.e.,
with live sockets on stdin/stdout, with port numbers indirectly
assigned by sysadmin), as well as a self-serving mode where stap picks
a port number for itself, optionally advertises via avahi, and loops
in an accept(2) loop.


The particular constraint of enforcing file size limits on incoming
request packages might be solved by using an uncompressed packaging
format such as tar.  Such a change would necessitate consideration 
about backward compatibility (old/new clients/servers trying or
being prevented from talk to each other).


Build-wise, it will be necessary to make all this merged code optional
based on build-time autoconf tests.  This could complicate the logic
for stap command line processing even further; the changes will have
to be tasteful.


The proposal does not address several robustness issues identified in
section 3, "size of request packages" etc.  While one may assume that
such issues will be dealt with once stap-server and stap are merged
together, it would be worthwhile to elaborate as to *how*.  There is
little reason in principle why those constraints couldn't be
identically applied in the current stap-server-connect.c code.


I wonder actually if it would make more sense to merge the *client*
side into stap first, then see if merging stap-server into stap is
still necessary.  After all, it is the client side that a normal user
sees, and automation/transparency at that point would be ideal.


It would be nice to see a list of all the typical commands remaining
post-proposal, and perhaps a parallel table listing the status quo.


- FChE