Messages in this thread |  | | Date | Wed, 13 Nov 2013 10:10:54 -0800 | From | David Cohen <> | Subject | Re: [PATCH 0/3] Bring SFI support to out-of-tree driver modules on Intel Mid |
| |
On 11/13/2013 03:19 AM, Ingo Molnar wrote: > > * Christoph Hellwig <hch@infradead.org> wrote: > >> On Tue, Nov 12, 2013 at 02:13:37PM -0800, David Cohen wrote: >> >>> Hi, >>> >>> This patchset extends sfi_device() macro support to driver modules. >>> The main use case is to allow external driver modules to be enumerated >>> by SFI on Intel Mid platforms. >> >> How about you merge those module again? Remember code added to the >> kernel without users isn't testable, and out of tree modules do not >> bring us any value add. > > I wanted to make the exact same point. > > I recently had to revert a similarly misguided attempt which added bloat > for out of tree modules without merging it in tree, see commit > b5dfcb09debc ("Revert "x86/UV: Add uvtrace support").
I was a bit reluctant in sending these patches, but I can tell my background to explain why:
I work most of my time with embedded platforms and I got the duty to maintain and sync Intel Mid codes from our internal tree to upstream (if you check out there Android trees supporting Intel platform you'll see it's completely different to what we have officially on Linux).
Unfortunately some drivers depend on Intel Mid to support a legacy device enumeration with SFI + platform codes (these platform codes are placed into arch/x86/platform/intel-mid/device_libs/). It means I need to support in my internal tree files that belong to drivers I don't own. Most of times it's OK, but regardless my will, we've drivers that can't be upstreamed right away.
In order to keep sanity in Intel Mid codes between internal tree and upstream, I'm trying to make non-upstreamable drivers to not mix platform codes to Intel Mid until they are ready to get merged to Linux kernel officially. This change makes Linux more friendly for drivers to reach time-to-market and do upstream work at same time. One other reason is to keep my internal tree closer to upstream and make things easier for upstreaming of Intel Mid patches themselves (which is my main interest).
But this code is testable. I used the word "external" because all the platform code merged into Linux are compiled as builtin. But my tests prior to send these patches were done by converting some of those codes to be compiled as module (I am glad to share the patches for tests).
Br, David Cohen
> > Thanks, > > Ingo >
|  |