[request-sponsor] 4532599: ptime should report resource usage
> On Fri, Apr 18, 2008 at 7:32 AM, Richard L. Hamilton > wrote: > > How does this behave with the -p option - does it > just report > > the current usage, or does it wait for the process > to exit and > > report its final usage? If the former (which I > suspect is the case), > > it might be handy to have an option to do the > latter (if possible). > > Yes, it's the former. I looked into performing the > latter, but I > didn't find a reasonable way to do this. Hmm. pwait can get the psinfo as of when the process exits, by using poll(2) to wait for the process to exit; the way I read proc(4) suggests that should work on /proc/*/usage (or /proc/*/lusage if LWP-level detail is desired) as well. > > > > Other wishlist thoughts: > > > > * option for LWP-level detail > > * option to report all the info in struct prusage, > not just times. > > The scope of this request can be found in the PSARC > case: > http://opensolaris.org/os/community/arc/caselog/2007/5 > 98/. I'd be > more than happy to do the work for other additions, > but I'm not > interested in adding anything to this particular > request. Certainly I don't want to slow down one thing getting added by piling on a bunch more; was just looking for a reaction. If you want this on some other list, please CC whichever you think most appropriate (discuss, rfc, code, whatever...). I have a few thoughts on how the things I mentioned might look; if I find some time, I might just try my hand at some code along those lines. In particular, I see the default format for additional usage info being modelled on the rusage(1b) output, since that's already familiar, and prusage contains equivalents to all but the last four fields reported by rusage, at least two of which are apparently no longer useful anyway. This message posted from opensolaris.org
[request-sponsor] 4532599: ptime should report resource usage
How does this behave with the -p option - does it just report the current usage, or does it wait for the process to exit and report its final usage? If the former (which I suspect is the case), it might be handy to have an option to do the latter (if possible). Other wishlist thoughts: * option for LWP-level detail * option to report all the info in struct prusage, not just times. This message posted from opensolaris.org
[request-sponsor] Request sponsor for openSolaris project
> > > > One feature that smartmontools provides that isn't > available with FMA > > is ability to query SMART attributes on a disk. > Smartmontools provides > > the smartctl utility to perform this operation, and > I think that alone > > warrants it's inclusion in opensolaris. > > > > Thanks, > > - Ryan > > Definitely agree. I view there as being two entirely > separate > technology items: > > (a) A set of tools and APIs to examine SMART data > from drives. > These tools could be used manually by admins, and > the APIs > can be used to build management stacks or > telemetry modules for FMA. > (b) Things that consume the data, use it as > telemetry, diagnose it, > and emit that diagnosis to a human or a > higher-level mgmt stack. > I want the smartmontools in Solaris for (a). FMA > already does (b), and > most importantly it integrates that telemetry with > other i/o telemetry > data, in particular silent data corruption detected > by ZFS, to form a > common diagnosis model. Smartmontools also offers a > legacy form of > reporting, i.e. a bunch of syslog error messages and > a weaker form of (b). > > I am similarly ok with including smartmon's > capability for (b), but we need > to make sure that it is off by default (i.e. not > conflicting with the FMA > (b)), and that something sensible occurs if you > enable it, or that we have > a documented procedure for enabling it in a way that > doesn't mess up FMA > or confuse users who are interacting with it. > Two points: First, if smartmontools is GPL, it would _have_ to remain separate from FMA anyway, right? I mean, one couldn't integrate it in terms of linking or mingling code, best one could do would be popen() and parse the output. But I also agree that making the info available in human-readable form with minimal interpretation is desirable, but doing so should not be permitted to impact or cause confusion with FMA functionality. And second, blastwave has a smartmontools package already; which is to say, they already have it ported to Solaris 8 and later (version 5.36, presumably for both SPARC and x86). http://www.blastwave.org/packages.php/smartmontools (In fact, I've used it on my SB2K running SX, not long after I got it 2nd-hand, and again not long after getting some larger and younger FC disks for it; it was nice to know hours of operation, error history, or number of power cycles or whatever such info it could provide, which more or less corroborated what the eBay seller of the used drives claimed, as I recall.) Unless one of those proposing this new port is the blastwave package maintainer shown at the location above, perhaps they ought to talk to him and try to learn whatever they can from what he's done already. And if it's integrated, perhaps the blastwave folks could be asked to add a note that it's bundled with build xx or later, so people don't end up with two copies running and possibly stepping on each other. This message posted from opensolaris.org
[request-sponsor] Requesting sponsor for CR #6451262 ("RFE:
Why do I think you're going to do this in terms of ksh93? :-)
Maybe since it's sleep builtin can do that?
So, will it be
#! /usr/bin/ksh93
# do we need to set PATH to ensure the builtin is used?
exec "$(basename "${0}")" "$...@}"
Or will it be a C wrapper to call b_sleep() in libcmd?
(which if done right could also call any of the builtins,
given a suitable hard or symbolic link; and might have
faster startup than ksh93 itself)
> This is a sponsor request to implement the RFE/CR
> #6451262 ("RFE:
> /usr/bin/sleep should support floating-point values"
> -
> http://bugs.opensolaris.org/view_bug.do?bug_id=6451262
> ).
> An old draft for the matching ARC case can be found
> at
> http://svn.genunix.org/repos/on/branches/ksh93/gisburn
> /arc/sleep/solaris_sleep_fasttrack.txt
> (comments welcome) ...
>
> My contributor ID is "OS0025".
>
>
>
> Bye,
> Roland
>
> --
> __ . . __
> o.\ \/ /.o) roland.mainz at nrubsig.org
> \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix
> programmer
> /O /==\ O\ TEL +49 641 7950090
> (;O/ \/ \O;)
> ___
> request-sponsor mailing list
> request-sponsor at opensolaris.org
This message posted from opensolaris.org
[request-sponsor] Re: Request for a sponsor of a driver for LSI Logic
AFAIK, if they're willing to, employers can sign SCAs too, which might open up that route. This message posted from opensolaris.org
[request-sponsor] Re: Adding status support to dd
Oh, and changes to usr/src/cmd/ttymon/stty.c usr/src/cmd/ttymon/sttyparse.c usr/src/ucbcmd/stty/stty.c usr/src/ucbcmd/stty/sttyparse.c which I'm too sleepy to figure out right now... This message posted from opensolaris.org
[request-sponsor] Re: Adding status support to dd
I'm very tempted to try to do the addition of SIGINFO, but it'd be sort of in
the blind, because I don't have the space to try to actually build it, nor
a system I'd be eager to reload to test it.
Let's see,
usr/src/uts/common/sys/iso/signal_iso.h:
add
#define SIGINFO 41/* information request */
change value of _SIGRTMIN from 41 to 42
usr/src/uts/common/sys/termios.h:
add
#define VSTATUS 16
add
#define CSTATUS CTL('t')
usr/src/uts/common/io/ldterm.c:
break apart the test for IEXTEN and VDSUSP into an outer if for just IEXTEN,
and two inner if's, one for VDSUSP and one for VSTATUS (latter action should
use ldterm_dosig() arguments like those for SIGINT, except for the
signal name).
usr/src/uts/common/os/sig.c:
add SIGINFO to the initializer for ignoredefault.
Is that really all it would take???
This message posted from opensolaris.org
[request-sponsor] Re: Adding status support to dd
I suppose that *BSD ignores SIGINFO by default, so that programs that don't wish to support it aren't bothered? Seems like this _could_ be added, insofar as slots 16-19 of termios c_cc[] are still unused. Have to add another signal too (eating into the number of realtime signals, I suppose). And a few lines to os/sig.c, a #define for VSTATUS to sys/termios.h, io/ldterm.c (looks like VSTATUS should only be interpreted if IEXTEN is enabled?) and I'm not sure what else. And of course a bit of research to see if one could do it in a way reasonably source compatible with Linux and/or *BSD. Alternatively to some of that work, Linux seems to maybe overload SIGINFO as a synonym for SIGPWR, but I'm wondering if that might not be potentially dangerous (I can see someone logged in as root on the console hitting ^T and causing something to shut down!). Still, I don't see that it would necessarily break anything to add SIGINFO support to Solaris, as long as the initial default tty settings didn't enable that special character. And as long as there was some clear understanding how to safely add support for SIGINFO to programs (maybe with the help of a library routine?), it might be kind of cool to be able to ask a long-running program what sort of progress it's making. This message posted from opensolaris.org
[request-sponsor] Re: Request Sponsor for: 6536837 (add -z option to
I suppose one could argue that having it work either like other remote access commands (rsh, ssh, rlogin, telnet, etc) or like the other zone* commands might make it more intuitive. But do you really want to make a command that "only a superuser operating in the global zone can use" so intuitive they don't need to read the man page? If the superuser in the global zone doesn't know what they're doing, bad things are going to happen anyway, why help them evade their own ignorance where it's a mere inconvenience only to encounter it far worse later on? And if you're going to go there, why not allow user at zonename in addition to allowing -l user zonename? (That might actually be good insofar as it rewarded use of ssh syntax; after all, people ought to be using ssh instead of rlogin or telnet whenever possible.) Why not allow -l user _after_ zonename (like some versions of rlogin allow or even require)? Once you start down the road of allowing multiple syntaxes for convenience, where do you stop? Heck, why not make up zone://user at zonename/ URLs? (actually, I suppose one could write a mozilla helper that would run the appropriate zlogin in an xterm if it encountered that, but what idiot would be running their browser as root?) Maybe it's just me, but it sure seems like a slippery slope. This message posted from opensolaris.org
request-sponsor@mail.opensolaris.org
[...] > The two that seem to be most important are the > original timezone RFE and > HOME as neither of these can effectively be worked > around. Though all [...] Couldn't one simply begin one's command with env HOME=/alternate/directory cmd args ? Unless one is worried about .cshrc files or something (and using them for anything other than functions and aliases [such as to set up environment variables when coming in via rsh] is evil anyway). This message posted from opensolaris.org
[request-sponsor] request sponsor for CR 6478299 (strnlen())
meem already said he's sponsor the PSARC fasttrack, so this is just for the code contribution side. I already received my contributor number and can provide that by email. This message posted from opensolaris.org
