From: Neal Becker (ndbecker2_at_gmail.com)
Date: Fri Nov 06 2009 - 17:39:25 PST
On Friday 06 November 2009, Paul H. Hargrove wrote: > Alan Woodland wrote: > > 2009/11/2 Alan Woodland <alan.woodland_at_gmail_dot_com>: > >> The attached patch fixes the cause of the missing modules when > >> building on 2.6.31. It doesn't however appear to be the only problem > >> when building for 2.6.31, it's now hitting a #error which I haven't > >> looked at yet. > >> > >> For those that are interested 2.6.31 no longer sets $(TOPDIR) in > >> kbuild invocations, so trying to work out if we're using kbuild based > >> on that fails. I switched to $(obj), I couldn't think of anything > >> better to use, but I'm sure there is a more appropriate variable to > >> use instead. > >> > >> When I've had more of a look I might post another patch here to fix > >> the remaining problems. > > > > Two problems seem to exist with 2.6.31: > > - find_task_by_pid_type_ns no longer exists, or isn't visible at all. > > - find_task_by_pid_ns test passes, with a warning, but dmesg reports > > find_task_by_pid_ns not found at modprobe time. I think this might be > > a mistake in the kernel headers, but it's still in System.map, so we > > can work around this maybe. > > > > This is the commit log: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit > >;h=17f98dcf6010a1cfd25d179fd0ce77d3dc2685c3 > > > > I'm slightly out of my depth here now, I tried to hack a work around, > > but didn't succeed yet. > > > > Alan > > W/o trying for myself I can't speculate too deeply on > find_task_by_pid_type_ns(), but the git commit log above seems to > indicate that some functionality has been removed from the kernel. I > don't yet know how it relates to what BLCR is actually doing w/ > find_task_by_pid_type_ns(). > > The commit log also says > "remove the exports for find_task_by_pid_ns...." So, I suggest that the > following addition to BLCR's configure.in may be the right fix for that > one (since Alan reports that the symbol is still in System.map): > > --- configure.ac 23 Aug 2009 22:58:26 -0000 1.410.2.10 > +++ configure.ac 7 Nov 2009 00:15:14 -0000 > @@ -1225,6 +1225,7 @@ CR_CHECK_KERNEL_CALL([find_task_by_pid_n > if test -z "${HAVE_FIND_TASK_BY_PID}${HAVE_FIND_TASK_BY_PID_NS}"; then > CR_BAD_KERNEL([unable to determine how to map pid_nr -> struct task]) > fi > +CR_FIND_KSYM([find_task_by_pid_ns],[CODE]) > > CR_CHECK_KERNEL_CALL([find_task_by_pid_type],[#include <linux/sched.h>]) > CR_CHECK_KERNEL_CALL([find_task_by_pid_type_ns],[#include > <linux/sched.h>]) > > > However, it is also possible that BCLR needs to finally move move to the > vpid interfaces. > > -Paul > Thanks, but this patch didn't help. checking kernel for nameidata.path... no checking kernel for nameidata.dentry... no ====================================================================== Please review the following configuration information: Kernel source directory = /usr/src/kernels/2.6.31.5-122.fc12.ppc Kernel build directory = /usr/src/kernels/2.6.31.5-122.fc12.ppc Kernel symbol table = /usr/src/kernels/2.6.31.5-122.fc12.ppc/System.map Kernel version probed from kernel build = 2.6.31.5-122.fc12.ppc Kernel running currently = 2.6.30.9-90.fc11.ppc64 ====================================================================== configure: error: Unable to use kernel 2.6.31.5-122.fc12.ppc - unable to determine composition of struct nameidata Build log here: http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/5496- blcr-kmod-0.8.1-3.fc12.12/ppc/build.log I don't have any local system configured with this kernel, so it's not easy for me to debug.