We probably should add a flag for those, but that is more of a boot_flag...
Yinghai Lu <[email protected]> wrote: >On Mon, Nov 19, 2012 at 3:13 PM, H. Peter Anvin <[email protected]> wrote: >> On 11/19/2012 02:53 PM, Yinghai Lu wrote: >>> >>> any other field, in header struct field that we can use to tell >>> bzImage could be used that >>> 0x200 directly? >>> >>> hardware_subarch? >>> >> >> There isn't one... this dates back all the way to the original x86-64 >> kernels. >> >> Are you asking if we can tell this is a 64-bit kernel (as opposed to >a >> 32-bit kernel, which obviously doesn't have a 64-bit entry point)? >> Unfortunately there isn't an intentional one that I know of. There >> might be an accidental such indicator, but we'd have to go back to >look >> at 8+ years of kernels. We can't even rely on a jmp instruction at >the >> address... > >So we could add one field to tell that bzImage could be used with >64bit? > >current in this patchset, I added > >0268/4 2.12+ ext_ramdisk_image ramdisk_image 32 bits >026C/4 2.12+ ext_ramdisk_size ramdisk_size high 32 bits >0270/4 2.12+ code64_start_offset 64bit start offset for bzImage >0274/4 2.12+ ext_cmd_line_ptr cmd_line_ptr high 32 bits > >so you don't like code64_start_offset. > >how about other three? > >can we use bits 31 of hardware_subarch to tell it is bzImage for >x86_64? > >Thanks > >Yinghai -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- 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/
