From 7250b3a21cc2c01c69f162bb365d6fda2cdf7bbe Mon Sep 17 00:00:00 2001 From: Paul Menzel Date: Mon, 13 Nov 2017 16:02:10 +0100 Subject: [PATCH] linux: Add mainline version 4.14 Announcement for Linux 4.13 [1]: > No surprises this week, although it is probably worth pointing out how > the 0day robot has been getting even better (it was very useful > before, but Fengguang has been working on making it even better, and > reporting the problems it has found). > > Sure, some of the new reports turned out to be just 0day doing things > that just don't work (ie KASAN with old gcc versions, but also doing > things like loading old ISA drivers in situations that just don't make > sense - remember when you couldn't even ask if the hardware existed or > not, and just had to know), but even then it's been all good. > > The appended shortlog is obviously only for the (small) haul since > rc8, and it really is tiny. Not very many commits, and they are small. > The biggest thing that stands out in the diffstat is the > "leaking_addresses" perl script, which is actually under active > development, but I put the first version in for 4.14 just so that > people could see that initial state and start looking at the end > result and perhaps ask themselves "should my code make these kernel > addresses visible to user space". > > The actual changes will hopefully start percolating into 4.15, with > one notable llikely early change (which has been discussed extensively > on the list) being to just hash any "%p" addresses by default. We used > to have strict modes that just zeroed the address out, but that was > actually counter-productive, in that often people use the address as a > "kernel object identity" for debugging (or fro cross-correlation - > think network sockets), and so just clearing the pointer value makes > those kinds of uses pointless. But using a secure hash allows for > those kinds of identity uses, while not actually leaking the address > itself. > > (Other situations where the actual address is relevant then need other > approaches - we'll be restricting /proc/kallsyms only to entities that > actually need them etc etc). > > Anyway, apart from that one script, the rest of it really is > one-liners or "few-liners". > > The most noticeable last-minute change is probably that we had to > revert the code that showed a good MHz value in /proc/cpuinfo even for > the modern "CPU picks frequency dynamically" case. It worked fine, but > it was much too expensive on machines with tens or hundreds of CPU > cores. There's a cunning plan, but it didn't make 4.14, so we'll get > it working and then back-port. > > Anything else is pretty esoteric, you can just read the changelog.. > > And with this, the merge window for 4.15 is obviously open. As > mentioned in the late rc announcements, the extra week for rc8 means > that now Thanksgiving week ends up happening during the second half of > the merge window, and I'll be off on a family vacation. > > We'll see how that goes. > > I might decide that I'll extend the merge window if I feel that I > can't be responsive enough. > > Or maybe you guys won't even notice, because I _will_ have my laptop > and internet access. > > Or maybe I will just decide that 4.14 was a painful release, and any > late stragglers for 4.15 are not worth _another_ painful release, and > I'll just say "tough luck, you were late to the merge window, and I > felt more like being out in the sun than taking your second-week pull > request". > > Because it really would be lovely to have a smaller and calmer release for 4.15. > > Anyway, go out and test the new 4.14 release, that is slated to be the > next LTS kernel - and start sending me pull request for the 4.15 merge > window. [1] https://lkml.org/lkml/2017/11/12/123 --- linux-4.14-189.bee | 79 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100755 linux-4.14-189.bee diff --git a/linux-4.14-189.bee b/linux-4.14-189.bee new file mode 100755 index 000000000..fc68c0aaa --- /dev/null +++ b/linux-4.14-189.bee @@ -0,0 +1,79 @@ +#!/bin/env beesh + +# note: CONFIG=/boot/config-WHATEVER BEE_MAKEFLAGS='-j 40' ./linux-xxx.bee + +KERNELVERSION=${PKGVERSION} +if [ -z "${PKGVERSION[3]}" ] ; then + KERNELVERSION=${KERNELVERSION}.0 +fi + +# append extra version to get for example 4.8.0-rc4 +KERNELVERSION=${KERNELVERSION}${PKGEXTRAVERSION_DASH} + +echo $KERNELVERSION + +SRCURL[0]="https://cdn.kernel.org/pub/linux/kernel/v${PKGVERSION[1]}.x/linux-${PKGVERSION}${PKGEXTRAVERSION_DASH}.tar.xz" + +# EXCLUDE="" + +#CONFIG= + +KERNELLOCAL=".mx64.${PKGREVISION}" +FULLKERNELVERSION="${KERNELVERSION}${KERNELLOCAL}" + +B=${S} + +mee_patch() { + echo "PATCH $@" + bee_patch $@ +} + +mee_configure() { + echo "configure $@" + if [ -e /proc/config.gz ] ; then + zcat /proc/config.gz >config-current + RUNNING=config-current + else + RUNNING=/boot/config-$(uname -r) + fi + + : ${CONFIG:=${RUNNING}} + + if [ ! -e ${CONFIG} ] ; then + echo "can't find config '${CONFIG}'" + exit 1 + fi + + cp -v ${CONFIG} .config + + LOCALVERSION="\"${KERNELLOCAL}\"" + sed -i -e "s@CONFIG_LOCALVERSION=.*@CONFIG_LOCALVERSION=${LOCALVERSION}@" .config + + echo "doing make -C ${S} olddefconfig in ${PWD} .." + + make olddefconfig + + echo "doing make -C ${S} menuconfig in ${PWD} .." + + make menuconfig +} + +mee_build() { + echo "build $@" + make ${BEE_MAKEFLAGS} +} + +mee_install() { + echo "install $@" + + make modules_install INSTALL_MOD_PATH=${D} + make install INSTALL_PATH=${D}/boot +# make firmware_install INSTALL_MOD_PATH=${D} + + rm -v ${D}/lib/modules/${FULLKERNELVERSION}/{source,build} + + ln -sv /usr/src/linux/${PKGALLPKG}/source ${D}/lib/modules/${FULLKERNELVERSION}/source + ln -sv /usr/src/linux/${PKGALLPKG}/build ${D}/lib/modules/${FULLKERNELVERSION}/build + + ln -sv bzImage-${FULLKERNELVERSION} ${D}/boot/mariux.${PKGREVISION} +}