Yes, I totally agree with your assessment. And yes, there is such a mechanism, very close to what I speculated. For your example, it would be
int kernel_regargs_foo(args) __attribute__ ((regparm(<x>)))
analogous to the compilation-unit option "-mregparm=<x>".
But I'm still not wildly in favor of this shimming/wrappering business in this case. CONFIG_DEV is a mess, and this will be worse, because it's not one or the other, it's both at the same time, and it will affect EVERY kernel-exported symbol.
2.6.6 allows loadable modules to export their own symbols, by the way, and my build changes for 2.6.6 fully support LiS exporting its own symbols, which it must do, if only to dependent drivers and modules. That being the case, this shimming/wrapping business can't be just one-way; you should (and possibly must) also wrap stack-convention symbols that LiS defines to make them register- convention for other code to use.
And LiS-dependent loadables will still be faced with the issue for those kernel-defined symbols it wants to use that LiS hasn't used and shimmed for itself. They'll have to do their own shimming/wrapping, on a per-symbol basis. At the least, they'll have to make a per-symbol decision. No fun.
I see a real mess brewing if you try to do this.
-John
Dave Grothe wrote:
The point of this shimming business is that the binary driver will be calling the shim function using stack conventions for passing arguments. And the shim function must call the kernel function using register passing.
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
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
