linux-kernel - Re: [PATCH 0/3] Bring SFI support to out-of-tree driver modules on Intel Mid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5283C0AE.4050403@linux.intel.com>
Date:	Wed, 13 Nov 2013 10:10:54 -0800
From:	David Cohen <david.a.cohen@...ux.intel.com>
To:	Ingo Molnar <mingo@...nel.org>
CC:	Christoph Hellwig <hch@...radead.org>, tglx@...utronix.de,
	mingo@...hat.com, hpa@...or.com, x86@...nel.org,
	linux-kernel@...r.kernel.org, lenb@...nel.org
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@...radead.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
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/