This is the mail archive of the 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]

Re: pre-compiled systemtap modules (try 2)

Frank Ch. Eigler wrote:
David Smith <> writes:

Instead of "-P", why not have stap just realize it's been given a module
and it automatically does the right thing?
Hmm.  You do have a point here, because with the patch it is possible to
do something like stupid like "stap -P foo.ko bar.stp".

We should consider separating the compile / run front-ends into separate programs entirely, perhaps by promoting and renaming stpd ("staprun")? This makes sense further because we will want to make it possible to install only a small subset of systemtap itself on a deployment machine in order to run a pre-compiled script.

Hmm. That's an interesting idea. If we were to do that, we might think about unifying option names between the two programs. Currently, we've got functionally equivalent options named different things between the 2 programs:

stap		stpd
====		====
-v		-q
-M		-m
-x pid		-t pid
-s size		-b size

I'm unsure about separating the programs. I don't have a strong feeling for it.

Why not "-S [dir]" so that the current directory is the default?
That is certainly possible [...]

Actually, not really, with getopt. A flag must or must not take a parameter, otherwise it leads to parsing ambiguities.


David Smith
Red Hat, Inc.
256.217.0141 (direct)
256.837.0057 (fax)

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