Huang, Ying wrote:
> Hi, Peter,
>
> On Wed, 2007-09-19 at 09:04 -0700, H. Peter Anvin wrote:
>> Huang, Ying wrote:
>>> Known Issues:
>>>
>>> 1. Where is safe to place the linked list of setup_data?
>>> Because the length of the linked list of setup_data is variable, it
>>> can not be copied into B
Hi, Peter,
On Wed, 2007-09-19 at 09:04 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> >
> > Known Issues:
> >
> > 1. Where is safe to place the linked list of setup_data?
> > Because the length of the linked list of setup_data is variable, it
> > can not be copied into BSS segment of kernel
Jeremy Fitzhardinge wrote:
>
> Do you actually need a linked list of data? This is similar to the
> changes to bzImage to support booting bzImage a paravirt environment,
> but I just proposed a pointer to a single info structure, along with a
> field to identify the boot environment (ie, native/l
Huang, Ying wrote:
> This patch add a field of 64-bit physical pointer to NULL terminated
> single linked list of struct setup_data to real-mode kernel
> header. This is used as a more extensible boot parameters passing
> mechanism.
>
> This patch has been tested against 2.6.23-rc6-mm1 kernel on x8
Huang, Ying wrote:
>
> Known Issues:
>
> 1. Where is safe to place the linked list of setup_data?
> Because the length of the linked list of setup_data is variable, it
> can not be copied into BSS segment of kernel as that of "zero
> page". We must find a safe place for it, where it will not be
>
This patch add a field of 64-bit physical pointer to NULL terminated
single linked list of struct setup_data to real-mode kernel
header. This is used as a more extensible boot parameters passing
mechanism.
This patch has been tested against 2.6.23-rc6-mm1 kernel on x86_64. It
is based on the propo
6 matches
Mail list logo
