calling oem sal functions

calling oem sal functions

[Tony Luck]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

Dean,

I've been thinking about this, and it does seem unresonable that there
is no way for an OEM written module to make a call to an OEM SAL function.

Would something like the (compiles, but untested) attached patch work
for you?  The return value of 0/-1 just indicates whether the SAL call
was attempted.  Callers should look at the status field of the isrvp
structure to determine the actual success of the call.

Would you also need "_nolock" and "_reentrant" versions?

-Tony

[-- Attachment #2: oemsal.patch --]
[-- Type: text/plain, Size: 711 bytes --]

===== arch/ia64/kernel/sal.c 1.11 vs edited =====
--- 1.11/arch/ia64/kernel/sal.c	2004-07-09 00:11:46 +00:00
+++ edited/arch/ia64/kernel/sal.c	2004-08-19 17:02:07 +00:00
@@ -10,6 +10,7 @@
 
 #include <linux/kernel.h>
 #include <linux/init.h>
+#include <linux/module.h>
 #include <linux/spinlock.h>
 #include <linux/string.h>
 
@@ -262,3 +263,15 @@
 		p += SAL_DESC_SIZE(*p);
 	}
 }
+
+int
+oem_sal_call(struct ia64_sal_retval *isrvp, u64 oemfunc, u64 arg1, u64 arg2,
+	     u64 arg3, u64 arg4, u64 arg5, u64 arg6, u64 arg7)
+{
+	if (oemfunc < 0x02000000 || oemfunc > 0x03ffffff)
+		return -1;
+	SAL_CALL(*isrvp, oemfunc, arg1, arg2, arg3, arg4, arg5, arg6, arg7);
+	return 0;
+}
+
+EXPORT_SYMBOL(oem_sal_call);

Re: calling oem sal functions

[Christoph Hellwig]

On Thu, Aug 19, 2004 at 05:23:46PM +0000, Tony Luck wrote:
> Dean,
> 
> I've been thinking about this, and it does seem unresonable that there
> is no way for an OEM written module to make a call to an OEM SAL function.
> 
> Would something like the (compiles, but untested) attached patch work
> for you?  The return value of 0/-1 just indicates whether the SAL call
> was attempted.  Callers should look at the status field of the isrvp
> structure to determine the actual success of the call.
> 
> Would you also need "_nolock" and "_reentrant" versions?

Please make the exports _GPL so we have the callers under rcontrol.

Re: calling oem sal functions

[Robin Holt]

On Thu, Aug 19, 2004 at 06:29:04PM +0100, Christoph Hellwig wrote:
> On Thu, Aug 19, 2004 at 05:23:46PM +0000, Tony Luck wrote:
> > Dean,
> > 
> > I've been thinking about this, and it does seem unresonable that there
> > is no way for an OEM written module to make a call to an OEM SAL function.
> > 
> > Would something like the (compiles, but untested) attached patch work
> > for you?  The return value of 0/-1 just indicates whether the SAL call
> > was attempted.  Callers should look at the status field of the isrvp
> > structure to determine the actual success of the call.
> > 
> > Would you also need "_nolock" and "_reentrant" versions?
> 
> Please make the exports _GPL so we have the callers under rcontrol.

If you make them GPL, it makes the call useless to SGI.  Some of our
tests suites have the problem description we are testing for and the
resolution.  This may include vendor specific or customer specific
data which is not disclosable.  Some of the vendor specific tests are
likewise covered by NDA.  I understand you would love to have
everything _GPL, but that is unreasonable.

All that is being provided here is a gateway to SAL.  How much value
is the kernel community adding.

Tony, please carefully consider the _GPL.

Thanks,
Robin Holt

Re: calling oem sal functions

[Christoph Hellwig]

On Thu, Aug 19, 2004 at 01:18:03PM -0500, Robin Holt wrote:
> If you make them GPL, it makes the call useless to SGI.  Some of our
> tests suites have the problem description we are testing for and the
> resolution.  This may include vendor specific or customer specific
> data which is not disclosable.  Some of the vendor specific tests are
> likewise covered by NDA.  I understand you would love to have
> everything _GPL, but that is unreasonable.

Huh?  As long as you use your testsuite only internally the GPL doesn't
matter.  It only kicks in as soon as you distribute something.

> Tony, please carefully consider the _GPL.

This is talking directly to the SAL layer, something that should
be reserved to OS internals.

Re: calling oem sal functions

[Dean Nelson]

