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]

Date:	Tue, 15 Apr 2014 11:34:30 -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>
Subject: Re: Hardware dependencies in Kconfig

On Tue, Apr 15, 2014 at 11:24 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
> 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.

OK, I'll look at what it produces.  Thanks.

I still agree with Jean that this isn't a solution to the actual problem though.

>> 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... :)

Yes, well... I don't get to set the policy.  This particular brand of
crazy does have some benefits, but I'm not sure they outweigh the
negatives.

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/