Subject: Re: another kdump problem
To: None <>
From: Niklas Hallqvist <>
List: tech-kern
Date: 09/05/1995 03:10:43
>>>>> "Charles" == Charles Hannum <> writes:

Charles> In article <199508260044.UAA18674@Collatz.McRCIM.McGill.EDU>
Charles> mouse@Collatz.McRCIM.McGill.EDU (der Mouse) writes:

Mouse>    Wouldn't it be better to have ktrace emit a special record
Mouse> the first time any given <emulation,syscall> pair is emitted,
Mouse> giving the name of that syscall?

Charles> It would be simpler and more efficient to just have it dump
Charles> the entire syscall list at the beginning of the output file.
Charles> It's probably smaller than the code to keep track of which
Charles> syscalls have been used, so it's not as if this will be a
Charles> problem.

I've implemented this and it works fine.  My changes touches the
following part of the system.

1	Emulations are now kept in a table, emulsw, with place-holders
	for LKMs.  It's up to the init/deinit function of an exec
	package LKM to register them there however.

2	The size and the contents of this table is available by the
	sysctl(3) interface.  The man page has been updated.

3	When not in append mode and when running on a kernel that
	supports the sysctls, ktrace will output a header containing a
	magic number and the emulation/syscall table in the ktrace.out

4	Kdump will check for the magic and read the table if it's
	there, otherwise falling back to the old static behaviour (not
	defining all possible options that might add syscalls before
	including the *syscalls.c files).

5	Let file(1) know about the new ktrace dump format.

6	The sysctl(1) has been made aware of the emulation MIB vars.

Could this be interesting to anyone?  Core?  Have I forgotten something?


Molndalsvagen 95	Email:
S-412 63  GOTEBORG	WWW:   Here