Subject: Re: Linking against Linux binary modules
To: Christos Zoulas <>
From: Eric Haszlakiewicz <>
List: current-users
Date: 09/28/2006 19:59:30
On Thu, Sep 28, 2006 at 09:23:12PM +0100, David Laight wrote:
> On Thu, Sep 28, 2006 at 12:53:27PM -0500, Eric Haszlakiewicz wrote:
> > 
> > 	Right, but you only have to do that for the linux functions that you use
> > from NetBSD code.  Then the shim does:
> > foo_shim()
> > {
> > 	convert args
> > 	syscall to switch emul mode to linux
> > 	call linux func
> > 	syscall to switch emul mode back to netbsd
> > 	convert return values
> > }
> That won't work for all system calls - I strongly suspect that some linux
> libraries (and programs) contain the asm statements for the actual trap.
> So the kernel would need to know the PC ranges for the different emulations.
> (and the thought of on-stack asm shims......)

	huh?  Why does it matter how the linxu code does the trap?  Once the
program counter is in the linux code the kernel would think that the process
is a linux binary, so the syscall table is the linux one.  The kernel
doesn't need to know PC ranges, it just needs to be told when the switch
happens (which is the whole point of the shim function).  Of course, things
get a little hairy if you want the linux code to be able to call back
into the netbsd code, but I don't think it's that bad.

	The thing is, for this to be feasible the shim functions needs to
be generated mostly automatically.  (not necessarily on the fly).  
I'm imagining a system where you have:
	1- a dynamic linker that causes foreign emulation symbols to be
	  prefixed with the name of the emulation.  e.g. linux function foo()
	  would be visible to a native netbsd function as linux_foo(), and
	  vice versa.
	2- a shim generator tool that takes as input: header files, along with
	  a set of general specs for converting common data types from one
	  emulation to another, along with custom translation functions for
	  the trickier API entry points.  It outputs some C files that get
	  compiled into a library using native tools.

Then, the netbsd program links against the shim library, which is linked
 against the linux library and everything works perfectly, causing
 happiness and joy and whirled peas to spread throughout NetBSD-land.