Re: cvs commit: src/sys/sys ktr.h src/sys/conf options src/sys/kern kern_ktr.c src/sys/i386/conf LINT

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:On Tue, Jun 21, 2005 at 12:59:00PM -0700, Matthew Dillon wrote:
:>     I don't understand the problem.  I am not logging stack pointers, and
:>     you can log as few or as many arguments as you want, up to the 40 byte
:>     limit.
:
:Argh, partly my fault :) OK, let me say it differently. I think this really
:will hit us once we want to support strict alignment platforms, since the
:simple IA32 modell for variadic arguments might not work there. The compiler
:can create padding between the arguments and it would be very difficult to
:trace such cases down. That's one reason why the original KTR was restricted
:to basically pointers and things which can be casted into pointers.

    I'm not particularly worried about that.  It is just a matter of figuring
    out the number of bytes to copy, since the argument format passed to
    the KTR logging function is padded by the compiler and thus will be
    padded correctly for the format string when it is printed, as long as
    the overall size is known. 

:Another, much more important issue is that you removed the ability to
:compile only a single trace point in. That's perhaps the most important
:feature of KTR after all. When I'm interested in malloc, I don't want to
:get all the data from the network stack for example.
:
:Joerg

    I did not remove the ability to compile only a single trace point in.
    If you do not set option KTR_ALL, and instead do individual KTR_<BLAH>
    options, you will be compiling only the selected trace points in.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>