So we need:
int lis_shim_stackargs_foo(args)
{
return(kernel_regargs_foo(args)) ;
}
My question is: Does anybody know any gcc judo that can cause lis_shim_stackargs_foo to be compiled using stack argument passing and the call to kernel_regargs_foo to be compiled using register argument passing? That is the tool needed to turn osif.c and its sidekicks into the needed shim functions.
-- Dave
At 04:51 PM 6/8/2004, Brian F. G. Bidulock wrote:
Dave,
Any driver that uses *any* kernel symbol not wrappered by LiS (and there
are lots to choose from) will not be binary compatible across kernel
builds regardless of what LiS does or doesn't do. Those wanting to release
a single driver binary could distribute GPL'ed shim source along with the
binary ala the Nvidia drivers. The user compiles the GPL'ed shim against
the built kernel and exports symbols to the driver. The shim can use 2.4
makefile rules or 2.6 kbuild for compatibility. Binary shims for popular
distro kernels can be released in distro packages.
Now, this is not different in approach to the wrappers that are included
with LiS; however, the shim need only contain those symbols needed by the
driver rather than attempt to wrapper every kernel symbol known to man
across every kernel version or distro hack. Otherwise, you will always
get a request for an lis_foo or an lis_bar function that is not included
in osif, but, then, I suppose that *is* the current situation, isn't it?
See the drivers released by Nvidia (the shim code is open source) for a
straightforward approach to accomodating the lack of a kernel abi.
I don't care that much, all our code is released as source. Binary packages
are only for convenience. Releasinng as source on GNU platforms will always
be easier than releasing as binary.
--brian
