Subject: Re: kdump dependency on kernel, ktrace id portability
To: Nathan J. Williams <firstname.lastname@example.org>
From: Emmanuel Dreyfus <email@example.com>
Date: 12/29/2003 22:56:44
Nathan J. Williams <firstname.lastname@example.org> wrote:
> > 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.
> Do I understand correctly that you want the ktrace facility to write
> the table of syscall names to the ktrace.out file? How big is that
> table? I'm more concerned with the space it occupies in the kernel
> than the space it occupies in the ktrace.out file.
For native syscalls, it's about 6kB. If we fold the syscall name table
in ktrace.out, we can get rid of the copy in kdump, I'd say this is
about 100kB in the kdump binary (currently it contains the syscalls
names tables for all emulations). If we remove it, we could not read
older ktrace.out anymore, so it's not really desirable, but this could
be a LETS_GET_SMALL ifdef.
> I have to admit that I see this as adding stuff to the kernel to solve
> a pretty minor problem that only happens to developers active in a
> certain area.
It would also enable today's kdump to read next year's ktrace.out files.
But I agree I'm not sure this is a good idea.
Il y a 10 sortes de personnes dans le monde: ceux qui comprennent
le binaire et ceux qui ne le comprennent pas.