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

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

[Lennart Sorensen]

I just encountered an issue compiling an external kernel module which
compiled fine with 3.0 kernel but with new kernels I get a linker error
about __ipipe_root_status

This used to be just EXPORT_SYMBOL, but not is EXPORT_SYMBOL_GPL which
breaks the compile.  I am pretty sure module does not call anything in
the kernel flagged EXPORT_SYMBOL_GPL, so it must be something ipipe
gets involved with somehow that is making it fail.  I haven't traced
down exactly how it is happening yet.

Is there any reason this symbol export was changed in newer versions?

-- 
Len Sorensen

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

[Gilles Chanteperdrix]

On Wed, Dec 10, 2014 at 01:37:47PM -0500, Lennart Sorensen wrote:
> I just encountered an issue compiling an external kernel module which
> compiled fine with 3.0 kernel but with new kernels I get a linker error
> about __ipipe_root_status
> 
> This used to be just EXPORT_SYMBOL, but not is EXPORT_SYMBOL_GPL which
> breaks the compile.  I am pretty sure module does not call anything in
> the kernel flagged EXPORT_SYMBOL_GPL, so it must be something ipipe
> gets involved with somehow that is making it fail.  I haven't traced
> down exactly how it is happening yet.
> 
> Is there any reason this symbol export was changed in newer versions?

Xenomai does not support modules with non GPL license.

-- 
					    Gilles.

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

[Lennart Sorensen]

On Wed, Dec 10, 2014 at 07:42:32PM +0100, Gilles Chanteperdrix wrote:
> On Wed, Dec 10, 2014 at 01:37:47PM -0500, Lennart Sorensen wrote:
> > I just encountered an issue compiling an external kernel module which
> > compiled fine with 3.0 kernel but with new kernels I get a linker error
> > about __ipipe_root_status
> > 
> > This used to be just EXPORT_SYMBOL, but not is EXPORT_SYMBOL_GPL which
> > breaks the compile.  I am pretty sure module does not call anything in
> > the kernel flagged EXPORT_SYMBOL_GPL, so it must be something ipipe
> > gets involved with somehow that is making it fail.  I haven't traced
> > down exactly how it is happening yet.
> > 
> > Is there any reason this symbol export was changed in newer versions?
> 
> Xenomai does not support modules with non GPL license.

Well it used to.  Or rather it used to not break the rest of the kernel
from supporting it.

Unfurtunately T1/E1 management software does not exist in free software
versions.

-- 
Len Sorensen

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

[Lennart Sorensen]

On Wed, Dec 10, 2014 at 02:02:40PM -0500, Lennart Sorensen wrote:
> Well it used to.  Or rather it used to not break the rest of the kernel
> from supporting it.
> 
> Unfurtunately T1/E1 management software does not exist in free software
> versions.

All the module is trying to do is strat a kthread and then later find
it to kill it, and it seems having ipipe makes that no longer possible.
I would call that a wrong change in ipipe.

-- 
Len Sorensen

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

[Gilles Chanteperdrix]

On Wed, Dec 10, 2014 at 02:02:40PM -0500, Lennart Sorensen wrote:
> On Wed, Dec 10, 2014 at 07:42:32PM +0100, Gilles Chanteperdrix wrote:
> > On Wed, Dec 10, 2014 at 01:37:47PM -0500, Lennart Sorensen wrote:
> > > I just encountered an issue compiling an external kernel module which
> > > compiled fine with 3.0 kernel but with new kernels I get a linker error
> > > about __ipipe_root_status
> > > 
> > > This used to be just EXPORT_SYMBOL, but not is EXPORT_SYMBOL_GPL which
> > > breaks the compile.  I am pretty sure module does not call anything in
> > > the kernel flagged EXPORT_SYMBOL_GPL, so it must be something ipipe
> > > gets involved with somehow that is making it fail.  I haven't traced
> > > down exactly how it is happening yet.
> > > 
> > > Is there any reason this symbol export was changed in newer versions?
> > 
> > Xenomai does not support modules with non GPL license.
> 
> Well it used to.  Or rather it used to not break the rest of the kernel
> from supporting it.
> 
> Unfurtunately T1/E1 management software does not exist in free software
> versions.

Ah, you mean the problem is with a module which does not use Xenomai
? That is unfortunate.

-- 
					    Gilles.

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

[Lennart Sorensen]

