hi folks.


i've been looking at fixing up the remaining issues with compat/netbsd32.
one of them is ktrace/kdump.  currently this doesn't work very well.. there
is little interpretation of arguments, the arguments are wrong in some
cases anyway, etc..

i have patches to kdump that allow 32 bit apps on 64 bit kernels to be
traced - but so far only with the 64 bit kdump.  there are multiple cases
that could be supported but i think something like this should work:

	- 32 bit ktrace should generate 32 bit ktrace.out records

	- 64 bit ktrace should generate 64 bit ktrace.out records

both of these irrespective of what size the application itself is.  this
is because you'll likely (and this will "force" the case) to be running
the same sized kdump as ktrace.  ie, running 64 bit "ktrace" and then
32 bit "kdump" or vice versa will be documented to lose.


i'm not entirely sure how to implement this yet.  much of kern_ktrace.c
is quite hard coded to the running kernel size.  from sys/ktrace.h:

	struct ktr_header - has 64 bit struct timeval & pointer

	struct ktr_sysret - has two 64 bit register_t values

	struct ktr_psig - has 64 bit sig_t (function pointer)

	struct ktr_mool - has 64 bit size_t

all need adjustment to write out 32 bit ktrace.out entries.  given that
the ktrxxx() entry hooks are (a) hard coded, and (b) scattered across
the tree, does anyone have any suggestions on how to actually do this,
considering that compat/netbsd32 works as an LKM currently?  one possible
method would be to move the ktrxxx() entry points into struct emul...
but i'm not sure i like that much.


anyone?


.mrg.


ps:  this issue is orthogonal to the "versioned" ktrace.out files but
it's possible this could be used to later remove the restrictions on
what sort of format ktrace.out "kdump" could understand.  but i see
that as a much more future step - mix-matched ktrace/kdump is and will
probably always be an extremely rare case.