Re: Portable binary modules

Michael Meissner (meissner@cygnus.com)
Sat, 11 Dec 1999 23:47:12 -0500

On Sat, Dec 11, 1999 at 01:11:40AM -0500, Michael Nelson wrote:
> On 10 Dec 1999, Peter Samuelson wrote:
> > You binary-module-compatibility people keep pointing at other operating
> > systems as how all this can and should be achieved. OK, question: How
> > does NT solve the problem of keeping compatibility in the face of
> > different optimizations for different CPUs? Answer: single UP kernel
> > and single SMP kernel for *all* x86 CPUs. (Wait, do they even
> > *support* 386? Not sure.) And no inlining of fastpath code like
> > spinlocks. Is this what we want?
>
> I am not trying to get in the middle of this, but I want to mention that
> they NOP out the spinlock codepaths in ntoskrnl.exe and hal.dll when you
> install/update a new kernel on a UP machine.

Far be it for me to aid people in making binary only drivers, but one hack that
I did many years ago when I wrote the Data General C compiler was to make
external symbols into instruction patterns so that the library could be linked
with checking code that would not normally affect the speed of the unchecked
code. For example to check R1 it might lay do something like:

.long __checkr1a
.long __checkr1b
.long __checkr1c

If the checking code was linked in, __checkr1a might be a PUSH R1 instruction,
__checkr1b might be an appropriate call instruction, __checkr1c might be a POP
R1 instruction. If checking was not linked in, the __checkr1{a,b,c} would be
resolved to NOPs. You could potentially do the same thing for UP/SMP, though
the variable instruction sizes on the x86 will make it tricky :-)

-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/