On Wed, Dec 10, 2014 at 08:05:09PM +0100, Gilles Chanteperdrix wrote:
> Ah, you mean the problem is with a module which does not use Xenomai
> ? That is unfortunate.

Yes, and only becasue ipipe messes with the task structures in some way
and the change in the export of that symbol is causing the problem.

Certainly the mainline kernel does not allow existing calls to get broken
by other changes.  Perhaps ipipe should follow the same rule and revert
the change to that symbol.

-- 
Len Sorensen

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

[Lennart Sorensen]

On Wed, Dec 10, 2014 at 02:09:39PM -0500, Lennart Sorensen wrote:
> Yes, and only becasue ipipe messes with the task structures in some way
> and the change in the export of that symbol is causing the problem.
> 
> Certainly the mainline kernel does not allow existing calls to get broken
> by other changes.  Perhaps ipipe should follow the same rule and revert
> the change to that symbol.

This was 2.6.36 ipipe:

./kernel/ipipe/core.c:EXPORT_SYMBOL(__ipipe_root_status);

But later versions changed it to:

./kernel/ipipe/core.c:EXPORT_SYMBOL_GPL(__ipipe_root_status);

and as a result anything that uses that symbol is now implicitly made
GPL only even though those calls are not GPL only.

-- 
Len Sorensen

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

[Gilles Chanteperdrix]

On Wed, Dec 10, 2014 at 02:09:39PM -0500, Lennart Sorensen wrote:
> On Wed, Dec 10, 2014 at 08:05:09PM +0100, Gilles Chanteperdrix wrote:
> > Ah, you mean the problem is with a module which does not use Xenomai
> > ? That is unfortunate.
> 
> Yes, and only becasue ipipe messes with the task structures in some way
> and the change in the export of that symbol is causing the problem.
> 
> Certainly the mainline kernel does not allow existing calls to get broken
> by other changes.  Perhaps ipipe should follow the same rule and revert
> the change to that symbol.

The I-pipe messing with task_struct is not involved here. Using
EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL is what causes the kernel
to refuse loading a module not using the GPL license trying to use
that symbol. That is the purpose of EXPORT_SYMBOL_GPL.

Using EXPORT_SYMBOL_GPL is done by a lot of modules which "follow
the rules", I-pipe included.

-- 
					    Gilles.

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

[Gilles Chanteperdrix]

On Wed, Dec 10, 2014 at 02:09:39PM -0500, Lennart Sorensen wrote:
> On Wed, Dec 10, 2014 at 08:05:09PM +0100, Gilles Chanteperdrix wrote:
> > Ah, you mean the problem is with a module which does not use Xenomai
> > ? That is unfortunate.
> 
> Yes, and only becasue ipipe messes with the task structures in some way
> and the change in the export of that symbol is causing the problem.
> 
> Certainly the mainline kernel does not allow existing calls to get broken
> by other changes.

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

-- 
					    Gilles.

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

[Lennart Sorensen]

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.

-- 
Len Sorensen

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

[Gilles Chanteperdrix]

On Wed, Dec 10, 2014 at 02:19:24PM -0500, 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)

A false statement again: the I-pipe tree is just one tree with the
mainline changes merged from version to version. Granted, this is to
recent a change to solve the issue you have, but please do not
propagate false rumours. 

-- 
					    Gilles.

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

[Lennart Sorensen]

On Wed, Dec 10, 2014 at 08:24:19PM +0100, Gilles Chanteperdrix wrote:
> A false statement again: the I-pipe tree is just one tree with the
> mainline changes merged from version to version. Granted, this is to
> recent a change to solve the issue you have, but please do not
> propagate false rumours. 

Well from my point of view it is a true statement.  I ahve never yet
found a git tree I could look at to see where the ipipe code changes
came from.  All I have ever located just has checkins of new versions
at various points in time.  I would love to actually be able to figure
this out.

There are certainly symbols in ipipe that are just EXPORT_SYMBOL.
Of course there are also some that are inconsistent such as:

./arch/arm/kernel/ipipe.c:EXPORT_SYMBOL_GPL(ipipe_test_and_stall_root);
./arch/powerpc/kernel/ipipe.c:EXPORT_SYMBOL(ipipe_test_and_stall_root);
./arch/blackfin/kernel/ipipe.c:EXPORT_SYMBOL_GPL(ipipe_test_and_stall_root);

As far as I can tell, the change to __ipipe_root_status has made it
impossible to have an ipipe enabled kernel be used for anything by a
non GPL kernel module, even if that module has never heard about ipipe
and doesn't care what so ever about ipipe.

