Re: [PATCH v7 1/7] mm, devm_memremap_pages: Mark devm_memremap_pages() EXPORT_SYMBOL_GPL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed 17-10-18 09:30:58, Dan Williams wrote:
> On Wed, Oct 17, 2018 at 1:18 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote:
[...]
> > > Again, devm_memremap_pagex() exposes and relies upon core kernel
> > > internal assumptions and will continue to evolve along with 'struct
> > > page', memory hotplug, and support for new memory types / topologies.
> > > Only an in-kernel GPL-only driver is expected to keep up with this
> > > ongoing evolution. This interface, and functionality derived from this
> > > interface, is not suitable for kernel-external drivers.
> >
> > I do not follow this line of argumentation though. We generally do not
> > care about out-of-tree modules and breaking them if the interface has to
> > be updated.
> 
> Exactly right. The EXPORT_SYMBOL_GPL is there to say that this api has
> deep enough ties into the core kernel to lower the confidence that the
> API will stay stable from one kernel revision to the next. It's also
> an api that is attracting widening and varied reuse and the long term
> health of the implementation depends on being able to peer deeply into
> its users and refactor the interface and the core kernel as a result.

I am sorry I do not follow. For in-tree modules you have to update users
whether the export is GPL or not and we do not care _at all_ about out
of tree because we do not guarantee _any_ kABI/API stability
(Documentation/process/stable-api-nonsense.rst).

Anyway, I do not really care much, but I find the way of the
argumentation dubious. I can clearly understand a simple line "me as the
author want this GPL - live with that".
-- 
Michal Hocko
SUSE Labs




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux