head.S and syscall 201

[Samuel Rydh]

On Mon, Jan 20, 2003 at 11:38:48PM +0100, Johan Högberg wrote:
> I'm investigating if it's possible to get MOL working on
> Simics/PowerPC (http://www.simics.com).
> (It will probably be too slow for any serious use, but's
> an interesting task and a good test on Simics).

Yes, MOL exercises most of the features of the PowerPC
processor so this is indeed a good test.

> I'm wondering how MOL hooks into the kernel.
> When I compare two linux versions (2.4.2 and 2.4.17) I can
> see that the 2.4.2 version has MOL_HOOK() macros first in the
> exception handlers in head.S.
> This makes sense, but the 2.4.17 kernel does not have these.
> Could both versions work? How?

Both versions work. The MOL_HOOK() stuff is obsolete and no longer in use.
Instead of relying on hooks, MOL nowdays patches the entrypoint of
all exception vectors.

> Secondly, so far the MOL kernel module loads ok but the mol
> application later crashes due to an illegal instruction (it jumps to
> a strange address) after syscall 201. Is this syscall something
> specific to the MOL kernel module or is it inside the kernel?

Syscall 201 is mol-specific. It is the main entry-point
of the mol-kernel module (excepting the low-level asm code).

The implementation is in the function sys_macos_multiplexer()
in mol/src/kmod/misc.c. The syscall is primarily used by the
mol userspace process to setup the mol-kernel module properly
but it is also used as a trampoline from the low-level asm code to
the high level C code.

> Finally, when compiling I had KHEADERS pointing to the location
> of my linux header files. 

Good.

> The user guide on the web also says that 
> /usr/include/linux and /usr/include/asm should point to the linux 
> headers. 

The guide is wrong. You shouldn't touch /usr/include/linux nor 
/usr/include/asm.

> I didn't change these links (compiled on another PPC box
> with a different 2.4.x kernel), it compiled alright but could it
> be a source for errors as well?

Nope.

Good luck,

/Samuel