-- 
Len Sorensen

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

[Lennart Sorensen]

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.

-- 
Len Sorensen

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

[Gilles Chanteperdrix]

On Wed, Dec 10, 2014 at 02:19:24PM -0500, 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,

And by the way, you are not "reverting a change". The I-pipe
starting with the version for Linux 3.2 was rewritten from scratch
and called "I-pipe core", did not you see the file names changing ?
So, what you have may simply have been a mistake. Or maybe not. 

And if you want to talk about stupid, using proprietary modules in
products based on Xenomai you redistribute is really stupidly
dangerous, both technically and legally.

-- 
					    Gilles.

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

[Philippe Gerum]

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?

-- 
Philippe.

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

[Gilles Chanteperdrix]

On Wed, Dec 10, 2014 at 02:39:46PM -0500, Lennart Sorensen wrote:
> On Wed, Dec 10, 2014 at 08:24:19PM +0100, Gilles Chanteperdrix wrote:
> > A false statement again: the I-pipe tree is just one tree with the
> > mainline changes merged from version to version. Granted, this is to
> > recent a change to solve the issue you have, but please do not
> > propagate false rumours. 
> 
> Well from my point of view it is a true statement.  I ahve never yet
> found a git tree I could look at to see where the ipipe code changes
> came from.  All I have ever located just has checkins of new versions
> at various points in time.  I would love to actually be able to figure
> this out.

If you checkout
https://git.xenomai.org/ipipe.git/log/?h=raw-ipipe-3.16
You have all the changes that were made since we started working
with a unique tree. As for the change you are referring to, this is
not a change, as explained in the other answer I just sent.

-- 
					    Gilles.

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

[Lennart Sorensen]

On Wed, Dec 10, 2014 at 08:44:58PM +0100, Gilles Chanteperdrix wrote:
> And by the way, you are not "reverting a change". The I-pipe
> starting with the version for Linux 3.2 was rewritten from scratch
> and called "I-pipe core", did not you see the file names changing ?
> So, what you have may simply have been a mistake. Or maybe not. 

I never realized changing ipipe to ipipe core was a huge change, and
certainly never noticed it was a rewrite.  It seemed to work about the
same with xenomai.

> And if you want to talk about stupid, using proprietary modules in
> products based on Xenomai you redistribute is really stupidly
> dangerous, both technically and legally.

Well to manage T1/E1 ports that was what existed.

I don't see a technical problem, we have the sources and are compiling
from source.  The modules build and work fine on the kernel without ipipe,
so clearly it isn't using any part of ipipe.

Legally has been a long time debate by many people.

Fortunately our new product does not have T1/E1 ports so that mess is
not a problem there, but existing products do have them.

-- 
Len Sorensen

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

[Lennart Sorensen]

On Wed, Dec 10, 2014 at 08:47:23PM +0100, Gilles Chanteperdrix wrote:
> If you checkout
> https://git.xenomai.org/ipipe.git/log/?h=raw-ipipe-3.16
> You have all the changes that were made since we started working
> with a unique tree. As for the change you are referring to, this is
> not a change, as explained in the other answer I just sent.

So I guess the part I would love to know is where did te code for this
commit come from:

commit a6118a10918dea6cd9206d2a5127fa1717180fc3
Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Tue Feb 5 21:28:38 2013 +0100

    ipipe: Import generic and x86 bits based on 3.5.7-x86-3

After all that is the first place I see where the symbol in question
has GPL only.

-- 
Len Sorensen

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

[Gilles Chanteperdrix]

On Wed, Dec 10, 2014 at 02:52:36PM -0500, Lennart Sorensen wrote:
> On Wed, Dec 10, 2014 at 08:44:58PM +0100, Gilles Chanteperdrix wrote:
> > And by the way, you are not "reverting a change". The I-pipe
> > starting with the version for Linux 3.2 was rewritten from scratch
> > and called "I-pipe core", did not you see the file names changing ?
> > So, what you have may simply have been a mistake. Or maybe not. 
> 
> I never realized changing ipipe to ipipe core was a huge change, and
> certainly never noticed it was a rewrite.  It seemed to work about the
> same with xenomai.
> 
> > And if you want to talk about stupid, using proprietary modules in
> > products based on Xenomai you redistribute is really stupidly
> > dangerous, both technically and legally.
> 
> Well to manage T1/E1 ports that was what existed.
> 
> I don't see a technical problem, we have the sources and are compiling
> from source.  The modules build and work fine on the kernel without ipipe,
> so clearly it isn't using any part of ipipe.

