On Tue, Apr 15, 2014 at 11:24 AM, Greg KH <gre...@linuxfoundation.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 <gre...@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.
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/