From: Dan Williams <dan.j.williams@intel.com>
To: Jerome Glisse <jglisse@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
mvitale@sinenomine.net, linux-mm <linux-mm@kvack.org>,
dan.j.williams@intel.org, jgorse@sinenomine.net,
release-team@openafs.org
Subject: Re: [PATCH v4 0/8] mm: Rework hmm to use devm_memremap_pages and other fixes
Date: Sat, 21 Jul 2018 09:11:46 -0700 [thread overview]
Message-ID: <CAA9_cmf0tGZJGWWnoBR6078Wy_RUe6OnFChp+DEk5TwE6k1gqQ@mail.gmail.com> (raw)
In-Reply-To: <20180720201706.GE7697@redhat.com>
On Fri, Jul 20, 2018 at 1:17 PM Jerome Glisse <jglisse@redhat.com> wrote:
>
> On Fri, Jul 20, 2018 at 01:01:24PM -0700, Matthew Wilcox wrote:
> > On Fri, Jul 20, 2018 at 03:57:47PM -0400, Jerome Glisse wrote:
> > > On Fri, Jul 20, 2018 at 12:51:46PM -0700, Andrew Morton wrote:
> > > > Problem is, that patch is eighth in a series which we're waiting for
> > > > Jerome to review and the changelog starts with "Now that all producers
> > > > of dev_pagemap instances in the kernel are properly converted to
> > > > EXPORT_SYMBOL_GPL...".
> > >
> > > I am fine with the patchset modulo GPL, i did review it in the past
> > > but i did not formaly reply as i was opose to the GPL changes. So my
> > > only objection is with the GPL export, everything else looks fine.
> >
> > Everyone from the mm side who's looked at these patches agrees that it
> > reaches far too far into the guts of the mm to be anything other than
> > exposing internals. It's not credible to claim that a module written that
> > uses these interfaces is anything other than a derived work of the kernel.
> >
> > I feel these patches should be merged over Jerome's objections.
>
> I feel that people do not understand how far reaching this is. It means
> that any new devices with memory supporting new system bus like CAPI or
> CCIX will need to have a GPL driver. This is a departure of current
> state of affair where we allow non GPL driver to exist.
Proprietary GPU driver vendors have done just fine without us adding
explicit new mechanisms for them to consume.
> Moreover I have argue that HMM abstract the internal mm and by doing so
> allow anyone to update the mm code without having to worried about driver
> which use HMM. Thus disproving that user of HMM are tie to mm internal.
No, HMM has has deployed a GPL-bypass shim into the kernel.
> Also to make thing perfectly clear i am a strong proponent of open
> source and i rather have a GPL driver but at the same time i do not want
> linux kernel to become second citizen because it can not support new
> devices ...
HMM diminishes the letter and the spirit of EXPORT_SYMBOL_GPL, it
grants access to and consumes GPL-only infrastructure written by me
and others.
next prev parent reply other threads:[~2018-07-21 16:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-20 14:43 Mark Vitale
2018-07-20 19:51 ` Andrew Morton
2018-07-20 19:57 ` Jerome Glisse
2018-07-20 20:01 ` Matthew Wilcox
2018-07-20 20:17 ` Jerome Glisse
2018-07-21 16:11 ` Dan Williams [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-07-11 5:14 Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA9_cmf0tGZJGWWnoBR6078Wy_RUe6OnFChp+DEk5TwE6k1gqQ@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.org \
--cc=jglisse@redhat.com \
--cc=jgorse@sinenomine.net \
--cc=linux-mm@kvack.org \
--cc=mvitale@sinenomine.net \
--cc=release-team@openafs.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox