Brendan Gregg - Sun Microsystems wrote: > On Fri, Jul 20, 2007 at 11:49:07PM +0200, Roland Mainz wrote: [snip] > > Now I am wondering whether it may be usefull to put all the tools in > > /usr/proc/bin/ and /usr/bin/ps in a seperate "procsh" (= "process shell" > > (more or less an add-on on top of ksh93)) which allows to combine all > > the operations of these tools within one shell process, output the > > requested information directly into shell variables instead of stdout > > and add extra shell builtin commands to do the process locking > > "manually" at the script level (which would avoid the race condition > > since the target process is only locked once, then all data are > > collected and then script releases the lock (or the shell releases the > > lock when the matching subshell exits)). > > Wow, I thought you were about to encourage something like: > - use of the SE Toolkit > - making libproc a stable interface > - adding a Sun::Solaris::Proc to Perl > I didn't guess ksh93!
See below (as a side-note... try to treat this idea as a ksh version of Sun::Solaris::Proc ... :-) ). > A decision you may have already made, would be whether it is best to > provide builtins for the ptools, or a shell interface to procfs. A > shell interface to procfs would be more useful, but that introduces > other issues (possible exporting /proc data that is unstable). It also > would be close to what the SE Toolkit provides anyway, along with other > features. Erm, the idea to provide something like shell builtins (or better: A loadable plugin library and a frontend called "procsh" which loads the builtins by default) for these tools was based the following thoughts: - Most of the consumers are _simple_ shell scripts, usually either /sbin/sh or /usr/bin/ksh (and when I am thinking about ksh93 I mean that /usr/bin/ksh93 is just an intermediate name until /usr/bin/ksh gets replaced by ksh93) - Some of the shell scripts use multiple proc tools to collect information but the results are usually not accurate because each chunk of data sampled requires an extra |fork()|/|exec()| cycle and extra /proc loocking - Turning the current proc tools into ksh93 builtins is ~~5min work per builtin (assuming the basic infratructure work of adding another library to OS/Net has been done and assuming that the tools propperly create&&destroy all resources they use) - usually you only have to replace |int main(int ac, char *av[]);| for tool "foobar" to |int b_foobar(int ac, char *av[], void *context);| and you can load that command as builtin - Using SE toolkit and/or rewriting the matching shell scripts in Perl only makes sense for larger scripts - IMO it is an overkill for most of the smaller consumers > > Comments/thoughts/ideas/rants welcome... > > You could create such a thing and have customers who don't use ksh93 never > find it, and continue to use whatever "ps" runs in their $PATH. You would > need to successfully market this feature and the benefits to customers. Right... ;-/ > And would other shells continue to run the ptools from /usr/bin? Now we > are supporting two sets of code... Erm, no. Take a look how alias.sh links ksh builtins like "ulimit" to /usr/bin/. The same could be done for the tools in /usr/proc/bin/. We would only maintain _one_ set of sources and one implementation. > So we bring ptools data into the shell and some scripts are now faster. The main idea was not only "speed" - it was the locking+race condition problem I described in my initial email. Currently this is handled very poorly and adding the correct error handling for processes disapearing in the middle of the shell script is slightly nightmarish. > Surely there is more value-add to be found in the shell than a little speed? > Why not PLOT DATA DIRECTLY FROM THE SHELL!!! (and not via gnuplot). > Can dtksh join the party? :) Slightly offtopic: I think there is no hope for dtksh in Solaris anymore (see http://mail.opensolaris.org/pipermail/opensolaris-discuss/2007-February/025562.html - since noone at Sun cares about fixing dtksh I am going to file a RFE to get it removed. In it current state it's even unuseaeble for backwards-compatibilty purposes (and it's broken state (e.g. Solaris dtksh is based in ksh93 version 'd' alpha - this code should've never been used for _any_ production environment) and the resulting (angry!) rants among customers resulted in the creation of the ksh93-integration project) ... ;-( ). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
