Re: [Xen-devel] [PATCH v6 1/4] pci: add pci_iomap_wc() variants

["Luis R. Rodriguez" <mcgrof@xxxxxxxxxxxxxxxx>]

On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
> On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
>> On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
>> > On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
>> > >
>> > > I tentatively put this (and the rest of the series) on a pci/resource
>> > > branch.  I'm hoping you'll propose some clarification about
>> > > EXPORT_SYMBOL_GPL().
>> >
>> > EXPORT_SYMBOL_GPL() also serves to ensure only GPL modules can
>> > only run that code. So for instance although we have "Dual BSD/GPL"
>> > tags for modules pure "BSD" tags do not exist for module tags and
>> > cannot run EXPORT_SYMBOL_GPL() code [0]. Also there is some folks
>> > who do believe tha at run time all kernel modules are GPL [1] [2].
>> > And to be precise even though the FSF may claim a list of licenses
>> > are GPL-compatible we cannot rely on this list alone for our own
>> > goals and if folks want to use our EXPORT_SYMBOL_GPL()s they must
>> > discuss this on lkml [2].
>>
>> By "propose some clarification," I meant that I hoped you would propose a
>> patch to Documentation/ that would give maintainers some guidance.
>
> I *really really* would hate to do so but only because you insist, I'll look
> into this...

OK done. Please let me know if there is anything else I can do to
help. Also as per review with Tomi, the framebuffer maintainer, he
would prefer for only the required symbols to go through your tree.
We'd then wait for the next merge window for them to perculate to
Linus' tree and once there I'd send him a pull request for the
framebuffer device driver changes alone. So this does mean we'll have
no users of the symbols for a full release, but again, this is as per
Tomi's preference. This strategy is also the preference then for the
pci_iomap_wc() series as well. With that in mind, perhaps the lib
patch can go in as we'd have no users but we do have a few future
possible expected users.

 Luis

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel