From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965497AbbJIK2v (ORCPT ); Fri, 9 Oct 2015 06:28:51 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:57471 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965472AbbJIK2u (ORCPT ); Fri, 9 Oct 2015 06:28:50 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Sjoerd Simons , Krzysztof Kozlowski , linux-samsung-soc@vger.kernel.org, Russell King , Anand Moon , Lukasz Majewski , linux-kernel@vger.kernel.org, Javier Martinez Canillas , Kukjin Kim Subject: Re: [PATCHv3 1/2] ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4 Date: Fri, 09 Oct 2015 12:28:09 +0200 Message-ID: <5276113.A7SSumyVrv@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <1444384745.9895.265.camel@collabora.co.uk> References: <1444276117-3657-1-git-send-email-linux.amoon@gmail.com> <5551783.9EQ5GEjhxX@wuerfel> <1444384745.9895.265.camel@collabora.co.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:LK/TutWbIf0DN8761aLGlyZfw7idSpgCUk/JK3JBt2UWcZwsmaJ D66rDy2KJv/x8S8Dy5RUc7Xi8t4pwHmfXxrAO0bk3mkEFGkACv1nu9Wke37gkR/ftSTA2nF UlQmInOSn88/i90Ylcatf9ooCotAVCUZV2z/x0eEPphngQq4e+2DJSbrHB7eC0SC4lFOS/I Y8Rcu5XtPgzX0QXaQYt6g== X-UI-Out-Filterresults: notjunk:1;V01:K0:+5sccieM7bo=:LZLqVat8KkvLDlCRxv7Am/ LtBOr/mTTQUR1bWsS14VQmjZvhdSszTcj1Q8ASHwpLJVH4OnT5pm2Oi5swhtYETFBLQUAA9/G G80fJkIHePUoWqha1PXmzD7GVv8V79caLnWWnMahhIymg4wOiWX2HdKS7FME2BD/wukbKPj2a XAMg2u9HJ+afGzftJTWX9UVL2Jaxh+LKkb+4pSX+vm/PcPIzZs6BUjPsVqvwPEJBt2RCOcxYF bDqQbzhkpvGzTXRhvRnQkbYOK/soZifDuowB3US12bxCL9RSgWon81CnzdkvCzw4ezBQwXlOj rgTxZPU9Rxn6pDroR8IDFrHieoFBqjXR8toC3ZV5IenUMVYF1f5PjhDxsml10auv8P/8w7yWC 3abLmQw7oc4fj8LF6DR9ReliD59X3y1jNbrUTjPxhmRs58BDBJWpcf0cAnIxlEIEVGqResY7q I3AVzDYnr2Rrft3oOBRbQN26viwcTywZ4Rex4sNWkNJFdmSrXRUG6aegoYAuftoI5oslOqGT9 bSs2diuFX5NLyNLb0Cbi+/iuvG05U5GLNtJLIZNJeQslNMf0Rzy3kbAl/HMggIGDzimvxXkm+ XZoDKt1qiOZx5Ca0nRUdOQxVZa8gggQMKJVAlVi0UUd7nbrANEqO9R5TkWJYdHR17sxjjUUq4 SPa4nP294Hi2PB5jeQ0f40LRtgGs+00cWnFJqZQjZJpRB0BaIZpxSWSamfJk8Si0yNXoNRISD IvxvbparAPb8V/m/ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 09 October 2015 11:59:05 Sjoerd Simons wrote: > > > I realize that building things as modules is a hassle, it is so for > > some things more than for others, so I keep asking the question > > to everyone to find out what a good balance is to make as much as > > possible modules without hurting too much. > > Fwiw, I don't find building modules overly cumbersome. Getting an > initramfs capable of moving on to an NFS root is mostly a one-time > thing (not unlike setting up the nfs root itself) and injecting modules > into it is relatively simple (doubly so if taking advantage of the > multiple cpio archive feature linux has). > > Interestingly, for me not building things as modules in multi_v7 tends > to cause more work as it hides a few categories of bugs that tend to > crop up once building distro kernels (e.g. missing module aliases, > missing module device table entries, implicitly relying on clocks being > active during probe as unused clocks only get turned of late in the > init sequence etc). > Ok, let's try to make all future network drivers modules in the multi_v7_defconfig then, and get people to use an initramfs if they need NFS root. If nobody complains too loudly for the next few releases, we can change the existing drivers to =m as well. Arnd