From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Fri Nov 06 2009 - 17:59:59 PST
Neal Becker wrote: > 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. > I have local machines for all BLCR-supported architectures, but none has a 2.6.31 kernel yet. However, I doubt that anything in struct nameidata is arch-specific. When I am able to return my attention to this in early December, getting BLCR updated for the then current kernels will be one of my top priorities. In the meantime, I'll continue to try to take occasional looks at one small problem at a time. I really do appreciate that Alan and Neal are both trying to make progress to support newer kernels in their respective distributions and regret that I cannot be more helpful. -Paul -- Paul H. Hargrove PHHargrove_at_lbl_dot_gov Future Technologies Group Tel: +1-510-495-2352 HPC Research Department Fax: +1-510-486-6900 Lawrence Berkeley National Laboratory