On 5/9/07, Gerd Hoffmann <[EMAIL PROTECTED]> wrote:
Refine SCREEN_INFO sanity check for vgacon initialization.
Checking video mode field only to see whenever SCREEN_INFO is
initialized is not enougth, in some cases it is zero although
a vga card is present. Lets additionally check cols and
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Obviously not, but it was more of a comment on the apparent assumption
> that doing so would be simple.
Reasonable comment then.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
[EMAIL PROTECTED] wrote:
>
> Well in this case things are so very much better then attempting to
> us setup.S it isn't a real option.
>
Obviously not, but it was more of a comment on the apparent assumption
that doing so would be simple.
-hpa
-
To unsubscribe from this list: send the
On 5/9/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
We can look in /proc/ioports and see what has reserved
the video resources. That should give us a reasonable
estimate of the video adapter. We can do an ioctl to
the console and see how many
Gerd Hoffmann <[EMAIL PROTECTED]> writes:
> Hi,
>
>> Since the whole point is to detect the case where we don't have
>> a screen at all it makes sense to check several additional variables
>> and make certain that they are all 0. Agreed?
>
> Like in the attached patch?
Looks good to me.
>
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> yhlu wrote:
>> so the kexec tools need to scan the pci devices list, and find out how
>> to set real_mode.isVGA and orig_video_mode, also need to parse the
>> comand line about vga console.
>
> BTW, welcome to the hell of bypassing setup.
Well in
Hi,
Since the whole point is to detect the case where we don't have
a screen at all it makes sense to check several additional variables
and make certain that they are all 0. Agreed?
Like in the attached patch?
cheers,
Gerd
Refine SCREEN_INFO sanity check for vgacon initialization.
yhlu wrote:
> so the kexec tools need to scan the pci devices list, and find out how
> to set real_mode.isVGA and orig_video_mode, also need to parse the
> comand line about vga console.
BTW, welcome to the hell of bypassing setup.
-hpa
-
To unsubscribe from this list: send the line
yhlu wrote:
so the kexec tools need to scan the pci devices list, and find out how
to set real_mode.isVGA and orig_video_mode, also need to parse the
comand line about vga console.
BTW, welcome to the hell of bypassing setup.
-hpa
-
To unsubscribe from this list: send the line
Hi,
Since the whole point is to detect the case where we don't have
a screen at all it makes sense to check several additional variables
and make certain that they are all 0. Agreed?
Like in the attached patch?
cheers,
Gerd
Refine SCREEN_INFO sanity check for vgacon initialization.
H. Peter Anvin [EMAIL PROTECTED] writes:
yhlu wrote:
so the kexec tools need to scan the pci devices list, and find out how
to set real_mode.isVGA and orig_video_mode, also need to parse the
comand line about vga console.
BTW, welcome to the hell of bypassing setup.
Well in this case
Gerd Hoffmann [EMAIL PROTECTED] writes:
Hi,
Since the whole point is to detect the case where we don't have
a screen at all it makes sense to check several additional variables
and make certain that they are all 0. Agreed?
Like in the attached patch?
Looks good to me.
cheers,
Gerd
On 5/9/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
H. Peter Anvin [EMAIL PROTECTED] writes:
We can look in /proc/ioports and see what has reserved
the video resources. That should give us a reasonable
estimate of the video adapter. We can do an ioctl to
the console and see how many lines
[EMAIL PROTECTED] wrote:
Well in this case things are so very much better then attempting to
us setup.S it isn't a real option.
Obviously not, but it was more of a comment on the apparent assumption
that doing so would be simple.
-hpa
-
To unsubscribe from this list: send the line
H. Peter Anvin [EMAIL PROTECTED] writes:
Obviously not, but it was more of a comment on the apparent assumption
that doing so would be simple.
Reasonable comment then.
Eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
On 5/9/07, Gerd Hoffmann [EMAIL PROTECTED] wrote:
Refine SCREEN_INFO sanity check for vgacon initialization.
Checking video mode field only to see whenever SCREEN_INFO is
initialized is not enougth, in some cases it is zero although
a vga card is present. Lets additionally check cols and
yhlu wrote:
> On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>> H. Peter Anvin wrote:
>> Of course, one could argue that since all of those were obsolete by the
>> time Linux was first created, that it probably doesn't matter and that
>> isVGA == 0 pretty much means the more obvious thing.
On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
H. Peter Anvin wrote:
Of course, one could argue that since all of those were obsolete by the
time Linux was first created, that it probably doesn't matter and that
isVGA == 0 pretty much means the more obvious thing.
MDA/HGC stuck around for
H. Peter Anvin wrote:
> yhlu wrote:
>> On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>>> Since the whole point is to detect the case where we don't have
>>> a screen at all it makes sense to check several additional variables
>>> and make certain that they are all 0. Agreed?
>> need one
yhlu wrote:
> On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> Since the whole point is to detect the case where we don't have
>> a screen at all it makes sense to check several additional variables
>> and make certain that they are all 0. Agreed?
>
> need one good way to find if there
yhlu <[EMAIL PROTECTED]> writes:
> On 5/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote:
>> On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote:
>> This message generally appears if you did not specify --args-linux
>> on kexec command line while loading vmlinux.
>>
> besides elf-x86_64, still need
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Since the whole point is to detect the case where we don't have
a screen at all it makes sense to check several additional variables
and make certain that they are all 0. Agreed?
need one good way to find if there is support vga console.
On 5/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote:
On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote:
This message generally appears if you did not specify --args-linux
on kexec command line while loading vmlinux.
besides elf-x86_64, still need --args-linux to pass sth? but how to
let it
On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote:
> Eric,
>
> i tried to load vmlinux with kexec and got
> Ramdisks not supported with generic elf arguments
>
This message generally appears if you did not specify --args-linux
on kexec command line while loading vmlinux.
Thanks
Vivek
-
To
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> I expect I can find a few more examples where we specify
>> video_cols and video_lines but we use video_mode == 0.
>>
>> Going farther mode 0x00 is a BIOS 40x25 mode. So the patch below is
>> not always safe even if
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
I believe YH is asking how we setup real_mode_data in /sbin/kexec.
pxelinux:
SCREEN_INFO.orig_video_mode = 3
SCREEN_INFO.orig_x = 0
SCREEN_INFO.orig_y = 24
x86_boot_params[] :
: 00 18
Eric W. Biederman wrote:
>
> I expect I can find a few more examples where we specify
> video_cols and video_lines but we use video_mode == 0.
>
> Going farther mode 0x00 is a BIOS 40x25 mode. So the patch below is
> not always safe even if we boot the bzImage. It is just highly
> unlikely
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> yhlu wrote:
>> On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>>> Jeremy Fitzhardinge wrote:
>>> Specifically boot_params.screen_info isn't being properly set up by the
>>> caller.
>>
>> will setup real_mode_data in kexec path?
>
> -ENOPARSE
yhlu wrote:
> On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>> Jeremy Fitzhardinge wrote:
>> Specifically boot_params.screen_info isn't being properly set up by the
>> caller.
>
> will setup real_mode_data in kexec path?
-ENOPARSE
-hpa
-
To unsubscribe from this list: send the
On 5/8/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
Jeremy Fitzhardinge wrote:
Specifically boot_params.screen_info isn't being properly set up by the
caller.
will setup real_mode_data in kexec path?
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Jeremy Fitzhardinge wrote:
>
> Interesting. I haven't really been following this thread, but doesn't
> it mean something isn't being initialized properly if this patch makes a
> difference?
>
Specifically boot_params.screen_info isn't being properly set up by the
caller.
-hpa
-
To
yhlu wrote:
> On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> You might try a git-bisect, or if it is just these patches
>> walking through them one-by-one.
>
> f82af20e1a028e16b9bb11da081fa1148d40fa6a is first bad commit
> commit f82af20e1a028e16b9bb11da081fa1148d40fa6a
> Author: Gerd
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
You might try a git-bisect, or if it is just these patches
walking through them one-by-one.
f82af20e1a028e16b9bb11da081fa1148d40fa6a is first bad commit
commit f82af20e1a028e16b9bb11da081fa1148d40fa6a
Author: Gerd Hoffmann <[EMAIL
yhlu <[EMAIL PROTECTED]> writes:
> Eric,
>
> i tried to load vmlinux with kexec and got
> Ramdisks not supported with generic elf arguments
>
> So i use mkelfImage with my patch ( convert elf64 to elf32) to make
> another elf32. and loaded with kexec and can not get vga console too.
> ---serial
the mkelfImage 2.7 patch is at
https://lists.linux-foundation.org/pipermail/fastboot/attachments/20061108/009064a6/mkelfImage_2.7_amd64_1108-0001.obj
YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Eric,
i tried to load vmlinux with kexec and got
Ramdisks not supported with generic elf arguments
So i use mkelfImage with my patch ( convert elf64 to elf32) to make
another elf32. and loaded with kexec and can not get vga console too.
---serial console works well.
the mkelfImage 2.7 patch is
On 5/8/07, Vivek Goyal <[EMAIL PROTECTED]> wrote:
setup.S is never executed while doing kexec (unless somebody chooses to
do a real mode entry) and these patches don't change this beahviour.
Tomorrow I will test VGA behaviour on my machine. Are you using some
special frame buffer mode etc?
I
On 5/8/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Yes. setup.S has always been skipped by bzImage via the kexec path
unless you explicitly tell /sbin/kexec to use the 16bit entry point.
Is not having a VGA console a new thing, or it something you just noticed?
Eric
before the
On Tue, May 08, 2007 at 09:41:09AM -0700, yhlu wrote:
> On 5/2/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >Vivek Goyal <[EMAIL PROTECTED]> writes:
> >
> >> On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
> >>> Jeremy Fitzhardinge wrote:
> >>> >
> >>> > So the bzImage
yhlu <[EMAIL PROTECTED]> writes:
> Eric,
>
> With the latest change that make vmlinux to be elf64 and make bzImage
> do switch to 64bit long mode, the kernel started via kexec can not get
> VGA console. but the serial console works well. I wonder if the
> setup.S is skipped in bzImage via kexec
On 5/2/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Vivek Goyal <[EMAIL PROTECTED]> writes:
> On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
>> Jeremy Fitzhardinge wrote:
>> >
>> > So the bzImage structure is currently:
>> >
>> >1. old-style boot sector
>> >2.
On 5/2/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
So the bzImage structure is currently:
1. old-style boot sector
2. old-style boot info,
yhlu [EMAIL PROTECTED] writes:
Eric,
With the latest change that make vmlinux to be elf64 and make bzImage
do switch to 64bit long mode, the kernel started via kexec can not get
VGA console. but the serial console works well. I wonder if the
setup.S is skipped in bzImage via kexec path.
On Tue, May 08, 2007 at 09:41:09AM -0700, yhlu wrote:
On 5/2/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
So the bzImage structure is currently:
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Yes. setup.S has always been skipped by bzImage via the kexec path
unless you explicitly tell /sbin/kexec to use the 16bit entry point.
Is not having a VGA console a new thing, or it something you just noticed?
Eric
before the changes,
On 5/8/07, Vivek Goyal [EMAIL PROTECTED] wrote:
setup.S is never executed while doing kexec (unless somebody chooses to
do a real mode entry) and these patches don't change this beahviour.
Tomorrow I will test VGA behaviour on my machine. Are you using some
special frame buffer mode etc?
I
Eric,
i tried to load vmlinux with kexec and got
Ramdisks not supported with generic elf arguments
So i use mkelfImage with my patch ( convert elf64 to elf32) to make
another elf32. and loaded with kexec and can not get vga console too.
---serial console works well.
the mkelfImage 2.7 patch is
the mkelfImage 2.7 patch is at
https://lists.linux-foundation.org/pipermail/fastboot/attachments/20061108/009064a6/mkelfImage_2.7_amd64_1108-0001.obj
YH
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
yhlu [EMAIL PROTECTED] writes:
Eric,
i tried to load vmlinux with kexec and got
Ramdisks not supported with generic elf arguments
So i use mkelfImage with my patch ( convert elf64 to elf32) to make
another elf32. and loaded with kexec and can not get vga console too.
---serial console
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
You might try a git-bisect, or if it is just these patches
walking through them one-by-one.
f82af20e1a028e16b9bb11da081fa1148d40fa6a is first bad commit
commit f82af20e1a028e16b9bb11da081fa1148d40fa6a
Author: Gerd Hoffmann [EMAIL PROTECTED]
yhlu wrote:
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
You might try a git-bisect, or if it is just these patches
walking through them one-by-one.
f82af20e1a028e16b9bb11da081fa1148d40fa6a is first bad commit
commit f82af20e1a028e16b9bb11da081fa1148d40fa6a
Author: Gerd Hoffmann
Jeremy Fitzhardinge wrote:
Interesting. I haven't really been following this thread, but doesn't
it mean something isn't being initialized properly if this patch makes a
difference?
Specifically boot_params.screen_info isn't being properly set up by the
caller.
-hpa
-
To
On 5/8/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Jeremy Fitzhardinge wrote:
Specifically boot_params.screen_info isn't being properly set up by the
caller.
will setup real_mode_data in kexec path?
YH
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
yhlu wrote:
On 5/8/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Jeremy Fitzhardinge wrote:
Specifically boot_params.screen_info isn't being properly set up by the
caller.
will setup real_mode_data in kexec path?
-ENOPARSE
-hpa
-
To unsubscribe from this list: send the line
H. Peter Anvin [EMAIL PROTECTED] writes:
yhlu wrote:
On 5/8/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Jeremy Fitzhardinge wrote:
Specifically boot_params.screen_info isn't being properly set up by the
caller.
will setup real_mode_data in kexec path?
-ENOPARSE
I believe YH is asking
Eric W. Biederman wrote:
I expect I can find a few more examples where we specify
video_cols and video_lines but we use video_mode == 0.
Going farther mode 0x00 is a BIOS 40x25 mode. So the patch below is
not always safe even if we boot the bzImage. It is just highly
unlikely anyone
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
H. Peter Anvin [EMAIL PROTECTED] writes:
I believe YH is asking how we setup real_mode_data in /sbin/kexec.
pxelinux:
SCREEN_INFO.orig_video_mode = 3
SCREEN_INFO.orig_x = 0
SCREEN_INFO.orig_y = 24
x86_boot_params[] :
: 00 18 ff ff
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
I expect I can find a few more examples where we specify
video_cols and video_lines but we use video_mode == 0.
Going farther mode 0x00 is a BIOS 40x25 mode. So the patch below is
not always safe even if we boot the
On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote:
Eric,
i tried to load vmlinux with kexec and got
Ramdisks not supported with generic elf arguments
This message generally appears if you did not specify --args-linux
on kexec command line while loading vmlinux.
Thanks
Vivek
-
To
On 5/8/07, Vivek Goyal [EMAIL PROTECTED] wrote:
On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote:
This message generally appears if you did not specify --args-linux
on kexec command line while loading vmlinux.
besides elf-x86_64, still need --args-linux to pass sth? but how to
let it load
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Since the whole point is to detect the case where we don't have
a screen at all it makes sense to check several additional variables
and make certain that they are all 0. Agreed?
need one good way to find if there is support vga console.
yhlu [EMAIL PROTECTED] writes:
On 5/8/07, Vivek Goyal [EMAIL PROTECTED] wrote:
On Tue, May 08, 2007 at 11:51:35AM -0700, yhlu wrote:
This message generally appears if you did not specify --args-linux
on kexec command line while loading vmlinux.
besides elf-x86_64, still need --args-linux to
yhlu wrote:
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Since the whole point is to detect the case where we don't have
a screen at all it makes sense to check several additional variables
and make certain that they are all 0. Agreed?
need one good way to find if there is support
H. Peter Anvin wrote:
yhlu wrote:
On 5/8/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Since the whole point is to detect the case where we don't have
a screen at all it makes sense to check several additional variables
and make certain that they are all 0. Agreed?
need one good way to
On 5/8/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
H. Peter Anvin wrote:
Of course, one could argue that since all of those were obsolete by the
time Linux was first created, that it probably doesn't matter and that
isVGA == 0 pretty much means the more obvious thing.
MDA/HGC stuck around for
yhlu wrote:
On 5/8/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
H. Peter Anvin wrote:
Of course, one could argue that since all of those were obsolete by the
time Linux was first created, that it probably doesn't matter and that
isVGA == 0 pretty much means the more obvious thing.
MDA/HGC
Eric W. Biederman wrote:
> Yes. I guess in this context, I am generally for building the ELF
> headers by hand instead of with a linker script, because then we
> know exactly what is happening and can ensure everything is just so.
>
Yes, it seems easiest - particularly given how flaky
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> OK, whatever you think will work. But I do think it should be a proper
> ELF file with a correct magic number, so that you can just point an ELF
> file parser at it and have it work (which means, of course, that all the
> file offsets are offsets
Eric W. Biederman wrote:
> Vivek Goyal <[EMAIL PROTECTED]> writes:
>
>
>> On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
>>
>>> Jeremy Fitzhardinge wrote:
>>>
So the bzImage structure is currently:
1. old-style boot sector
2. old-style boot
Vivek Goyal <[EMAIL PROTECTED]> writes:
> On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
>> Jeremy Fitzhardinge wrote:
>> >
>> > So the bzImage structure is currently:
>> >
>> >1. old-style boot sector
>> >2. old-style boot info, followed by 0xaa55 at the end of the
Vivek Goyal [EMAIL PROTECTED] writes:
On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
So the bzImage structure is currently:
1. old-style boot sector
2. old-style boot info, followed by 0xaa55 at the end of the sector
3. the HdrS
Eric W. Biederman wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
So the bzImage structure is currently:
1. old-style boot sector
2. old-style boot info, followed by 0xaa55 at
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
OK, whatever you think will work. But I do think it should be a proper
ELF file with a correct magic number, so that you can just point an ELF
file parser at it and have it work (which means, of course, that all the
file offsets are offsets from
Eric W. Biederman wrote:
Yes. I guess in this context, I am generally for building the ELF
headers by hand instead of with a linker script, because then we
know exactly what is happening and can ensure everything is just so.
Yes, it seems easiest - particularly given how flaky binutils
On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
> >
> > So the bzImage structure is currently:
> >
> >1. old-style boot sector
> >2. old-style boot info, followed by 0xaa55 at the end of the sector
> >3. the HdrS boot param block
> >4.
On Wed, 2007-05-02 at 14:09 -0700, H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
> >
> > Hm, that's unfortunate. How about an ELF file wrapped in some other
> > container, so that we can easily extract a properly formed ELF file?
> >
>
> Effectively the same thing as changing the magic
H. Peter Anvin wrote:
> I don't know if that would break any programs that are currently
> bypassing the setup. The existing setup protocol definitely allows
> invoking an entry point which isn't 0x10 (rather, the 32-bit
> entrypoint is defined by code32_start); I'm not sure how Eric's
>
Jeremy Fitzhardinge wrote:
>
> So the bzImage structure is currently:
>
>1. old-style boot sector
>2. old-style boot info, followed by 0xaa55 at the end of the sector
>3. the HdrS boot param block
>4. setup.S boot code
>5. the self-decompressing kernel
>
> If we make 5
H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>
>> Hm, that's unfortunate. How about an ELF file wrapped in some other
>> container, so that we can easily extract a properly formed ELF file?
>>
>>
>
> Effectively the same thing as changing the magic number. Note that the
> format
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> So we won't do this casually and if it there are real problems we will
>> remove the ELF magic number.
>>
>
> I think we can use ELF-compatible format just fine, but it would make
> more sense to use a non-ELF magic
Eric W. Biederman wrote:
>
> So we won't do this casually and if it there are real problems we will
> remove the ELF magic number.
>
I think we can use ELF-compatible format just fine, but it would make
more sense to use a non-ELF magic number from the start, instead of
signalling it with a
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Jeremy Fitzhardinge wrote:
>>
>> True. But the plan is already to make bzImage an ELF file, so notes
>> would seem to be the best option. At worst, it could be ELF notes
>> wrapped in some other container, but that's not pretty.
>>
>
> It's not
Jeremy Fitzhardinge wrote:
>
> Hm, that's unfortunate. How about an ELF file wrapped in some other
> container, so that we can easily extract a properly formed ELF file?
>
Effectively the same thing as changing the magic number. Note that the
format for bzImage is pretty rigid, and it would
H. Peter Anvin wrote:
> Jeremy Fitzhardinge wrote:
>
>> True. But the plan is already to make bzImage an ELF file, so notes
>> would seem to be the best option. At worst, it could be ELF notes
>> wrapped in some other container, but that's not pretty.
>>
>>
>
> It's not going to happen.
Jeremy Fitzhardinge wrote:
>
> True. But the plan is already to make bzImage an ELF file, so notes
> would seem to be the best option. At worst, it could be ELF notes
> wrapped in some other container, but that's not pretty.
>
It's not going to happen. Too many boot loaders make assumptions
Gerd Hoffmann wrote:
> Doesn't need to be ELF notes. The current (3.0.5+) domain builder has
> pluggable binary parsers. Right now there are two: ELF (obviously
> ...) and binary (with a multiboot-like header). Filling the
> informations such as virt_base is a function of the parser, so when
>
Jeremy Fitzhardinge wrote:
Eric W. Biederman wrote:
I have several ideas on how we can make this work but first I have to
ask what is it that you are trying to accomplish?
The requirements are:
1. the domain builder needs to get various information about the
guest kernel by
Jeremy Fitzhardinge wrote:
Eric W. Biederman wrote:
I have several ideas on how we can make this work but first I have to
ask what is it that you are trying to accomplish?
The requirements are:
1. the domain builder needs to get various information about the
guest kernel by
Gerd Hoffmann wrote:
Doesn't need to be ELF notes. The current (3.0.5+) domain builder has
pluggable binary parsers. Right now there are two: ELF (obviously
...) and binary (with a multiboot-like header). Filling the
informations such as virt_base is a function of the parser, so when
Jeremy Fitzhardinge wrote:
True. But the plan is already to make bzImage an ELF file, so notes
would seem to be the best option. At worst, it could be ELF notes
wrapped in some other container, but that's not pretty.
It's not going to happen. Too many boot loaders make assumptions about
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
True. But the plan is already to make bzImage an ELF file, so notes
would seem to be the best option. At worst, it could be ELF notes
wrapped in some other container, but that's not pretty.
It's not going to happen. Too many boot
Jeremy Fitzhardinge wrote:
Hm, that's unfortunate. How about an ELF file wrapped in some other
container, so that we can easily extract a properly formed ELF file?
Effectively the same thing as changing the magic number. Note that the
format for bzImage is pretty rigid, and it would be
H. Peter Anvin [EMAIL PROTECTED] writes:
Jeremy Fitzhardinge wrote:
True. But the plan is already to make bzImage an ELF file, so notes
would seem to be the best option. At worst, it could be ELF notes
wrapped in some other container, but that's not pretty.
It's not going to happen.
Eric W. Biederman wrote:
So we won't do this casually and if it there are real problems we will
remove the ELF magic number.
I think we can use ELF-compatible format just fine, but it would make
more sense to use a non-ELF magic number from the start, instead of
signalling it with a note.
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
So we won't do this casually and if it there are real problems we will
remove the ELF magic number.
I think we can use ELF-compatible format just fine, but it would make
more sense to use a non-ELF magic number from the
H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
Hm, that's unfortunate. How about an ELF file wrapped in some other
container, so that we can easily extract a properly formed ELF file?
Effectively the same thing as changing the magic number. Note that the
format for bzImage is
Jeremy Fitzhardinge wrote:
So the bzImage structure is currently:
1. old-style boot sector
2. old-style boot info, followed by 0xaa55 at the end of the sector
3. the HdrS boot param block
4. setup.S boot code
5. the self-decompressing kernel
If we make 5 actually an ELF
H. Peter Anvin wrote:
I don't know if that would break any programs that are currently
bypassing the setup. The existing setup protocol definitely allows
invoking an entry point which isn't 0x10 (rather, the 32-bit
entrypoint is defined by code32_start); I'm not sure how Eric's
On Wed, 2007-05-02 at 14:09 -0700, H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
Hm, that's unfortunate. How about an ELF file wrapped in some other
container, so that we can easily extract a properly formed ELF file?
Effectively the same thing as changing the magic number. Note
On Wed, May 02, 2007 at 02:59:11PM -0700, H. Peter Anvin wrote:
Jeremy Fitzhardinge wrote:
So the bzImage structure is currently:
1. old-style boot sector
2. old-style boot info, followed by 0xaa55 at the end of the sector
3. the HdrS boot param block
4. setup.S boot
1 - 100 of 176 matches
Mail list logo
