Hello

Each time I add a system call or a Mach service, I have to update kdump
to get a proper display ou kernel traces. That's annoying.

This is because kdump embed the syscall name table, which is generated
in the kernel tree. I thought about two ways of removing the dependency
of kdump on the kernel:

First idea: Build a kern.syscalls tree, with the system call names. It
would be invisible from sysctl -a, and would contain R/O nodes, like
this

kern.syscalls.netbsd
kern.syscalls.linux
kern.syscalls.darwin

And so on. Each node would contain a system call table names. kdump
would just have to do a sysctl call when getting an EMUL record to
discover the system call names. For performance sake, we can cache the
values in kdump and only call sysctl for EMUL that have not been
encountered before.

But with this idea, kdump would not be able to read a ktrace.out file on
an older kernel, or on a kernel that does not contain the emulation you
are looking for. This led me to a second idea.

Second idea: create a new EMUL record (with a different id), which would
provide the emulation name with the system call table. This would grow a
bit the ktrace.out files, but they would be readable anywhere.

By using a different id, we retain backward compatibility, and even
compatibility with other BSD's ktrace.

Then we need a way of providing the Mach services table. Just another id
just for that could do it.


Speaking of ktrace id's: in order to have decent debugging tools, I
added two id's for Mach messaging activity: Mach messages at 9 and Mach
out of line data at 12. We also have envp and argc traces at 10 and 11.
As other BSD will also evolve their ktrace interface, I think it could
be nice to avoid conflicting id's so that binary compatibility is
retained on ktrace files. This would be easy, if we used some particular
id ranges for our extensions.  

For now, the only conflict are FreeBSD's and Darwin's USER and our EMUL
at 7. That's a minor problem. There is no conflict with OpenBSD. We
could try to coordinate with other projects to avoid future clashes:
book id 9-12 and a given higer range for NetBSD use, and other higher
ranges for other BSDs. If this is percieved as desirable, I can try to
go and talk to other BSDs.

Given that they have not been used in any release, we could also move id
9-12 to a higher range before we release 2.0: the API is not yet carved
in the stone. Opinion? 

-- 
Emmanuel Dreyfus
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent 
le binaire et ceux qui ne le comprennent pas.
manu@netbsd.org