From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5488C149.8020901@nta-inc.net> Date: Wed, 10 Dec 2014 15:55:21 -0600 From: Jeff Webb MIME-Version: 1.0 References: <20141210184232.GP1524@hermes.click-hack.org> <20141210190240.GB24110@csclub.uwaterloo.ca> <20141210190509.GR1524@hermes.click-hack.org> <20141210190939.GD24110@csclub.uwaterloo.ca> <20141210191350.GT1524@hermes.click-hack.org> <20141210191924.GF24110@csclub.uwaterloo.ca> <5488A2BD.3080800@xenomai.org> <20141210194405.GH24110@csclub.uwaterloo.ca> <5488A985.2070006@xenomai.org> <20141210201140.GL24110@csclub.uwaterloo.ca> <20141210212342.GO24110@csclub.uwaterloo.ca> In-Reply-To: <20141210212342.GO24110@csclub.uwaterloo.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] __ipipe_root_status exported GPL only but used to be not GPL only and is breaking other code List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xenomai@xenomai.org 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