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. josh _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
