Date: Thu, 30 Apr 2009 18:31:06 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: "M. Warner Losh" <imp@bsdimp.com> Cc: stas@FreeBSD.org, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, brde@optusnet.com.au Subject: Re: svn commit: r191677 - head/usr.bin/du Message-ID: <20090430172939.M1225@besplex.bde.org> In-Reply-To: <20090430.011913.-1023162474.imp@bsdimp.com> References: <200904300124.n3U1Or1w097927@svn.freebsd.org> <20090430162311.T2904@delplex.bde.org> <20090430110739.682cc989.stas@FreeBSD.org> <20090430.011913.-1023162474.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 30 Apr 2009, M. Warner Losh wrote: > In message: <20090430110739.682cc989.stas@FreeBSD.org> > Stanislav Sedov <stas@FreeBSD.org> writes: > : On Thu, 30 Apr 2009 16:36:38 +1000 (EST) > : Bruce Evans <brde@optusnet.com.au> mentioned: > : > : > On Thu, 30 Apr 2009, Warner Losh wrote: > : > > : > > Log: > : > > Report the next directory being scanned when a ^T is pressed (or any > : > > SIGINFO). Provides some progress report for the impatient. > : > > : > The impatient should use a tracing utility instead of encrufting > : > individual utilities. > : > : On the other hand, using tracing utilities is not the best way to retireve > : status information in all cases. It just handles many more cases better than encrufting utilities does. > Especially if one started the job and then it seems to be "stuck". > It is most efficient to know if something is going on, and ^T gives > that with a very minimal set of code. No, this case is handled almost identically for utilities (like all the encrufted ones starting with cp) whose activity consists mainly of making syscalls -- both will report no output. The tracing utilities should be able to better when started with -p pid by determining if the process is in a syscall (blocked or not) on startup. Testing processes blocked in sleep(100) shows some bugs in truss(1): - under ~5.2, truss without -p doesn't report the nanosleep() syscall until after 100 seconds, while ktrace without -p (plus kdump to watch) reports the syscall as soon as it is made followed by syscall return 100 seconds later. I think truss only reports syscall completion, so it works less well than ktrace for watching blocked syscalls. - under ~5.2, both truss and ktrace/kdump with -p report the completion of the syscall after 100 seconds. - under -current, truss with -p is broken. It now aborts the nanosleep() immediately with EINTR. ktrace with -p still works correctly. > Tracing utilities produce way too much output... This is a feature. Instead of being restricted to the output that has been encrufted, you can get fairly complete details of non-internal (i.e., syscall) activity and filter out the parts that you don't want to see. Of course, large utilities with lots of internal state that might be interesting to follow cannot be handled well by either ^T or tracing utilities. I hestitate to point out that your patch could be made less encrufted and more useful by making it toggle the -v flag. It could be made more encrufted and more useful by subverting ^T further to cycle through various combinations of flags, in particular -i for cp and rm. Toggling -i would fix the missing interaction of turning off -i in -i mode itself Full encruftion would add GUI interaction to all the little utilities, making them perfectly large and un-unixlike. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090430172939.M1225>