[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4772EF95.9060003@tmr.com>
Date: Wed, 26 Dec 2007 19:19:33 -0500
From: Bill Davidsen <davidsen@....com>
To: Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
CC: "linux-os (Dick Johnson)" <linux-os@...logic.com>,
Sam Ravnborg <sam@...nborg.org>,
Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: Trying to convert old modules to newer kernels
Lennart Sorensen wrote:
> On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote:
>> I need to get rid of -mregparm=3 on gcc's command line. It
>> is completely incompatible with the standard calling conventions
>> used in all our assembly-language files in our drivers. We make
>> very high-speed number-crunching drivers that munge high-speed
>> data into images. We need to do that in assembly as we have
>> always done.
>
> Well I guess you can either fix the assembly once and for all to handle
> the current linux way of doing things, or you can patch to kernel back
> to the old ways of doing things when using your driver.
>
> I suppose you could just add some wrapper functions to your assembly
> that uses the new regparm calling method and then calls your methods the
> old way and selectively enable those when regparm is used by the kernel
> if you want to support all kernel versions. Or you could use inline
> assembly in C functions to handle the calling convention for you.
If I were to guess, based on nothing but what's in this thread, people
who write modules in assembler would want to avoid the the wrapper
overhead. Of course putting image processing in the kernel at all
instead of user programs is not something I ever do...
--
Bill Davidsen <davidsen@....com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists