In article <20040422083606.GA16676@NetBSD.org>,
Andrey Petrov <petrov@netbsd.org> wrote:
>-=-=-=-=-=-
>
>Folks,
>
>I needed low-level memory buffer tracing and I took freebsd's kern_ktr.c
>for that. I stripped 'bells and whistls' like sysctl control and saving in
>file,  because I don't think they are really needed and it would take more
>time for porting. Main reason was replace sparc64 traptrace with something
>more generic and flexible, uvm_history seems closest by functionality
>but too tied to
>uvm and somewhat too heavy for .S codes. So I ended up with freebsd's
>kern_ktr and that's light-weight, simple and convinient interface.
>
>It has mi and md parts, buffer itself, ktr_traptrace and db_show_ktr in mi (and
>for mi, and C code) and CATR assembler macro for md.
>
>Now, I use it in sparc64 and did support only for sparc64, and put those
>traces only in sparc64. I'd like to go on with it further and commit it
>eventually (sooner better). The problem is that it's not likely that I will
>add support for other platforms or put traces in common parts in short
>time frame
>but the feature is optionable so it wouldn't hurt to have it in sys and kern
>directories. It's possible to put everything in sparc64 directory as an
>alternative approach but no,
>
>I'm attaching main pieces of kern_ktr here for your review. I'd like to
>commit after some clean-up. Opinions? objections?
>

Our cpp supports varyadic macros now, so there is no need for the multiple
macro kludge.

christos