* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-10 20:13 ` Philippe Gerum
@ 2014-12-10 20:11 ` Lennart Sorensen
2014-12-10 20:38 ` Philippe Gerum
2014-12-10 21:23 ` Lennart Sorensen
2014-12-10 20:53 ` Jeff Webb
2014-12-22 10:06 ` Jan Kiszka
2 siblings, 2 replies; 39+ messages in thread
From: Lennart Sorensen @ 2014-12-10 20:11 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
On Wed, Dec 10, 2014 at 09:13:57PM +0100, Philippe Gerum wrote:
> The point is about being able to discuss issues without starting useless
> rants or flame wars.
I was not trying to. I think I was getting frustrated chasing around
git trees wondering why I could not figure out where the change came from.
> 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?
I tried comparing a 3.1 versino of core.c to a 3.5 version and they are
certainly changed a lot. For the symbol here It went from:
/*
* Create an alias to the unique root status, so that arch-dep code
* may get simple and easy access to this percpu variable. We also
* create an array of pointers to the percpu domain data; this tends
* to produce a better code when reaching non-root domains. We make
* sure that the early boot code would be able to dereference the
* pointer to the root domain data safely by statically initializing
* its value (local_irq*() routines depend on this).
*/
#if __GNUC__ >= 4
extern unsigned long __ipipe_root_status
__attribute__((alias(__stringify(ipipe_percpu_darray))));
EXPORT_SYMBOL(__ipipe_root_status);
#else /* __GNUC__ < 4 */
/*
* Work around a GCC 3.x issue making alias symbols unusable as
* constant initializers.
*/
unsigned long *const __ipipe_root_status_addr =
&__raw_get_cpu_var(ipipe_percpu_darray)[IPIPE_ROOT_SLOT].status;
EXPORT_SYMBOL(__ipipe_root_status_addr);
#endif /* __GNUC__ < 4 */
and become:
/*
* Create an alias to the unique root status, so that arch-dep code
* may get fast access to this percpu variable including from
* assembly. A hard-coded assumption is that root.status appears at
* offset #0 of the ipipe_percpu struct.
*/
extern unsigned long __ipipe_root_status
__attribute__((alias(__stringify(ipipe_percpu))));
EXPORT_SYMBOL_GPL(__ipipe_root_status);
So certainly cleaner after getting rid of support for old GCC versions
and such.
--
Len Sorensen
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-10 20:11 ` Lennart Sorensen
@ 2014-12-10 20:38 ` Philippe Gerum
2014-12-10 21:16 ` Lennart Sorensen
2014-12-10 21:23 ` Lennart Sorensen
1 sibling, 1 reply; 39+ messages in thread
From: Philippe Gerum @ 2014-12-10 20:38 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: xenomai
On 12/10/2014 09:11 PM, Lennart Sorensen wrote:
> On Wed, Dec 10, 2014 at 09:13:57PM +0100, Philippe Gerum wrote:
>> The point is about being able to discuss issues without starting useless
>> rants or flame wars.
>
> I was not trying to. I think I was getting frustrated chasing around
> git trees wondering why I could not figure out where the change came from.
>
>> 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.
>
GPL_ONLY is a clear statement that if somebody converts this to plain
EXPORT_SYMBOL() in the code in order to link whatever non-GPL module, he
is definitely and willingly violating the kernel license. This does make
a difference.
--
Philippe.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-10 20:38 ` Philippe Gerum
@ 2014-12-10 21:16 ` Lennart Sorensen
0 siblings, 0 replies; 39+ messages in thread
From: Lennart Sorensen @ 2014-12-10 21:16 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
On Wed, Dec 10, 2014 at 09:38:18PM +0100, Philippe Gerum wrote:
> GPL_ONLY is a clear statement that if somebody converts this to plain
> EXPORT_SYMBOL() in the code in order to link whatever non-GPL module, he
> is definitely and willingly violating the kernel license. This does make
> a difference.
Well given that the code isn't asking for ipipe features and is only
hitting this symbol because it is everywhere in the kernel once you
enable ipipe, then it seems excessive.
And as I found, in older ipipe versions that had most functions defined
as EXPORT_SYMBOL_GPL, this status flag was EXPORT_SYMBOL.
--
Len Sorensen
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-10 20:11 ` Lennart Sorensen
2014-12-10 20:38 ` Philippe Gerum
@ 2014-12-10 21:23 ` Lennart Sorensen
2014-12-10 21:55 ` Jeff Webb
1 sibling, 1 reply; 39+ messages in thread
From: Lennart Sorensen @ 2014-12-10 21:23 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
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 point is about being able to discuss issues without starting useless
> > rants or flame wars.
>
> I was not trying to. I think I was getting frustrated chasing around
> git trees wondering why I could not figure out where the change came from.
>
> > 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.
--
Len Sorensen
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-10 21:23 ` Lennart Sorensen
@ 2014-12-10 21:55 ` Jeff Webb
2014-12-10 22:01 ` Lennart Sorensen
0 siblings, 1 reply; 39+ messages in thread
From: Jeff Webb @ 2014-12-10 21:55 UTC (permalink / raw)
To: xenomai
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-10 21:55 ` Jeff Webb
@ 2014-12-10 22:01 ` Lennart Sorensen
2014-12-10 23:18 ` Jeff Webb
0 siblings, 1 reply; 39+ messages in thread
From: Lennart Sorensen @ 2014-12-10 22:01 UTC (permalink / raw)
To: Jeff Webb; +Cc: xenomai
On Wed, Dec 10, 2014 at 03:55:21PM -0600, Jeff Webb wrote:
> 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.
Well certainly I do agree with Gilles that if there is a binary blob,
you can not know if it is going to mess directly with interrupts and
break ipipe, so the nvidia driver could be a problem (hard to know).
Of course if you have source code and are compiling the module yourself
then that part should not be a problem. I wonder if a BSD licenced
module would even compile with an ipipe enabled kernel
right now assuming any such thing exists (other than
./Documentation/blackfin/gptimers-example.c:MODULE_LICENSE("BSD");
that I spotted).
--
Len Sorensen
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-10 22:01 ` Lennart Sorensen
@ 2014-12-10 23:18 ` Jeff Webb
0 siblings, 0 replies; 39+ messages in thread
From: Jeff Webb @ 2014-12-10 23:18 UTC (permalink / raw)
To: xenomai
On 12/10/2014 04:01 PM, Lennart Sorensen wrote:
> On Wed, Dec 10, 2014 at 03:55:21PM -0600, Jeff Webb wrote:
>> 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.
>
> Well certainly I do agree with Gilles that if there is a binary blob,
> you can not know if it is going to mess directly with interrupts and
> break ipipe, so the nvidia driver could be a problem (hard to know).
Yes, this is true. Just to be clear, though, I have used Xenomai with the nvidia module loaded, and it does work well enough to be useful for some applications on some hardware. I would not recommend this configuration for a critical application, but it may be useful to some people for development and testing. The open-source nouveau driver is much better behaved, but some video cards don't work well with nouveau.
-Jeff
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-10 20:13 ` Philippe Gerum
2014-12-10 20:11 ` Lennart Sorensen
@ 2014-12-10 20:53 ` Jeff Webb
2014-12-10 21:58 ` Gilles Chanteperdrix
2014-12-22 10:06 ` Jan Kiszka
2 siblings, 1 reply; 39+ messages in thread
From: Jeff Webb @ 2014-12-10 20:53 UTC (permalink / raw)
To: xenomai
On 12/10/2014 02:13 PM, Philippe Gerum wrote:
> On 12/10/2014 08:44 PM, Lennart Sorensen wrote:
>> On Wed, Dec 10, 2014 at 08:45:01PM +0100, Philippe Gerum wrote:
>>> On 12/10/2014 08:19 PM, Lennart Sorensen wrote:
>>>> On Wed, Dec 10, 2014 at 08:13:50PM +0100, Gilles Chanteperdrix wrote:
>>>>> This is true in user space. Not for kernel modules, see:
>>>>> https://git.xenomai.org/ipipe.git/tree/Documentation/stable_api_nonsense.txt?h=ipipe-3.14
>>>>
>>>> I can't even figure out how to track down which call is making it
>>>> reference that symbol (for which it has zero interest of course).
>>>>
>>>> I suppose if whoever made the change in ipipe (which unfortunately the
>>>> ipipe git tree does not make easy to track down since it isn't like it
>>>> is one git tree moving from version to version) does not see the point
>>>> in reverting the change, then I will just have to keep a patch around to
>>>> do it instead and ignore the advisory on the symbol to get this to work.
>>>> I really don't want to do that, but stupid changes sometimes need stupid
>>>> fixes.
>>>>
>>>> This code does NOT use any xenomai or ipipe features. Other code does.
>>>> ipipe should not be breaking it.
>>>>
>>>
>>> The stupid guy is me, as the main copyright holder on most of the code
>>> you have been using with Xenomai so far. So where do we go from here?
>>
>> No one said the guy was stupid. Just the change.
>>
>> As far as I can tell, __ipipe_root_status is a number containing some
>> status. It is not a function, it doesn't do anything by itself, so why
>> did it need to be changed to GPL only if that causes the entire kernel
>> to become GPL only (from what I have been able to tell so far)?
>>
>> I certainly think having the ipipe functions limited to GPL only seems
>> perfectly reasonable. It is new functionality the kernel didn't have
>> before. I don't think it should make existing kernel functions suddenly
>> be GPL only though.
>>
>> I will do a test build with the symbol changed back to see if that is
>> in fact the only thing causing issues for the external module.
>>
>
> The point is about being able to discuss issues without starting useless
> rants or flame wars.
>
> 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.
>
> 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".
>
> 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.
>
> 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.
>
I had a similar issue in the past getting an I-pipe patched kernel to work with the proprietary nvidia driver module. I added the following lines to my build script to get things working on Ubuntu 12.04 (x86-64) with a 3.5.7 kernel:
if [ ${FIX_SYMBOL_EXPORT} = 1 ]; then
sed -i 's/EXPORT_PER_CPU_SYMBOL_GPL(ipipe_percpu);/EXPORT_PER_CPU_SYMBOL(ipipe_percpu);/' kernel/ipipe/core.c
sed -i 's/EXPORT_SYMBOL_GPL(ipipe_restore_root);/EXPORT_SYMBOL(ipipe_restore_root);/' kernel/ipipe/core.c
sed -i 's/EXPORT_SYMBOL_GPL(ipipe_root_only);/EXPORT_SYMBOL(ipipe_root_only);/' kernel/ipipe/core.c
sed -i 's/EXPORT_SYMBOL_GPL(__ipipe_spin_unlock_debug);/EXPORT_SYMBOL(__ipipe_spin_unlock_debug);/' kernel/ipipe/core.c
fi
As one would expect, worst-case latencies with the nvidia module loaded are terrible, but this capability can be useful from a code development standpoint on machines that don't work well with the free software nouveau driver.
-Jeff
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-10 20:53 ` Jeff Webb
@ 2014-12-10 21:58 ` Gilles Chanteperdrix
0 siblings, 0 replies; 39+ messages in thread
From: Gilles Chanteperdrix @ 2014-12-10 21:58 UTC (permalink / raw)
To: Jeff Webb; +Cc: xenomai
On Wed, Dec 10, 2014 at 02:53:51PM -0600, Jeff Webb wrote:
> On 12/10/2014 02:13 PM, Philippe Gerum wrote:
> >On 12/10/2014 08:44 PM, Lennart Sorensen wrote:
> >>On Wed, Dec 10, 2014 at 08:45:01PM +0100, Philippe Gerum wrote:
> >>>On 12/10/2014 08:19 PM, Lennart Sorensen wrote:
> >>>>On Wed, Dec 10, 2014 at 08:13:50PM +0100, Gilles Chanteperdrix wrote:
> >>>>>This is true in user space. Not for kernel modules, see:
> >>>>>https://git.xenomai.org/ipipe.git/tree/Documentation/stable_api_nonsense.txt?h=ipipe-3.14
> >>>>
> >>>>I can't even figure out how to track down which call is making it
> >>>>reference that symbol (for which it has zero interest of course).
> >>>>
> >>>>I suppose if whoever made the change in ipipe (which unfortunately the
> >>>>ipipe git tree does not make easy to track down since it isn't like it
> >>>>is one git tree moving from version to version) does not see the point
> >>>>in reverting the change, then I will just have to keep a patch around to
> >>>>do it instead and ignore the advisory on the symbol to get this to work.
> >>>>I really don't want to do that, but stupid changes sometimes need stupid
> >>>>fixes.
> >>>>
> >>>>This code does NOT use any xenomai or ipipe features. Other code does.
> >>>>ipipe should not be breaking it.
> >>>>
> >>>
> >>>The stupid guy is me, as the main copyright holder on most of the code
> >>>you have been using with Xenomai so far. So where do we go from here?
> >>
> >>No one said the guy was stupid. Just the change.
> >>
> >>As far as I can tell, __ipipe_root_status is a number containing some
> >>status. It is not a function, it doesn't do anything by itself, so why
> >>did it need to be changed to GPL only if that causes the entire kernel
> >>to become GPL only (from what I have been able to tell so far)?
> >>
> >>I certainly think having the ipipe functions limited to GPL only seems
> >>perfectly reasonable. It is new functionality the kernel didn't have
> >>before. I don't think it should make existing kernel functions suddenly
> >>be GPL only though.
> >>
> >>I will do a test build with the symbol changed back to see if that is
> >>in fact the only thing causing issues for the external module.
> >>
> >
> >The point is about being able to discuss issues without starting useless
> >rants or flame wars.
> >
> >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.
> >
> >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".
> >
> >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.
> >
> >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.
> >
>
> I had a similar issue in the past getting an I-pipe patched kernel to work with the proprietary nvidia driver module. I added the following lines to my build script to get things working on Ubuntu 12.04 (x86-64) with a 3.5.7 kernel:
>
> if [ ${FIX_SYMBOL_EXPORT} = 1 ]; then
> sed -i 's/EXPORT_PER_CPU_SYMBOL_GPL(ipipe_percpu);/EXPORT_PER_CPU_SYMBOL(ipipe_percpu);/' kernel/ipipe/core.c
> sed -i 's/EXPORT_SYMBOL_GPL(ipipe_restore_root);/EXPORT_SYMBOL(ipipe_restore_root);/' kernel/ipipe/core.c
> sed -i 's/EXPORT_SYMBOL_GPL(ipipe_root_only);/EXPORT_SYMBOL(ipipe_root_only);/' kernel/ipipe/core.c
> sed -i 's/EXPORT_SYMBOL_GPL(__ipipe_spin_unlock_debug);/EXPORT_SYMBOL(__ipipe_spin_unlock_debug);/' kernel/ipipe/core.c
> fi
>
> As one would expect, worst-case latencies with the nvidia module loaded are terrible, but this capability can be useful from a code development standpoint on machines that don't work well with the free software nouveau driver.
Well, at some point, we had some performances issues due to the
intel drivers creating large latencies, so, this may not be related
to the binary blob, but simply of some other hardware related
issues.
--
Gilles.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-10 20:13 ` Philippe Gerum
2014-12-10 20:11 ` Lennart Sorensen
2014-12-10 20:53 ` Jeff Webb
@ 2014-12-22 10:06 ` Jan Kiszka
2014-12-22 11:19 ` Philippe Gerum
2014-12-22 14:42 ` Lennart Sorensen
2 siblings, 2 replies; 39+ messages in thread
From: Jan Kiszka @ 2014-12-22 10:06 UTC (permalink / raw)
To: Philippe Gerum, Lennart Sorensen; +Cc: xenomai
On 2014-12-10 21:13, Philippe Gerum wrote:
> On 12/10/2014 08:44 PM, Lennart Sorensen wrote:
>> On Wed, Dec 10, 2014 at 08:45:01PM +0100, Philippe Gerum wrote:
>>> On 12/10/2014 08:19 PM, Lennart Sorensen wrote:
>>>> On Wed, Dec 10, 2014 at 08:13:50PM +0100, Gilles Chanteperdrix wrote:
>>>>> This is true in user space. Not for kernel modules, see:
>>>>> https://git.xenomai.org/ipipe.git/tree/Documentation/stable_api_nonsense.txt?h=ipipe-3.14
>>>>
>>>> I can't even figure out how to track down which call is making it
>>>> reference that symbol (for which it has zero interest of course).
>>>>
>>>> I suppose if whoever made the change in ipipe (which unfortunately the
>>>> ipipe git tree does not make easy to track down since it isn't like it
>>>> is one git tree moving from version to version) does not see the point
>>>> in reverting the change, then I will just have to keep a patch around to
>>>> do it instead and ignore the advisory on the symbol to get this to work.
>>>> I really don't want to do that, but stupid changes sometimes need stupid
>>>> fixes.
>>>>
>>>> This code does NOT use any xenomai or ipipe features. Other code does.
>>>> ipipe should not be breaking it.
>>>>
>>>
>>> The stupid guy is me, as the main copyright holder on most of the code
>>> you have been using with Xenomai so far. So where do we go from here?
>>
>> No one said the guy was stupid. Just the change.
>>
>> As far as I can tell, __ipipe_root_status is a number containing some
>> status. It is not a function, it doesn't do anything by itself, so why
>> did it need to be changed to GPL only if that causes the entire kernel
>> to become GPL only (from what I have been able to tell so far)?
>>
>> I certainly think having the ipipe functions limited to GPL only seems
>> perfectly reasonable. It is new functionality the kernel didn't have
>> before. I don't think it should make existing kernel functions suddenly
>> be GPL only though.
>>
>> I will do a test build with the symbol changed back to see if that is
>> in fact the only thing causing issues for the external module.
>>
>
> The point is about being able to discuss issues without starting useless
> rants or flame wars.
>
> 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.
>
> 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".
>
> 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.
>
> 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.
>
Lennart, are you on x86 and do you have CONFIG_CMP disabled? Then
__ipipe_root_status gets pulled in via arch_local_irq_disable ->
ipipe_stall_root. If that is the problem, I think it's more than
reasonable to argue that effectively making local_irq_disable GPL-only
would be an unwanted restriction over mainline.
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20141222/217506f7/attachment.sig>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-22 10:06 ` Jan Kiszka
@ 2014-12-22 11:19 ` Philippe Gerum
2014-12-22 14:46 ` Lennart Sorensen
2014-12-22 14:42 ` Lennart Sorensen
1 sibling, 1 reply; 39+ messages in thread
From: Philippe Gerum @ 2014-12-22 11:19 UTC (permalink / raw)
To: Jan Kiszka, Lennart Sorensen; +Cc: xenomai
On 12/22/2014 11:06 AM, Jan Kiszka wrote:
> On 2014-12-10 21:13, Philippe Gerum wrote:
>> On 12/10/2014 08:44 PM, Lennart Sorensen wrote:
>>> On Wed, Dec 10, 2014 at 08:45:01PM +0100, Philippe Gerum wrote:
>>>> On 12/10/2014 08:19 PM, Lennart Sorensen wrote:
>>>>> On Wed, Dec 10, 2014 at 08:13:50PM +0100, Gilles Chanteperdrix wrote:
>>>>>> This is true in user space. Not for kernel modules, see:
>>>>>> https://git.xenomai.org/ipipe.git/tree/Documentation/stable_api_nonsense.txt?h=ipipe-3.14
>>>>>
>>>>> I can't even figure out how to track down which call is making it
>>>>> reference that symbol (for which it has zero interest of course).
>>>>>
>>>>> I suppose if whoever made the change in ipipe (which unfortunately the
>>>>> ipipe git tree does not make easy to track down since it isn't like it
>>>>> is one git tree moving from version to version) does not see the point
>>>>> in reverting the change, then I will just have to keep a patch around to
>>>>> do it instead and ignore the advisory on the symbol to get this to work.
>>>>> I really don't want to do that, but stupid changes sometimes need stupid
>>>>> fixes.
>>>>>
>>>>> This code does NOT use any xenomai or ipipe features. Other code does.
>>>>> ipipe should not be breaking it.
>>>>>
>>>>
>>>> The stupid guy is me, as the main copyright holder on most of the code
>>>> you have been using with Xenomai so far. So where do we go from here?
>>>
>>> No one said the guy was stupid. Just the change.
>>>
>>> As far as I can tell, __ipipe_root_status is a number containing some
>>> status. It is not a function, it doesn't do anything by itself, so why
>>> did it need to be changed to GPL only if that causes the entire kernel
>>> to become GPL only (from what I have been able to tell so far)?
>>>
>>> I certainly think having the ipipe functions limited to GPL only seems
>>> perfectly reasonable. It is new functionality the kernel didn't have
>>> before. I don't think it should make existing kernel functions suddenly
>>> be GPL only though.
>>>
>>> I will do a test build with the symbol changed back to see if that is
>>> in fact the only thing causing issues for the external module.
>>>
>>
>> The point is about being able to discuss issues without starting useless
>> rants or flame wars.
>>
>> 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.
>>
>> 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".
>>
>> 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.
>>
>> 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.
>>
>
> Lennart, are you on x86 and do you have CONFIG_CMP disabled? Then
> __ipipe_root_status gets pulled in via arch_local_irq_disable ->
> ipipe_stall_root. If that is the problem, I think it's more than
> reasonable to argue that effectively making local_irq_disable GPL-only
> would be an unwanted restriction over mainline.
>
This has been agreed upon.
--
Philippe.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-22 11:19 ` Philippe Gerum
@ 2014-12-22 14:46 ` Lennart Sorensen
2014-12-22 15:00 ` Philippe Gerum
0 siblings, 1 reply; 39+ messages in thread
From: Lennart Sorensen @ 2014-12-22 14:46 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Jan Kiszka, xenomai
On Mon, Dec 22, 2014 at 12:19:15PM +0100, Philippe Gerum wrote:
> On 12/22/2014 11:06 AM, Jan Kiszka wrote:
> > Lennart, are you on x86 and do you have CONFIG_CMP disabled? Then
> > __ipipe_root_status gets pulled in via arch_local_irq_disable ->
> > ipipe_stall_root. If that is the problem, I think it's more than
> > reasonable to argue that effectively making local_irq_disable GPL-only
> > would be an unwanted restriction over mainline.
> >
>
> This has been agreed upon.
Will the change go in git sometime so I can pull it from there. I could
change it locally (and did to test it), but would much rather pull the
code cange from the git tree.
--
Len Sorensen
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-22 14:46 ` Lennart Sorensen
@ 2014-12-22 15:00 ` Philippe Gerum
2014-12-22 19:08 ` Lennart Sorensen
0 siblings, 1 reply; 39+ messages in thread
From: Philippe Gerum @ 2014-12-22 15:00 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: Jan Kiszka, xenomai
On 12/22/2014 03:46 PM, Lennart Sorensen wrote:
> On Mon, Dec 22, 2014 at 12:19:15PM +0100, Philippe Gerum wrote:
>> On 12/22/2014 11:06 AM, Jan Kiszka wrote:
>>> Lennart, are you on x86 and do you have CONFIG_CMP disabled? Then
>>> __ipipe_root_status gets pulled in via arch_local_irq_disable ->
>>> ipipe_stall_root. If that is the problem, I think it's more than
>>> reasonable to argue that effectively making local_irq_disable GPL-only
>>> would be an unwanted restriction over mainline.
>>>
>>
>> This has been agreed upon.
>
> Will the change go in git sometime so I can pull it from there. I could
> change it locally (and did to test it), but would much rather pull the
> code cange from the git tree.
>
I'll push the change to the git tree.
--
Philippe.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-22 15:00 ` Philippe Gerum
@ 2014-12-22 19:08 ` Lennart Sorensen
0 siblings, 0 replies; 39+ messages in thread
From: Lennart Sorensen @ 2014-12-22 19:08 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Jan Kiszka, xenomai
On Mon, Dec 22, 2014 at 04:00:03PM +0100, Philippe Gerum wrote:
> On 12/22/2014 03:46 PM, Lennart Sorensen wrote:
> > On Mon, Dec 22, 2014 at 12:19:15PM +0100, Philippe Gerum wrote:
> >> On 12/22/2014 11:06 AM, Jan Kiszka wrote:
> >>> Lennart, are you on x86 and do you have CONFIG_CMP disabled? Then
> >>> __ipipe_root_status gets pulled in via arch_local_irq_disable ->
> >>> ipipe_stall_root. If that is the problem, I think it's more than
> >>> reasonable to argue that effectively making local_irq_disable GPL-only
> >>> would be an unwanted restriction over mainline.
> >>>
> >>
> >> This has been agreed upon.
> >
> > Will the change go in git sometime so I can pull it from there. I could
> > change it locally (and did to test it), but would much rather pull the
> > code cange from the git tree.
> >
>
> I'll push the change to the git tree.
Yay!
--
Len Sorensen
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-22 10:06 ` Jan Kiszka
2014-12-22 11:19 ` Philippe Gerum
@ 2014-12-22 14:42 ` Lennart Sorensen
2014-12-22 14:44 ` Jan Kiszka
1 sibling, 1 reply; 39+ messages in thread
From: Lennart Sorensen @ 2014-12-22 14:42 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
On Mon, Dec 22, 2014 at 11:06:53AM +0100, Jan Kiszka wrote:
> Lennart, are you on x86 and do you have CONFIG_CMP disabled? Then
> __ipipe_root_status gets pulled in via arch_local_irq_disable ->
> ipipe_stall_root. If that is the problem, I think it's more than
> reasonable to argue that effectively making local_irq_disable GPL-only
> would be an unwanted restriction over mainline.
This is on powerpc. So far we use xenomai on powerpc and arm, but
not x86. And SMP is disabled since it is a single core MPC8360e.
--
Len Sorensen
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code
2014-12-22 14:42 ` Lennart Sorensen
@ 2014-12-22 14:44 ` Jan Kiszka
0 siblings, 0 replies; 39+ messages in thread
From: Jan Kiszka @ 2014-12-22 14:44 UTC (permalink / raw)
To: Lennart Sorensen; +Cc: xenomai
On 2014-12-22 15:42, Lennart Sorensen wrote:
> On Mon, Dec 22, 2014 at 11:06:53AM +0100, Jan Kiszka wrote:
>> Lennart, are you on x86 and do you have CONFIG_CMP disabled? Then
>> __ipipe_root_status gets pulled in via arch_local_irq_disable ->
>> ipipe_stall_root. If that is the problem, I think it's more than
>> reasonable to argue that effectively making local_irq_disable GPL-only
>> would be an unwanted restriction over mainline.
>
> This is on powerpc. So far we use xenomai on powerpc and arm, but
> not x86. And SMP is disabled since it is a single core MPC8360e.
The pattern on Power is identical to x86: ipipe_stall_root pulls in
__ipipe_root_status if SMP is off.
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20141222/48461978/attachment.sig>
^ permalink raw reply [flat|nested] 39+ messages in thread