I hadn't looked into this closely when I responded before.
CONFIG_REGPARM, aka -mregparm=, is like a virus. If a kernel is compiled with it, all loadable kernel code must also be compiled with it (at least; it should cross the syscall interface into user space, but I'd have to build some code and do some tests to be sure).
Dave Grothe wrote:
This is extremely nasty and poses a big problem.
Conceivably this could force all STREAMS driver writers to compile their drivers with "-mregparm=3" in order to be able to run on SuSE 9.1.
I can handle the compile option, but recompilation will certainly be mandatory.
LiS already has different options for kernel vs. user space; this is just another. My biggest problem with such options is that accomodating them internally implies knowing and understanding all kernel config options, which is a tall order. I would as soon do something similar to what was previously suggested, i.e., defining something like KOPTS (I think MODOPT would serve this purpose, but I haven't reviewed that thoroughly yet) that the person building LiS can pass on the command line, e.g.,
make EXTRA_MODOPTS='-mregparm=3' ...
Then Configure & the makefiles wouldn't have to know about all the kernel options.
If it's a frequent enough option, though, we could do a special Configure option for it; that's not a big deal anymore.
If LiS is compiled with that option then STREAMS drivers must be as well since they call functions within LiS and must follow the subroutine calling convention.
Absolutely.
The most desirable outcome would be for LiS to provide wrapper functions for the kernel routines, as it now does via osif, lismem, lislocks and lispci, and make these wrapper functions callable with stack parameters as in the past, but with the calls to the kernel functions able to use register passing.
That would defeat the purpose, in my view.
But here's the problem. Consider:
int lis_foo(args) { return(kernel_foo(args)) ; }
How do you get lis_foo to compile for stack arguments and kernel_foo to compile for register arguments? Not just by setting "-mregparm=3" on the compiler command line.
You don't. The GCC man page notes that -mregparm= applies to all.
That makes sense; these are different calling conventions, after all.
Does anyone know of GNU C pragmas or the like to do this? If so, please let me know.
It could be done with assembler code but there goes the portability to other architectures.
It _is_ done with assembler code - code that GCC generates, hence the GCC option (-mregparm= is a GCC option). Trying to tweak this gets one into the heart of GCC; a good percentage of GCC is just for handling RTL (GCC's "register transfer language").
In net effect, this will amount to a different target architecture, given a base machine architecture. Calling conventions are that fundamental.
-- Dave
At 02:52 PM 5/27/2004, Steffen Hieber wrote:
Anyway, the crash which led to patch2.LiS had nothing to do with the missing or wrong format arguments, the reason for the crash is the CONFIG_REGPARM option SuSE enabled when building the default kernel. With CONFIG_REGPARM=y the kernel and the kernel modules are compiled with the compiler option "-mregparm=3", with which the first three arguments of a function call are passed in registers. With this option set in the kernel, LiS needs to be compiled with the same compiler option (kernel space only, not the user space utilities).
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
