In article <1g6qod8.1dz4k3kyqy4fjM%manu@netbsd.org>,
Emmanuel Dreyfus <manu@netbsd.org> wrote:
>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.

Right. This is why it is a bad 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.

That sounds better.

>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.

We could do that, but kdump is of limited use between different OS's.

>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? 

I don't think having kdump work across different OS's is going to be
easy and it will require a lot of maintainance.

Finally we should bite the bullet and add a version record and magic
identification number to the file, so that we can make backwards compatible
changes. Right now, we need to put lwp id's in it, and it is not easy
to do without breaking backwards compatibility.

christos