On 3/16/07, Horms <[EMAIL PROTECTED]> wrote: > On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote: > > On Thu, Mar 15, 2007 at 12:22:57PM +0000, Ian Campbell wrote: > > > On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote: > > > > > > But I think changing this macro might run into issues. It is > > > > > > being used at few places in kernel, for example while loading > > > > > > module. This will essentially mean that we allow loading 64bit > > > > > > x86_64 modules on 32bit i386 systems? > > > > > > Yes, not sure how I missed that fact... > > > > > > > Kexec will also not allow loading an x86_64 kernel on a 32bit machine. > > > > > > For crash kernel only or for regular kexec too? > > > > > > > I think for both. One of the possible reasons I think is that one never > > knows is underlying machine has got 64bit extensions or not. So even if > > we load the kernel it will never boot. Secondly, we might not be able to > > handle 64bit address in 32bit kernel/user space? > > Perhaps I am miss-understanding what you are saying, but I do > recally kexecing from 32->64 and 64->32 bit kernels on x86_64 hardware. > I can run these checks again if it helps.
I recall kexecing a bzImage for x86_64 on i386, but I'm not 100% sure. I think it worked because the bzImage loader code was regular 32 bit x86 code, but that may be wrong as well. > Won't the above change break non i386 archtectures as > vmcore_elf_check_arch_cross isn't defined for them? Right. And maybe it's a good idea to make sure that this feature is actually supported by kexec-tools before adding code to the kernel? My gut feeling about this is that you are begging for trouble. The kexec/kdump solution is fragile just by itself, and trying to go between architectures is just going to be painful. / magnus _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
