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
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 BSS segment of
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
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 as that of
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,
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
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 x86_64.
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,
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
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
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
12 matches
Mail list logo
