lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