From: David Cohen <david.a.cohen@linux.intel.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
x86@kernel.org, linux-kernel@vger.kernel.org, lenb@kernel.org
Subject: Re: [PATCH 0/3] Bring SFI support to out-of-tree driver modules on Intel Mid
Date: Wed, 13 Nov 2013 10:10:54 -0800 [thread overview]
Message-ID: <5283C0AE.4050403@linux.intel.com> (raw)
In-Reply-To: <20131113111934.GB9654@gmail.com>
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
>
next prev parent reply other threads:[~2013-11-13 18:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-12 22:13 [PATCH 0/3] Bring SFI support to out-of-tree driver modules on Intel Mid David Cohen
2013-11-12 22:13 ` [PATCH 1/3] sfi: add private data to sfi_parse_table() David Cohen
2013-11-12 22:13 ` [PATCH 2/3] x86: intel-mid: struct devs_id.name should have 'SFI_NAME_LEN' length David Cohen
2013-11-12 22:13 ` [PATCH 3/3] x86: intel-mid: allow sfi_device() to be used by modules David Cohen
2013-11-13 8:14 ` [PATCH 0/3] Bring SFI support to out-of-tree driver modules on Intel Mid Christoph Hellwig
2013-11-13 11:19 ` Ingo Molnar
2013-11-13 18:10 ` David Cohen [this message]
2013-11-15 22:25 ` David Cohen
2013-11-13 19:29 ` [PATCH] x86: intel-mid: add test module for sfi_device() David Cohen
2013-11-13 19:31 ` David Cohen
2013-11-16 0:09 ` [PATCH v1.1] " David Cohen
2013-11-18 15:28 ` Christoph Hellwig
2013-11-18 17:35 ` David Cohen
2013-11-18 17:37 ` David Cohen
2013-11-21 18:25 ` David Cohen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5283C0AE.4050403@linux.intel.com \
--to=david.a.cohen@linux.intel.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).