On Wed, May 19, 2010 at 10:18 AM, Bakul Shah <bakul+pl...@bitblocks.com> wrote:
> 0. Name syscalltrace is too long :-) pick a name and I'll change it. > 1. Curiously, an actual errstr is not enclosed in "..". that goes on the bug list. If you want, use the bugtracker at bitbucket.org, on my rminnich/vx32 project, and add these bugs. Also add your changes below as an enhancement and I'll apply it. > 2. Seems long long values are printed as two numbers > (but I haven't checked carefully enough to be sure). that's an error, but I have not seen it. > 3. Printing . for isgraph(char) loses information. that's life. I'm happy to consider a \hex as an alternate print scheme, but that complicates parsing? Not sure. Advice welcome. nemo? > 4. Perhaps buffersize should be settable to deal with > args pointing to large areas. yes. It's on the list of "things I want" > 5. Occasional hangs. Not sure what the cause is. weird. Have not seen this. If you can reproduce it let me know. > > What happens if the passed in ptr points to invalid memory? I used uvalidaddr and you'll get the same error as you would in the system call: suicide. > > Given 3., in the kernel I would've just copied a binary > structure and let the userland worry about any formatting. no. No, no, no, no, no. no. If there is any consistent thing in Plan 9, it's that ctl and other files use text. It's great. This binary idea is a cancer. 1. with text, I can mount /proc from an ARM, and do system call tracing on my 386 laptop: text is architecture-independent 2. with kernel formatting, I can use awk and rc and perl and whatever I want to implement tracing 3. textual formats don't need versioning of binary structures. So, no. It stays as text :-) > I can imagine showing syscalls of each traced process on a > separate scrolling time line. This will allow one to see > timing relationships and call patterns. Zoom to see > appropriate scale, click on a call (or select a range) to see > call details. Can also show who forks whom, with a > connecting line to the new timeline that just popped up for > the new process. Color can be used for procs or syscalls. > etc. Not sure when/if I will get around to implementing > something like this though. That's a very fine idea. Will our draw libraries support an interface with this degree of capability? Note that it's very easy, on Plan 9, with a shell script, to put every traced proc into a different window. Thanks for the corrections! ron
