Intel cites that is a RedHat issue per below email

<snip>
	issuppor.intel.com
	05/20/2003 07:08 PM
	Please respond to "joseph m"
		 
		 To: Omkhar Arasaratnam/Toronto/IBM@IBMCA
		 cc: 
		 Subject: RE: Issue with iANS-2.3.35 and RedHat's 2.4.20-13.7
		


Omkhar:

There seems to be an issue with the kernel source you have. Please contact
RedHat for assistance in getting properly configured kernel source.

Regards,

============================
Joe M.
Intel(R) Customer Support
*All other brands & names are the property of their respective owners.

->After installing RedHat's latest eratta kernel for RH7.3, I get the 
->following error when I try and build iANS-2.3.35:
->
->  Compiling ians_base.c ...
->  Compiling ians_kernel.c ...
->  Compiling lib/incg_dev.c ...
->  Compiling lib/incg_gp_mem.c ...
->  Compiling lib/incg_kthread.c ...
->In file included from lib/incg_kthread.c:366:
->/lib/modules/2.4.20-13.7/build/include/asm/smplock.h:47:40: macro 
->"lock_kernel" passed 1 arguments, but takes just 0
->/lib/modules/2.4.20-13.7/build/include/asm/smplock.h:63:42: macro 
->"unlock_kernel" passed 1 arguments, but takes just 0
->In file included from lib/incg_kthread.c:366:
->/lib/modules/2.4.20-13.7/build/include/asm/smplock.h:48: syntax error 
->before `{'
->/lib/modules/2.4.20-13.7/build/include/asm/smplock.h:64: syntax error 
->before `{'
->make: *** [lib/incg_kthread.o] Error 1
->
->Can you please recommend how to resolve this issue?
->-------------------------------------------------------------------------------------
->Omkhar Arasaratnam RHCE, MCP
->IT Specialist - Distributed Server Services East
->255 Consumers Rd, 2nd Floor, Office 344
->Toronto, Ontario, M2J 1S2
->external voice: 416.490.3920 / pager: 416.440.5057 / fax: 416.490.2335
->email: omkhar.com
->e-pager: http://www.rogers.com/english/wireless/sendpage.html - (pin 
->4164405057)
->
->"Be liberal in what you accept, and conservative in what you send" --jon 
->RFC1122 (RFC760)


</snip>

iANS is a binary only kernel module that probably will need modifications.
Since it's a binary only module Red Hat can't touch it, not even the glue layer,
for risk of IP contamination. Intel is more than free to open source iANS and at
that point I'll have a look.

*** This bug has been marked as a duplicate of 78616 ***

Created attachment 91858 [details]
iANS-2.3.35 Source Tarball

The source is available, and is attached. Perhaps this was an issue with
previous versions, however full source is available here.


Please review

It seems to disctinctly lack the source for the following file:
-r--r--r--    1 arjan    arjan      126281 Feb 27 11:56 ians_core.o
while the rest is just glue layer.

Doh!

I see the issue. I will speak with Intel regarding this.

As an update, recieved the following email from Intel regarding this issue:

Hello:

I have passed this info back to the engineers here.

I understand RedHat's IP concern. However, there is no risk in them working
with the glue code since it is GPL.

Are the machines you are working with UP or SMP?

Regards,

============================
Joe M.
Intel(R) Customer Support
*All other brands & names are the property of their respective owners.

"I understand RedHat's IP concern. However, there is no risk in them working
with the glue code since it is GPL."

That code cannot be GPL unless Intel doesn't mind shipping blatant license
violations themselves. I sure hope IBM has let their legal folks check this out
before distributing this to customers.

I've deleted the attachement from this bug and all materials from it from my PC
given the highly unclear and dangerous license situation of it.

Recieved the following response from Intel

*****
Hi,

We have escalated this issue to development. They looked at the -13.8 update 
and did not see the issue there. The test lab will be getting the .13.7 today 
to see if we can see the issue. 

Their initial guess (and only a guess) was that it could be an include order 
problem in the kernel itself in the kernel smplock.h file that results from 
changes that Red Hat introduced into the kernel.  They also believe  it is 
related to the compilation of the open part of iANS since the binary part is 
not kernel dependent.  You could see if you can get the smplock changes from 
Red Hat for us to work with. 

We cannot get any more information before Monday due to the different schedules 
around the world. 


Colleen Culbertson
MCSE, CNE, CCNA
Sr. Product Support Engineer - wired, non mobile adapters
Intel Corporation Retail Customer Support

******

My questions are as follows:

1. Was there ever a 2.4.20-13.8 for RH 7.3 ? All I can find is -13.7.
2. What were the differences in smplock.h between -13.7 and (the alleged) -13.8?

As for the Intellectual Property issue, our legal team as stated we are OK to 
use this code as we are not "rebranding" it. We are merely using the driver on 
a server which we are providing support for. I have raised this issue with the 
Intel legal team however, as this does seem to be a GPL concern.

-13.7 and -13.8 are identical except for the compiler used.
This thing is in intel's hands; we don't provide support for binary only kernel
modules.

Agreed, this is Intels issue. Thanks for the information regarding the version 
differences. I will communicate this to Intel. If this works with .8 perhaps 
gcc is expanding macros differently to how they would expect.

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.