Date: Thu, 20 Apr 2006 08:38:36 -0700 From: "David Kirchner" <dpk@dpk.net> To: "Peter Jeremy" <peterjeremy@optushome.com.au> Cc: arch@freebsd.org Subject: Re: Add some more information in the ktrace(1)/kdump(1) output Message-ID: <35c231bf0604200838w224c810cue82beace0d63f18b@mail.gmail.com> In-Reply-To: <20060420091534.GA709@turion.vk2pj.dyndns.org> References: <35c231bf0604191339m598d9b7n6681421403d5d4e1@mail.gmail.com> <20060420091534.GA709@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/20/06, Peter Jeremy <peterjeremy@optushome.com.au> wrote:
> Looks good. One improvement I'd suggest is to report both raw hex as wel=
l
> as decoded output - eg the way a printf(9) %b format looks. This would
> make the above look like:
>
> 32229 telnet CALL mmap(0,0x8000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_=
PRIVATE|MAP_ANON>,0xffffffff,0,0,0)
> 32229 telnet CALL open(0x2807bc28,0<O_RDONLY>,<unused>0x1b6)
> 32229 telnet CALL socket(PF_INET,SOCK_DGRAM,0)
Yeah, I could see a benefit to that. Easy to add.
> >more data in the dump output. I'm thinking, specifically, adding
> >KTR_STAT for stat() results and KTR_SOCKADDR for connect(), bind()
> >arguments, and accept() results.
>
> Wonderful. IMHO, the lack of struct sockaddr decoding is the biggest
> drawback of ktrace (though I admit I've never been sufficiently
> annoyed at the lack of support to actually implement it).
>
> Some comments on the code approach (these are personal opinions -
> feel free to ignore them):
> - I find case statements easier to follow than very long "else if"
> clauses.
I do, too. I built on the existing if/else structure already there,
but I wasn't sure of the best accepted style to use.
> - Have you considered a semi-interpreted approach to allow more
> generalised decoding (less special-cased code)?
> [..]
> /*004*/ { SYS_write , "write(dbd)d" , 3 , printargs_write , printret_writ=
e } ,
>
> The string contains the syscall name, the argument types in
> parenthesis (b - buffer, d - signed decimal, p - pointer, o - octal
> etc) and a return type, the number of arguments and functions to print
> the arguments and return values. (The return handling wouldn't be
> relevant to ktrace). About 3/4 of the Tru64 syscalls can be handled
> using the generic printargs_gen().
That does look great. I'll give it a shot. I was definitely getting
concerned over the number of different functions inside each
if(...SYS_foo){} statement. It's easy to make a mistake there.
> Since ktrace doesn't need special handling for syscalls that have I/O
> buffers or various structures (they are passed via different KTR_xxx
> records), FreeBSD is even more amenable to generic argument processing.
> I suspect that virtually all of the FreeBSD syscalls could be handled
> in a similar manner if a %b option string and an enum decoding
> structure (or two) could be passed via a similar sort of table.
Yeah. That sounds good. The original patch should probably not be
committed then, since it'll just get changed again Real Soon Now(tm).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35c231bf0604200838w224c810cue82beace0d63f18b>