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: <CA+5PVA4-8CDT1Mfw_t6WKu6zmo1Ugn4ssTXPCS-W-bPnKtH=5g@mail.gmail.com>
Date:	Tue, 15 Apr 2014 07:50:05 -0400
From:	Josh Boyer <jwboyer@...oraproject.org>
To:	Greg KH <gregkh@...uxfoundation.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>,
	Josh Boyer <jwboyer@...oraproject.org>
Subject: Re: Hardware dependencies in Kconfig

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?  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?

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.

>> Ideally I would like to be able to run "make oldconfig" on a new kernel
>> version and only be asked about things I should really care about. And
>> I'm sure every distro kernel package maintainer and most kernel
>> developers and advanced users feel the same.
>
> I agree, but partitioning all new drivers off to a single arch might be
> hard to do.  It's not a simple problem, I'd suggest getting a faster
> build box to start with :)

In some cases, that literally isn't possible.  As far as I'm aware,
Fedora is using the fastest available ARM server boxes from Calxeda.
In the future, AArch64 machines will help but that doesn't solve the
problem of bloat anyway.

josh
--
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/