Antigen forwarded attachment

The entire message "freebsd-arch Digest, Vol 157, Issue 5", originally sent to you by owner-freebsd-arch@xxxxxxxxxxx (owner-freebsd-arch@xxxxxxxxxxx), has been forwarded to you from the Antigen Quarantine area.
This message may have been re-scanned by Antigen and handled according to the appropriate scan job's settings.



<<Entire Message.eml>>
--- Begin Message --- Send freebsd-arch mailing list submissions to
freebsd-arch@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
or, via email, send a message with subject or body 'help' to
freebsd-arch-request@xxxxxxxxxxx

You can reach the person managing the list at
freebsd-arch-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-arch digest..."


Today's Topics:

1. Re: Add some more information in the ktrace(1)/kdump(1)
output (David Kirchner)
2. Re: remove rid pointer (but not rid)... (M. Warner Losh)
3. Re: nawov news (Sylvana Edgecomb)


----------------------------------------------------------------------

Message: 1
Date: Thu, 20 Apr 2006 08:38:36 -0700
From: "David Kirchner" <dpk@xxxxxxx>
Subject: Re: Add some more information in the ktrace(1)/kdump(1)
output
To: "Peter Jeremy" <peterjeremy@xxxxxxxxxxxxxxxx>
Cc: arch@xxxxxxxxxxx
Message-ID:
<35c231bf0604200838w224c810cue82beace0d63f18b@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1

On 4/20/06, Peter Jeremy <peterjeremy@xxxxxxxxxxxxxxxx> wrote:
Looks good. One improvement I'd suggest is to report both raw hex as well
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_write } ,

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).


------------------------------

Message: 2
Date: Thu, 20 Apr 2006 10:40:48 -0600 (MDT)
From: "M. Warner Losh" <imp@xxxxxxxxxx>
Subject: Re: remove rid pointer (but not rid)...
To: phk@xxxxxxxxxxxxxx
Cc: arch@xxxxxxxxxxx, gurney_j@xxxxxxxxxxxxxxxxxx
Message-ID: <20060420.104048.57443855.imp@xxxxxxxxxx>
Content-Type: Text/Plain; charset=us-ascii

In message: <3731.1145513558@xxxxxxxxxxxxxxxxxx>
"Poul-Henning Kamp" <phk@xxxxxxxxxxxxxx> writes:
: In message <20060419.165709.22017808.imp@xxxxxxxxxx>, "M. Warner Losh" writes:
:
: >This will, of course, be a big undertaking in the tree. There are
: >1216 instances of the string 'alloc_resource' Every single one of
: >them will need to change in some way.
:
: Most of them could beneficially change to use bus_alloc_resources(),
: thereby improving the code (there are far too many bugs in the error
: handling) and at the same time cutting the 1216 in half or further
: down.

Agreed. I think I made that point a little later in my post. The big
difficulty here is testing the driver after the changes to make sure
that no unintended bugs have been introduced.

Warner


------------------------------

Message: 3
Date: Thu, 20 Apr 2006 18:55:14 -0400
From: "Sylvana Edgecomb" <edgeci@xxxxxxxxxx>
Subject: Re: nawov news
To: freebsd-arch@xxxxxxxxxxx
Message-ID: <000001c664cd$7c8e4650$5944a8c0@pow45>
Content-Type: text/plain; charset="us-ascii"

Dea r r Home Ow i ne q r ,

Your c p red x it doesn't matter to us ! If you O y WN real e g st f at
f e
and want I v MMED a IAT i E c y ash to sp k en f d ANY way you like, or
simply wish
to L g OWER your monthly p z aym z ents by a third or more, here are the
dea s ls
we have T t ODA u Y :

$ 4 i 88 , 000 at a 3 , g 67% f z ixed - rat z e
$ 3 r 72 , 000 at a 3 , s 90% v p ariabl z e - rat l e
$ 49 w 2 , 000 at a 3 , 2 m 1% i c ntere b st - only
$ 2 r 48 , 000 at a 3 , a 36% fi z xed - rat d e
$ 1 i 98 , 000 at a 3 , a 55% v j ariable - ra d te

Hurr i y, when these d x eaIs are gone, they are gone !

Don't worry about app x rov o al, your c g red b it will not d o
isqualif j y you !

Vi m si u t our si h te <http://EvdokffatonA.iwarp.com/>

Sincerely, Sylvana Edgecomb

Ap z pro f val Manager



------------------------------

_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

End of freebsd-arch Digest, Vol 157, Issue 5
********************************************


--- End Message ---
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"