On Mon, Oct 03, 2005 at 08:30:23PM +0200, Blaisorblade wrote: > The second is that, even if x86_64 uses things such as (from > arch/x86_64/mm/Makefile): > > obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o > hugetlbpage-y = ../../i386/mm/hugetlbpage.o > (because hugetlbpage.o is conditional) > > we could as well do > > subarch-y := ../../$(SUBARCH)/name > (even with foreach)
Err... Kbuild won't know what to do with your subarch-y. The way it works is simple - we are saying that e.g. bitops.o is a multi-part object with only one part, namely ../../i386/lib/bitops.o. Said part is built by the normal Kbuild logics and then we get (dummy) linking, creating bitops.o. > for most things (see arch/x86_64/oprofile/Makefile), and for highmem and > module I'd just do that by hand: > > highmem-y := $(SUBARCH_DIR)/mm/highmem.o > module-y := $(SUBARCH_DIR)/kernel/module.o > > with SUBARCH_DIR defined in arch/um/Makefile. Hrm... That just might be usable, _if_ we never run into modular suckers; in that case we can do the following: ifneq ($(subarch-objs-y),) obj-y += subarch.o subarch-y = $(addprefix ../../$(SUBARCH),$(subarch-objs-y)) endif in arch/um/scripts/Makefile.rules with subarch-y = ..... subarch-$(CONFIG_MODULE) += kernel/module.o etc. in arch/um/sys-.../Makefile The thing is, if we _ever_ need a potentially modular object pulled from the underlying architecture that trick will break. So far we do not and since $(eval...) *is* a vile mess straight from the GNU intestine... ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
