From: Franck Bui-Huu <vagabon.xyz@gmail.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: vagabon.xyz@gmail.com, ralf@linux-mips.org, ths@networkno.de,
linux-mips@linux-mips.org, fbuihuu@gmail.com
Subject: Re: [PATCH 6/7] setup.c: clean up initrd related code
Date: Thu, 19 Oct 2006 12:51:27 +0200 [thread overview]
Message-ID: <453758AF.2060109@innova-card.com> (raw)
In-Reply-To: <20061019.193050.39153762.nemoto@toshiba-tops.co.jp>
Atsushi Nemoto wrote:
> On Thu, 19 Oct 2006 11:54:09 +0200, Franck Bui-Huu <vagabon.xyz@gmail.com> 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
next prev parent reply other threads:[~2006-10-19 10:51 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-13 12:38 [PATCH 0/7] Get ride of CPHYSADDR() in setup.c [take #2] Franck Bui-Huu
2006-10-13 12:39 ` [PATCH 1/7] page.h: remove __pa() usages Franck Bui-Huu
2006-10-13 16:27 ` Atsushi Nemoto
2006-10-14 9:22 ` Franck Bui-Huu
2006-10-13 12:39 ` [PATCH 2/7] Make __pa() aware of XKPHYS/CKSEG0 address mix for 64 bit kernels Franck Bui-Huu
2006-10-13 16:27 ` Atsushi Nemoto
2006-10-14 8:39 ` Franck Bui-Huu
2006-10-19 4:01 ` Atsushi Nemoto
2006-10-19 6:20 ` Franck Bui-Huu
2006-10-19 6:41 ` Yoichi Yuasa
2006-10-19 7:01 ` Atsushi Nemoto
2006-10-19 7:23 ` Yoichi Yuasa
2006-10-19 7:43 ` Franck Bui-Huu
2006-10-19 7:59 ` Atsushi Nemoto
2006-10-13 12:39 ` [PATCH 3/7] setup.c: get ride of CPHYSADDR() Franck Bui-Huu
2006-10-13 12:39 ` [PATCH 4/7] Introduce __pa_symbol() Franck Bui-Huu
2006-10-13 12:39 ` [PATCH 5/7] setup.c: use __pa_symbol() where needed Franck Bui-Huu
2006-10-13 12:39 ` [PATCH 6/7] setup.c: clean up initrd related code Franck Bui-Huu
2006-10-16 8:03 ` Franck Bui-Huu
2006-10-16 8:10 ` Atsushi Nemoto
2006-10-16 8:48 ` Franck Bui-Huu
2006-10-16 9:07 ` Atsushi Nemoto
2006-10-16 9:54 ` Thiemo Seufer
2006-10-16 10:19 ` Atsushi Nemoto
2006-10-16 14:42 ` Franck Bui-Huu
2006-10-16 14:51 ` Franck Bui-Huu
2006-10-16 9:09 ` Thiemo Seufer
2006-10-16 14:23 ` Franck Bui-Huu
2006-10-16 14:49 ` Franck Bui-Huu
2006-10-19 4:13 ` Atsushi Nemoto
2006-10-19 6:37 ` Franck Bui-Huu
2006-10-19 6:51 ` Atsushi Nemoto
2006-10-19 7:29 ` Franck Bui-Huu
2006-10-19 7:51 ` Atsushi Nemoto
2006-10-19 8:30 ` Franck Bui-Huu
2006-10-19 8:39 ` Franck Bui-Huu
2006-10-19 9:15 ` Atsushi Nemoto
2006-10-19 9:54 ` Franck Bui-Huu
2006-10-19 10:30 ` Atsushi Nemoto
2006-10-19 10:51 ` Franck Bui-Huu [this message]
2006-10-19 11:00 ` Atsushi Nemoto
2006-10-19 11:12 ` Franck Bui-Huu
2006-10-13 12:39 ` [PATCH 7/7] Make free_init_pages() arguments to be physical addresses Franck Bui-Huu
2006-10-13 13:31 ` Franck Bui-Huu
-- strict thread matches above, loose matches on Subject: below --
2006-10-16 16:12 [PATCH 0/7] Get ride of CPHYSADDR() in setup.c [take #3] Franck Bui-Huu
2006-10-16 16:12 ` [PATCH 6/7] setup.c: clean up initrd related code Franck Bui-Huu
2006-10-19 11:19 [PATCH 0/7] Get ride of CPHYSADDR() in setup.c [take #4] Franck Bui-Huu
2006-10-19 11:20 ` [PATCH 6/7] setup.c: clean up initrd related code Franck Bui-Huu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=453758AF.2060109@innova-card.com \
--to=vagabon.xyz@gmail.com \
--cc=anemo@mba.ocn.ne.jp \
--cc=fbuihuu@gmail.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=ths@networkno.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox