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

[Tomi Valkeinen <tomi.valkeinen@xxxxxx>]

On 29/05/15 03:36, Luis R. Rodriguez wrote:
> 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.

I don't have any issue with fbdev changes going through other trees, but
I'd rather do that only if there are good reasons to go that way.

These changes to fbdev drivers look like cleanups, so they are not
critical, right? Does delaying the fbdev changes until the dependencies
are in prevent some other development?

 Tomi

Attachment: signature.asc
Description: OpenPGP digital signature

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