[lttng-dev] [PATCH 01/11] mm: export vmalloc_sync_all symbol to GPL modules

[Greg KH]

On Thu, Dec 01, 2011 at 05:28:03PM -0500, Christoph Hellwig wrote:
> On Thu, Dec 01, 2011 at 02:13:37PM -0800, Greg KH wrote:
> > On Thu, Dec 01, 2011 at 04:57:00PM -0500, Christoph Hellwig wrote:
> > > On Thu, Dec 01, 2011 at 04:41:13PM -0500, Mathieu Desnoyers wrote:
> > > > LTTng needs this symbol exported. It calls it to ensure its tracing
> > > > buffers and allocated data structures never trigger a page fault. This
> > > > is required to handle page fault handler tracing and NMI tracing
> > > > gracefully.
> > > 
> > > We:
> > > 
> > >  a) don't export symbols unless they have an intree-user
> > 
> > lttng is now in-tree in the drivers/staging/ area.  See linux-next for
> > details if you are curious.
> 
> Eww - merging stuff without discussion on lkml is more than evil.

Do you really want discussing all staging driver crap on lkml?

Core changes, like this one, for stuff in staging should be done on
lkml, which is what this conversation is :)

> Either way, it was guaranteed that drivers/staging is considered out of
> tree for core code.

The zram and zcache code would tend to disagree with you there :)

> I'm defintively dead set against exporting anything for staging and
> opening that slippery slope.

How else should we handle something like this then?  Some code, this one
specifically, is trying to get merged, so taking it slowly, through
staging, and getting it reviewed and cleaned up better before it can go
into the "real" part of the kernel, is the whole goal here.

Here's a real need for a symbol that an existing, shipping, useful
kernel module is wanting to use.

If you can provide a way that this can be handled without such an
export, that does not require digging through the symbol table (which is
what it was doing and I rightfully objected to that), then please let us
know.

Otherwise, what are our alternatives here, to just forbid this code from
ever being merged?

thanks,

greg k-h