On Sep 18, 2010, at 11:56 AM, Josh Boyer wrote: > On Sat, Sep 18, 2010 at 11:34 AM, Kumar Gala <kumar.g...@freescale.com> wrote: >> >> On Sep 18, 2010, at 9:36 AM, Tabi Timur-B04825 wrote: >> >>> On Sep 17, 2010, at 10:14 PM, "Benjamin Herrenschmidt" >>> <b...@kernel.crashing.org> wrote: >>> >>>> On Fri, 2010-09-17 at 20:20 -0500, Timur Tabi wrote: >>>>> I don't see any reason to limit it to GPL drivers. Not only that, but >>>>> then we'll have this: >>>> >>>> I do >>> >>> Can you elaborate on that, or are you just going to pull rank on me? >>> >>>> >>>>> EXPORT_SYMBOL(ppc_proc_freq); >>>>> EXPORT_SYMBOL_GPL(ppc_tb_freq); >>>>> >>>>> That just looks dumb. >>>> >>>> Right, so send a patch to fix the first one too :-) >> >> I don't think either of these should be EXPORT_SYMBOL_GPL. Why shouldn't a >> binary module be allowed to know these frequencies? My view is why preclude >> anyone from using this how they want. If they want to live in the gray area >> so be it. Who am I to say they shouldn't have that choice. >> > > It is not, in my opinion, about what is technically possible and what > isn't. The kernel is licensed under the GPL. This is a Linux kernel > only symbol. One would be hard pressed to claim they have a driver > that wasn't written for Linux that happens to need that symbol. As a > member of the Linux kernel community, I find it important to encourage > the contribution of code back to the kernel, and this is one way to > help that. This isn't BSD. > > Besides, a developer is free to export it however they wish in their > own kernel tree. They can deviate from mainline if they so choose.
I'll buy this argument as a reason to make both EXPORT_SYMBOL_GPL. - k _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
