linux-kernel - Re: Hardware dependencies in Kconfig

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: <20140415152452.GC7311@kroah.com>
Date:	Tue, 15 Apr 2014 08:24:52 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Josh Boyer <jwboyer@...oraproject.org>
Cc:	Jean Delvare <jdelvare@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michal Marek <mmarek@...e.cz>
Subject: Re: Hardware dependencies in Kconfig

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@...uxfoundation.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
--
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/