On Thu, Aug 19, 2004 at 05:23:46PM +0000, Tony Luck wrote:
> Dean,
> 
> I've been thinking about this, and it does seem unresonable that there
> is no way for an OEM written module to make a call to an OEM SAL function.
> 
> Would something like the (compiles, but untested) attached patch work
> for you?  The return value of 0/-1 just indicates whether the SAL call
> was attempted.  Callers should look at the status field of the isrvp
> structure to determine the actual success of the call.
> 
> Would you also need "_nolock" and "_reentrant" versions?

Yes, it would certainly do the trick. And yes, we would need all
three versions.

Did you want me to finish developing this patch and submit it with my stuff,
or were you planning on taking it to completion?

Thanks,
Dean

Re: calling oem sal functions

[Jack Steiner]

On Thu, Aug 19, 2004 at 06:29:04PM +0100, Christoph Hellwig wrote:
> On Thu, Aug 19, 2004 at 05:23:46PM +0000, Tony Luck wrote:
> > Dean,
> > 
> > I've been thinking about this, and it does seem unresonable that there
> > is no way for an OEM written module to make a call to an OEM SAL function.
> > 
> > Would something like the (compiles, but untested) attached patch work
> > for you?  The return value of 0/-1 just indicates whether the SAL call
> > was attempted.  Callers should look at the status field of the isrvp
> > structure to determine the actual success of the call.
> > 
> > Would you also need "_nolock" and "_reentrant" versions?
> 
> Please make the exports _GPL so we have the callers under rcontrol.

SGI uses OEM_SAL calls in some of it's online diagnostics. These diagnostics
are run on production systems, both in the factory and at customer sites.
If the SAL call interface is marked _GPL, then these diagnostics cant
be run on standard kernels. 

Since the OEM_SAL call interface restricts SAL calls to the OEM range
of function codes, I dont understand why these calls should be GPL'ed.



-- 
Thanks

Jack Steiner (steiner@sgi.com)          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.

Re: calling oem sal functions

[Robin Holt]

On Thu, Aug 19, 2004 at 07:21:02PM +0100, Christoph Hellwig wrote:
> On Thu, Aug 19, 2004 at 01:18:03PM -0500, Robin Holt wrote:
> > If you make them GPL, it makes the call useless to SGI.  Some of our
> > tests suites have the problem description we are testing for and the
> > resolution.  This may include vendor specific or customer specific
> > data which is not disclosable.  Some of the vendor specific tests are
> > likewise covered by NDA.  I understand you would love to have
> > everything _GPL, but that is unreasonable.
> 
> Huh?  As long as you use your testsuite only internally the GPL doesn't
> matter.  It only kicks in as soon as you distribute something.

The test suites are part of our online diagnostics.  We normally have the
field support or customer run the diagnostics to identify the source
of the problem.

> 
> > Tony, please carefully consider the _GPL.
> 
> This is talking directly to the SAL layer, something that should
> be reserved to OS internals.

IIRC, the SAL calls that diags make do stuff like change hardware error
timeout settings, hardware request queue sizes, voltage thresholds,
and retry limits so that even slightly marginal hardware becomes extermely
likely to fail.

Userland then uses normal kernel mechanism to excercise the portion
under test (eg: ping-pong a cacheline between two nodes) to attempt to
force an error.

All the error indications we are looking for use the normal kernel
paths.  We are just setting the hardware up for the maximum probability
for failure.

Again Tony, please consider carefully the effect of putting _GPL on
these exports.

Thanks,
Robin

RE: calling oem sal functions

[John Lee]

> -----Original Message-----
> From: linux-ia64-owner@vger.kernel.org 
> [mailto:linux-ia64-owner@vger.kernel.org] On Behalf Of Robin Holt
...
> 
> On Thu, Aug 19, 2004 at 06:29:04PM +0100, Christoph Hellwig wrote:
> > On Thu, Aug 19, 2004 at 05:23:46PM +0000, Tony Luck wrote:
....
> > > 
> > > Would you also need "_nolock" and "_reentrant" versions?

Yes, that would be perfect.

> > 
> > Please make the exports _GPL so we have the callers under rcontrol.
> 
> If you make them GPL, it makes the call useless to SGI.  Some of our
> tests suites have the problem description we are testing for and the
> resolution.  This may include vendor specific or customer specific
> data which is not disclosable.  Some of the vendor specific tests are
> likewise covered by NDA.  I understand you would love to have
> everything _GPL, but that is unreasonable.
> 
> All that is being provided here is a gateway to SAL.  How much value
> is the kernel community adding.
> 
> Tony, please carefully consider the _GPL.
> 

I have to second to this.

John
Platform Solutions