On Thu, Jan 31, 2008 at 06:12:34PM +0900, Paul Mundt wrote: > kernel/ksysfs.c seems to be a random dumping group for misc globals > that the rest of the tree depend on. This has caused problems with > exports in the past when sysfs is disabled, which can already be > observed in commit-id 51107301b629640f9ab76fe23bf385e187b9ac29. > > The latest one is the kernel_kobj usage, which presently results in: > > fs/built-in.o: In function `debugfs_init': > inode.c:(.init.text+0xc34): undefined reference to `kernel_kobj' > make: *** [.tmp_vmlinux1] Error 1 > > kernel/ksysfs.c itself at this point only contains globals and some > basic sysfs initialization, the sysfs initialization code is optimized > out when we build with sysfs disabled. Given that, it's easier to just > build in unconditionally, rather than trying to find some other random > place to dump and initialize the globals. > > Additionally, the current trend seems to be decoupling of kobjects from > sysfs, in which case it still makes sense to perform the kernel_kobj > initialization that happens here even if sysfs is disabled, as > lib/kobject.o is built-in unconditionally. > > Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
I'll take this, it looks right, but I don't think it fixes the kernel_kobj problem, that shows up in a number of other places too. I'm working on fixing that up properly right now, give me a day, I'm doing builds with tons of different kernel options :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