The technical problem is that the I-pipe relies on macro to
substitute local_irq_save and local_irq_restore in all the code
running in the linux kernel. So technically, any code which uses
local_irq_save and local_irq_restore uses the I-pipe, in an I-pipe
patched kernel. If any code runs which disables the irqs without
using these macros, because it is shipped pre-compiled, then you may
just have lost real-time guarantees.

-- 
					    Gilles.

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

[Gilles Chanteperdrix]

On Wed, Dec 10, 2014 at 02:55:55PM -0500, Lennart Sorensen wrote:
> On Wed, Dec 10, 2014 at 08:47:23PM +0100, Gilles Chanteperdrix wrote:
> > If you checkout
> > https://git.xenomai.org/ipipe.git/log/?h=raw-ipipe-3.16
> > You have all the changes that were made since we started working
> > with a unique tree. As for the change you are referring to, this is
> > not a change, as explained in the other answer I just sent.
> 
> So I guess the part I would love to know is where did te code for this
> commit come from:
> 
> commit a6118a10918dea6cd9206d2a5127fa1717180fc3
> Author: Jan Kiszka <jan.kiszka@siemens.com>
> Date:   Tue Feb 5 21:28:38 2013 +0100
> 
>     ipipe: Import generic and x86 bits based on 3.5.7-x86-3
> 
> After all that is the first place I see where the symbol in question
> has GPL only.

The first commit is the initial import of the ipipe-core branch for
3.2 or 3.1. Since this is a rewrite, you will not see a change. Just
a big patch which adds the new I-pipe core support.

-- 
					    Gilles.

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

[Lennart Sorensen]

On Wed, Dec 10, 2014 at 02:55:55PM -0500, Lennart Sorensen wrote:
> On Wed, Dec 10, 2014 at 08:47:23PM +0100, Gilles Chanteperdrix wrote:
> > If you checkout
> > https://git.xenomai.org/ipipe.git/log/?h=raw-ipipe-3.16
> > You have all the changes that were made since we started working
> > with a unique tree. As for the change you are referring to, this is
> > not a change, as explained in the other answer I just sent.
> 
> So I guess the part I would love to know is where did te code for this
> commit come from:
> 
> commit a6118a10918dea6cd9206d2a5127fa1717180fc3
> Author: Jan Kiszka <jan.kiszka@siemens.com>
> Date:   Tue Feb 5 21:28:38 2013 +0100
> 
>     ipipe: Import generic and x86 bits based on 3.5.7-x86-3
> 
> After all that is the first place I see where the symbol in question
> has GPL only.

OK, that seems to be in the ipipe-gch tree in the for 3.5.7 branch and
came from here:

commit 30d88146bf57a0681cca890bc16f38c6d87bed1a
Author: Philippe Gerum <rpm@xenomai.org>
Date:   Fri Aug 31 10:32:06 2012 +0200

    ipipe: introduce generic pipeline support

-- 
Len Sorensen

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

[Lennart Sorensen]

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

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

[Lennart Sorensen]

On Wed, Dec 10, 2014 at 08:57:49PM +0100, Gilles Chanteperdrix wrote:
> The technical problem is that the I-pipe relies on macro to
> substitute local_irq_save and local_irq_restore in all the code
> running in the linux kernel. So technically, any code which uses
> local_irq_save and local_irq_restore uses the I-pipe, in an I-pipe
> patched kernel. If any code runs which disables the irqs without
> using these macros, because it is shipped pre-compiled, then you may
> just have lost real-time guarantees.

Certainly true.  Nothing precompile in this case though.

-- 
Len Sorensen

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

[Philippe Gerum]

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.

-- 
Philippe.

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

[Philippe Gerum]

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.

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

[Jeff Webb]

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

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

[Lennart Sorensen]

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

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

[Lennart Sorensen]

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

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

[Jeff Webb]

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

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

[Gilles Chanteperdrix]

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.

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

[Lennart Sorensen]

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

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

[Jeff Webb]

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

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

[Jan Kiszka]

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>

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

[Philippe Gerum]

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.

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

[Lennart Sorensen]

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

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

[Jan Kiszka]

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>

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

[Lennart Sorensen]

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

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

[Philippe Gerum]

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.

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

[Lennart Sorensen]

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