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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
