public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Jean Delvare <jdelvare@suse.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Marek <mmarek@suse.cz>
Subject: Re: Hardware dependencies in Kconfig
Date: Tue, 15 Apr 2014 08:24:52 -0700	[thread overview]
Message-ID: <20140415152452.GC7311@kroah.com> (raw)
In-Reply-To: <CA+5PVA4-8CDT1Mfw_t6WKu6zmo1Ugn4ssTXPCS-W-bPnKtH=5g@mail.gmail.com>

On Tue, Apr 15, 2014 at 07:50:05AM -0400, Josh Boyer wrote:
> On Tue, Apr 15, 2014 at 12:52 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Mon, Apr 14, 2014 at 11:12:54PM +0200, Jean Delvare wrote:
> >> And it's not going to get any better over time. As others have already
> >> mentioned, most new drivers these days are NOT for x86, they are for
> >> ARM, AVR32 and other fancy embedded architectures.
> >>
> >> "Just say m to everything" is just so wrong today that at SUSE we are
> >> very close to switching our policy to "just say no to everything and
> >> wait for people to complain about missing drivers." This may not sound
> >> too appealing but this is the only way to keep the kernel package at a
> >> reasonable size (and build time), as long as upstream doesn't help us
> >> make smarter decisions. Useless modules aren't free, they aren't even
> >> cheap.
> 
> FWIW, we did that policy changed in Fedora a while ago.  Not
> wholesale, but if it looks niche, it's disabled by default and enabled
> only on request.
> 
> > I'd argue that your build systems need to get faster, the laptop I'm
> > typing this on can do a full modconfig build, with over 3000 modules, in
> > around 20 minutes.  My build server in the cloud can do that in less
> > than 5 minutes, and that's not a very fast machine these days.
> 
> Is that literally 'make modconfig && make bzImage && make modules' in
> those setups?

Yes, I use ktest with the allmodconfig option.

> I'm curious if the distros have some options enabled
> that significantly impact build time.  Perhaps CONFIG_DEBUG_INFO or
> something else like that.  Could you send me whatever config results
> from what you're building in 5min?

You can use ktest with the BUILD_TYPE set to allmodconfig and it will
reproduce the same options.

> It takes my desktop machine about 30-45min to build an x86_64 kernel
> RPM with the current configs.  Now granted, that's a bit more than
> just building a kernel in a local git tree, but it's nowhere near
> 5min.  Our official build servers show similar timings for x86_64.
> 
> For ARM kernels, it takes about 3.5-4 hours.  That's due to policy
> decisions on now allowing cross-builds in the distro (sigh), so all of
> the kernels are built on native ARM machines.

That's really crazy to do that, there is this wonderful tool called
qemu... :)

good luck,

greg k-h

  reply	other threads:[~2014-04-15 15:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-14 12:53 Hardware dependencies in Kconfig Jean Delvare
2014-04-14 13:06 ` Josh Boyer
2014-04-14 19:11 ` Greg KH
2014-04-14 19:59   ` Josh Boyer
2014-04-15  4:53     ` Greg KH
2014-04-15  7:27       ` Jean Delvare
2014-04-14 21:12   ` Jean Delvare
2014-04-15  4:52     ` Greg KH
2014-04-15 10:26       ` Michal Marek
2014-04-15 10:54       ` Jean Delvare
2014-04-15 17:36         ` Randy Dunlap
2014-04-15 11:50       ` Josh Boyer
2014-04-15 15:24         ` Greg KH [this message]
2014-04-15 15:34           ` Josh Boyer
2014-04-22 13:42       ` Jean Delvare
2014-04-29  9:23       ` Pavel Machek
2014-04-23 17:45   ` Generating .config from device tree [was Re: Hardware dependencies in Kconfig] Pavel Machek

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=20140415152452.GC7311@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=jdelvare@suse.de \
    --cc=jwboyer@fedoraproject.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=torvalds@linux-foundation.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