From owner-freebsd-arch@FreeBSD.ORG Thu Apr 20 15:38:39 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE5DB16A428 for ; Thu, 20 Apr 2006 15:38:38 +0000 (UTC) (envelope-from dpkirchner@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E70143D69 for ; Thu, 20 Apr 2006 15:38:37 +0000 (GMT) (envelope-from dpkirchner@gmail.com) Received: by uproxy.gmail.com with SMTP id m3so163266ugc for ; Thu, 20 Apr 2006 08:38:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZuiLVCkzuqqf8iL/PmK3UyOCMvitwDOq7QKp9PcPM7FwScxDz6leqVuQc6qlLqDjgrBIzc5aNLX1eYKSqsbsQLCa8kC/fM69joSdGRlJvrT3Or9aTnfKAdI1Qehg0Lb7BhHp/Wz2LuyOgdDCzUDwPAhXV/TfvAOKW5R+htriQH4= Received: by 10.78.32.14 with SMTP id f14mr35914huf; Thu, 20 Apr 2006 08:38:36 -0700 (PDT) Received: by 10.78.13.2 with HTTP; Thu, 20 Apr 2006 08:38:36 -0700 (PDT) Message-ID: <35c231bf0604200838w224c810cue82beace0d63f18b@mail.gmail.com> Date: Thu, 20 Apr 2006 08:38:36 -0700 From: "David Kirchner" Sender: dpkirchner@gmail.com To: "Peter Jeremy" In-Reply-To: <20060420091534.GA709@turion.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <35c231bf0604191339m598d9b7n6681421403d5d4e1@mail.gmail.com> <20060420091534.GA709@turion.vk2pj.dyndns.org> Cc: arch@freebsd.org Subject: Re: Add some more information in the ktrace(1)/kdump(1) output X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2006 15:38:39 -0000 On 4/20/06, Peter Jeremy 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,0x1002,0xffffffff,0,0,0) > 32229 telnet CALL open(0x2807bc28,0,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).