lkml.org 
[lkml]   [2010]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] x86: Setup early console as early as possible
On 07/12/2010 11:11 AM, Yinghai Lu wrote:
> On 07/12/2010 11:09 AM, H. Peter Anvin wrote:
>
>> On 07/12/2010 10:44 AM, Cyrill Gorcunov wrote:
>>
>>> Peter, while reviewing this patch I found another nit in
>>> context of early_param usage, so the patch is below. It's
>>> completely trivial. Actually I thought I've already fixed
>>> all early_param cases long ago but this one somehow sneaked ;)
>>>
>>> Anyway, Yinghai, Peter,
>>>
>>> I'm not sure but can't we use some boot_param "pad" field for
>>> "being copied" flag instead of new variable? There is a case
>>> when boot_param is used as __initdata and I'm not sure we clear
>>> this section explicitly.
>>>
>>>
>> Actually, even better would be to simply use boot_params.hdr.version,
>> which will never be zero.
>>
> Jeremy,
>
> any reason that xen cat not use x86_64_start_kernel directly?
>

As I remember it, I split x86_64_start_kernel into two pieces, one
containing the bits that were awkward with Xen. I don't remember which
were the problematic parts, but it all looks pretty tricky. Specifically:

* Xen will pre-clear the bss, so that's not necessary
* we don't go via head, so cleanup_highmap isn't either
* PV domains don't have an IDT available to them, or any of their
associated structures

So the whole thing looks at best reundant, and at worst has the
potential for causing subtle damage.

Why do you ask? Does it relate to the early console stuff, or are you
just asking because you're looking at it?

J


\
 
 \ /
  Last update: 2010-07-13 01:01    [W:0.069 / U:1.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site