From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Fri Nov 06 2009 - 16:21:50 PST
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 -- 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