> > > I don't get this patch - do we still need > > > packages/kernel/serengeti_cheetah-kernel-x86_64.mk? kernel.inc does > all > > > the heavy lifting now. Or not? > > > > My understanding is that packages/kernel/serengeti_cheetah-kernel- > x86_64.mk > > sets the kernel version, url, config file, etc. kernel.inc builds the > > kernel you specified in the .mk file. > > is there enough different about it that we need two files? I was planning > on setting the configuration information in the platform configuration: > > ifeq ($(CONFIG_TARGET_64BIT),y) > KERNEL_VERSION=2.6.22.2
> KERNEL_MK=$(PACKAGE_DIR)/kernel/serengeti_cheetah-kernel-x86_64.mk So do you want to remove this line if you only want one .mk file? Do we want to make a new variable CONFIG_TINY that downloads the tiny patches for the KERNEL_VERSION we've selected? Once we go that far is there any reason to have board-specific .mk files for the kernel at all? That would be nice from my perspective (many of the boards can/do use the same kernel versions), but it is a major change. Myles > KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah- > x86_64 > BUSYBOX_CONFIG=defconfig-serengeti_cheetah-x86_64 > UCLIBC_VER=0.9.29 > UCLIBC_CONFIG=defconfig-x86_64 > else > KERNEL_VERSION=2.6.20.2 > KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah > UCLIBC_VER=0.9.28 > endif > > That would save us having to have mutiple copies of the kernel make files > for 32 and 64 bit. Is this bad? > > Jordan > > > The other two files are Config.lb files depending on which payload you > want > > to use. > > Yes - those made sense to me. > > > > Myles > > > > > > > > Jordan > > > > > > > > > > -- > Jordan Crouse > Systems Software Development Engineer > Advanced Micro Devices, Inc. -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios