All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.