Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code

[Jeff Webb <jeff.webb@nta-inc.net>]

On 12/10/2014 03:23 PM, Lennart Sorensen wrote:
> On Wed, Dec 10, 2014 at 03:11:40PM -0500, Lennart Sorensen wrote:
>> On Wed, Dec 10, 2014 at 09:13:57PM +0100, Philippe Gerum wrote:
>>> The I-pipe interface was moved to GPL_ONLY to clearly state that such
>>> code intimately depends on the kernel innards, has to know about them to
>>> function, and therefore any client code has to be GPL-compatible to
>>> comply with the kernel license.
>>
>> Well I think most of the interfaces were already GPL only even in 2.6.36
>> from what I can tell, so nothing new there.
>>
>>> The only question that matters is: does __ipipe_root_status belong to
>>> the visible I-pipe API exposed to clients? The answer from the copyright
>>> holder of this particular code is "no".
>>
>> Oh good, because I was having trouble seeing how it was part of the
>> ipipe interface.
>>
>>> Ah, maybe it was a mistake then, something that was overlooked, just
>>> because I-pipe maintainers don't routinely have to rebuild non-GPL
>>> software on top the I-pipe? Yes, most likely it was.
>>
>> I would not expect that to be a normal procedure.  Would be a pain to do.
>>
>>> Could the code be changed to fix this, then? Yes, it sounds reasonable,
>>> and would not change the original intent of moving the API symbols to
>>> GPL_ONLY.
>>>
>>> The issue is non-ambiguous, the solution is straightforward. Let's
>>> relax, there is work ahead.
>>
>> Should I do a test build with it changed to at least confirm if that is
>> the only issue?
>
> So a test build with just this:
>
> --- linux-3.12.33.rr1.orig/kernel/ipipe/core.c  2014-12-10 15:16:41.045125486 -0500
> +++ linux-3.12.33.rr1/kernel/ipipe/core.c       2014-12-10 15:16:43.189141150 -0500
> @@ -93,7 +93,7 @@
>    */
>   extern unsigned long __ipipe_root_status
>   __attribute__((alias(__stringify(ipipe_percpu))));
> -EXPORT_SYMBOL_GPL(__ipipe_root_status);
> +EXPORT_SYMBOL(__ipipe_root_status);
>
>   #endif /* !CONFIG_SMP */
>
> in fact makes the module compile again.
>
> So changing the one symbol back to what it was pre 3.2 would certainly
> help a lot.
>

I can confirm that this is around the time I started having trouble with the proprietary nvidia module.  In the linux 2.6.?? days, I didn't experience that issue.  It is obviously up to the authors to decide whether or not it is desirable to allow proprietary modules to continue to operate on an I-pipe patched kernel as they do an un-patched kernel.  Since the issue was raised, I thought I would report my experience in case there is a desire to get this configuration working again.

-Jeff