On Fri, Jan 21, 2011 at 03:27:57PM -0700, Matthew Burgess wrote: > > If we set it to 2.6.30 (there's no point in adding the stable version as > Glibc only checks the major.minor.patch level), we'll miss out on > F_GETOWN_EX (new in 2.6.32 - see http://lwn.net/Articles/354842/) and > recvmmsg (new in 2.6.33 - see http://lwn.net/Articles/334854/) support. > > Release dates of those kernels are as follows: > > 2.6.30 - 10-Jun-2009 > 2.6.32 - 03-Dec-2009 > 2.6.33 - 24-Feb-2010 > > So, by the time LFS-6.8 is released, 2.6.33 will have been out for just over > 12 months. Given that most major distros have moved to a 6-month release > cycle, and that LFS-6.7 also meets that dependency, I don't think it's an > overly hard-to-meet requirement, so I propose bumping it straight up to > 2.6.33. > > Thoughts? > > Matt. > Sounds good. For my own builds, I normally run a host kernel newer than glibc knows about. I specify --enable-kernel=2.6.33 at the moment. I prefer it to =current because it reminds me to check what versions glibc knows about when I build a new system. [ I usually build several new kernels each month, most of them -rc versions ].
Very rarely, e.g. when I was first messing with kms, I might specify a slightly older kernel if I think I might have to bisect kernel problems. But then, I'm usually a firm believer in "run the kernel (on the host) that you intend to use on the new system". Saves aggravation trying to sort out an old .config that broke across kernel upgrades - it's much easier to fix those problems in a full-featured system. I can see that isn't possible for people using a Live CD, but for everyone else I still recommend it. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
