On Tue, Jun 05, 2018 at 04:06:12PM -0700, Dan Williams wrote:
> On Tue, Jun 5, 2018 at 3:19 PM, Dave Airlie <airlied@xxxxxxxxx> wrote:
> > On 6 June 2018 at 04:48, Jerome Glisse <jglisse@xxxxxxxxxx> wrote:
> >> On Tue, May 29, 2018 at 04:33:49PM -0700, Dan Williams wrote:
> >>> On Tue, May 29, 2018 at 4:00 PM, Dave Airlie <airlied@xxxxxxxxx> wrote:
> >>> > On 30 May 2018 at 08:31, Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
[...]
> >>> It honestly was an oversight, and as we've gone on to add deeper and
> >>> deeper ties into the mm and filesystems [1] I realized this symbol was
> >>> mis-labeled. It would be one thing if this was just some random
> >>> kernel leaf / library function, but this capability when turned on
> >>> causes the entire kernel to be recompiled as things like the
> >>> definition of put_page() changes. It's deeply integrated with how
> >>> Linux manages memory.
> >>
> >> I am personaly on the fence on deciding GPL versus non GPL export
> >> base on subjective view of what is deeply integrated and what is
> >> not. I think one can argue that every single linux kernel function
> >> is deeply integrated within the kernel, starting with all device
> >> drivers functions. One could similarly argue that nothing is ...
> >
> > This is the point I wasn't making so well, the whole deciding on a derived
> > work from the pov of one of the works isn't really going to be how a court
> > looks at it.
> >
> > At day 0, you have a Linux kernel, and a separate Windows kernel driver,
> > clearly they are not derived works.
> >
> > You add interfaces to the Windows kernel driver and it becomes a Linux
> > kernel driver, you never ship them together, derived work only if those
> > interfaces are GPL only? or derived work only if shipped together?
> > only shipped together and GPL only? Clearly not a clearcut case here.
> >
> > The code base is 99% the same, the kernel changes an export to a GPL
> > export, the external driver hasn't changed one line of code, and it suddenly
> > becomes a derived work?
> >
> > Oversights happen, but 3 years of advertising an interface under the non-GPL
> > and changing it doesn't change whether the external driver is derived or not,
> > nor will it change anyone's legal position.
>
> My concern is the long term health and maintainability of the Linux
> kernel. HMM exports deep Linux internals out to proprietary drivers
> with no way for folks in the wider kernel community to validate that
> the interfaces are necessary or sufficient besides "take Jerome's word
> for it". Every time I've pushed back on any HMM feature the response
> is something to the effect of, "no, out of tree drivers need this".
> HMM needs to grow upstream users and the functionality needs to be
> limited to whatever those upstream users exploit. Since there are no
> upstream users of HMM, we should delete it unless / until those users
> arrive.
The raison d'être of HMM is to isolate driver from mm internal gut and
thus provide a clear contract and API to device driver. I tried to spell
that contract in include/linux/hmm.h which i can re-formulate shortly in:
- provide call back when CPU try to access a device page so that
memory can be migrated back to CPU accessible page under the
control of the device driver for device synchronization reasons
(the whole gory mm details is still in mm/migrate.c it just does
provide way point in the migration process so that the device
driver can synchronize and update the hardware along the way too)
- provide a 64bits storage inside struct page so that the device
driver can store either pointer to its internal data structure
or store necessary informations there while page is in use in a
process
- inform device driver once a page is freed (ie no longer use in a
process address space)
This virtualy isolate device driver from the inner gut of mm and allow
mm to change as long as we can keep this contract in place. As long as
device driver only use HMM API to perform any of the above and this is
my intention to push for that and try to enforce it as strongly as i
can.
Nouveau patchset have been posted and i will post newer updated version
this month and i hope this can get upstream in 4.19 abidding by the drm
sub-system requirement of having open source userspace upstream in mesa
project too (which have been under work for last few months).
This whole thing have been a big chicken and egg nightmare with moving
pieces everywhere. I wish i was better at getting all the pieces ready
at the same time but alas i was not.
>
> I want the EXPORT_SYMBOL_GPL on devm_memremap_pages() primarily for
> development purposes. Any new users of devm_memremap_pages() should be
> aware that they are subscribing to the whims of the core-VM, i.e. the
> ongoing evolution of 'struct page', and encourage those drivers to be
> upstream to improve the implementation, and consolidate use cases. I'm
> not qualified to comment on your "nor will it change anyone's legal
> position.", but I'm saying it's in the Linux kernel's best interest
> that new users of this interface assume they need to be GPL.
Note that HMM isolate the device driver from struct page as long as
the driver only use HMM helpers to get to the information it needs.
I intend to be pedantic about that with any driver using HMM. I want
HMM to be an impedance layer that provide stable and simple API to
device driver while preserving freedom of change to mm.
Cheers,
Jérôme
