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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <52869F3E.30702@linux.intel.com>
Date:	Fri, 15 Nov 2013 14:25:02 -0800
From:	David Cohen <david.a.cohen@...ux.intel.com>
To:	Christoph Hellwig <hch@...radead.org>
CC:	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 12:14 AM, Christoph Hellwig wrote:
> On Tue, Nov 12, 2013 at 02:13:37PM -0800, David Cohen wrote:
>> Hi,

Hi Christoph,

>>
>> 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 got your point.
Here's the testable user:
https://patchwork.kernel.org/patch/3179381/
By simply 'make ARCH=i386 allyesconfig' it will be selected.

But I think there is a misunderstanding here :)
My main target is to sync Intel MID codes from our internal tree to
upstream. These patches I am sending are useful to protect Intel MID
from drivers I don't own and not ready for upstreaming.
My main intention is to upstream more Intel MID codes in a faster and
more reliably way (if internal tree == upstream my tests will be
better).

Since Intel MID users are too sensitive to time to market (sorry to
bring this scenario but we can't run from it on embedded world) I can't
prevent drivers not ready yet for upstreaming to use sfi_device() macro.

So, given my intention is to increase upstreamed codes, do you think it
makes sense to have this sfi_device() modularization support?

Br, David Cohen
--
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/