> I just finished adding ktrace support for emulation switches. The way I
> did it, is to add a KTR_EMUL field similar to KTR_NAMEI that contains
> the emulation name. execve now spits out a KTR_EMUL field when it
> succeeds.  I modified kdump to switch to the appropriate system call
> names array depending on the name in the KTR_EMUL field. The fixes are
> really small...

makes sense.

> The problem with this approach is that when you attach to a process, you
> don't know what emulation it is currently running; you could change the
> attach code to spit out a KTR_EMUL record, or you can leave it to the
> user [what I did: I added a flag to kdump to specify the name of the
> initial emulation].

i'd say that the former is the appropriate solution.  it's annoying
for the user to have to remember that information, especially since:
	(1) one of the prime reasons to use ktrace is to figure out
	    why something's going wrong, and one of the things
	    that could potentially go wrong is the kernel's notion
	    of the process's emulation mode,
	(2) the user shouldn't have to know the names of the various
	    emulation modes,
	(3) they may be looking at the trace file days, weeks, or
	    months later,
	(4) they may be shipping the ktrace file off to Joe Random,
	    who's even less likely to know the right emulation mode.

> A better fix is to include the emulation name on every system call, but
> that will make the trace file much larger.

uh, actually, that's not such a great 'fix'.  The emulation mode for a
given process hardly ever changes (only possible at execve(),
currently), and so that'd not only store a lot of information, but
most of that information would be redundant.

on a related note:

does your set of changes deal with the case of ktracing a process and
its descendents, all of which may be running in a different emultion
mode?  "whee!"  8-)




chris