Atsushi Nemoto wrote: > On Thu, 19 Oct 2006 11:54:09 +0200, Franck Bui-Huu <vagabon.xyz@xxxxxxxxx> wrote: >>> This does not work if PAGE_OFFSET was 0xffffffff80000000 and >>> initrd_start was 0x980000000XXXXXXX :-) >>> >> I think we should terminate this patch pretty quickly because >> it's going to make me mad ;) >> >> How can PAGE_OFFSET be in CKSEG0 segment and initrd_start be >> in XKPHYS ? > > If we passed a XKPHYS address to "rd_start=" option. Bad usage :-) > ok so testing initrd_start against PAGE_OFFSET (instead of XKPHYS) is good check since we catch such bad usages. Do you agree ? >> With the current code we can say: >> >> - If PAGE_OFFSET is in CKSEG0, that means that all kernel >> virtual address must be in CKSEG0. >> - If PAGE_OFFSET is in XKPHYS, that means that _after_ booting >> process all kernel virtual address will be in XKPHYS. But we >> allow CKSEG0 virtual address during boot for the reasons >> we know. >> >> What woud give __pa(initrd_start) in your example ? >> >> __pa(initrd_start) -> 0x980000000XXXXXXX - 0xffffffff80000000 >> >> which is wrong...Does your example come from a real use case ? > > It's wrong indeed. But I can not see good way to handle such terrible > usage. So ... let's ignore it. I'm OK, are you ? > why do we need to handle them anyway ? PAGE_OFFSET in XKPHYS means that the kernel runs in XKPHYS address space. We allow at boot time kernel address to be in CKSEG0 because we have a good reason to handle that. It allows to get a kernel smaller and faster at compile time. PAGE_OFFSET in CKSEG0 means that the kernel runs in CKSEG0 address space. This means also that kernel can't handle XKPHYS address. But how would the kernel get addresses in XKPHYS (except user bad usages) ? Franck
