"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> With ELF we get a single file format that works on multiple
>> architectures and for multiple OS-s, with well understood rules. This
>> allows for a broader audience who can review and maintain the code.
>> In addition
Eric W. Biederman wrote:
With ELF we get a single file format that works on multiple
architectures and for multiple OS-s, with well understood rules. This
allows for a broader audience who can review and maintain the code.
In addition to the real possibility of multi-architecture or multi-os
--- "Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> What I was thinking is that in the not we place the physical address
> and length that we load the real mode code at. My assumption being
> that we have marked the real mode code __init or the equivalent,
> so we always load and just ignore it
Etienne Lorrain <[EMAIL PROTECTED]> writes:
> --- "Eric W. Biederman" wrote:
>> So I really don't care if we move whole real mode section into a note
>> or if we just put a pointer to it into a note. What is important is
>> that we use a note to find it.
>
> Well, we can advertise by a note the
--- "Eric W. Biederman" wrote:
> So I really don't care if we move whole real mode section into a note
> or if we just put a pointer to it into a note. What is important is
> that we use a note to find it.
Well, we can advertise by a note the section number or the section
name which contains
--- Eric W. Biederman wrote:
So I really don't care if we move whole real mode section into a note
or if we just put a pointer to it into a note. What is important is
that we use a note to find it.
Well, we can advertise by a note the section number or the section
name which contains the
Etienne Lorrain [EMAIL PROTECTED] writes:
--- Eric W. Biederman wrote:
So I really don't care if we move whole real mode section into a note
or if we just put a pointer to it into a note. What is important is
that we use a note to find it.
Well, we can advertise by a note the section
--- Eric W. Biederman [EMAIL PROTECTED] wrote:
What I was thinking is that in the not we place the physical address
and length that we load the real mode code at. My assumption being
that we have marked the real mode code __init or the equivalent,
so we always load and just ignore it later
Eric W. Biederman wrote:
With ELF we get a single file format that works on multiple
architectures and for multiple OS-s, with well understood rules. This
allows for a broader audience who can review and maintain the code.
In addition to the real possibility of multi-architecture or multi-os
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
With ELF we get a single file format that works on multiple
architectures and for multiple OS-s, with well understood rules. This
allows for a broader audience who can review and maintain the code.
In addition to the real
Etienne Lorrain <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Etienne Lorrain writes:
>> > Well, a self relocating image cannot be an ELF file because the code
>> > to relocate the ELF cannot be executed at the wrong place.
>> > If relocation is needed, I would better like not to
Eric W. Biederman wrote:
> Etienne Lorrain writes:
> > Well, a self relocating image cannot be an ELF file because the code
> > to relocate the ELF cannot be executed at the wrong place.
> > If relocation is needed, I would better like not to link vmlinux at a
> > fixed address first. In fact
Eric W. Biederman wrote:
Etienne Lorrain writes:
Well, a self relocating image cannot be an ELF file because the code
to relocate the ELF cannot be executed at the wrong place.
If relocation is needed, I would better like not to link vmlinux at a
fixed address first. In fact I wonder
Etienne Lorrain [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Etienne Lorrain writes:
Well, a self relocating image cannot be an ELF file because the code
to relocate the ELF cannot be executed at the wrong place.
If relocation is needed, I would better like not to link vmlinux
Etienne Lorrain <[EMAIL PROTECTED]> writes:
> Well, a self relocating image cannot be an ELF file because the code
> to relocate the ELF cannot be executed at the wrong place.
> If relocation is needed, I would better like not to link vmlinux at a
> fixed address first. In fact I wonder if
--- Vivek Goyal <[EMAIL PROTECTED]> wrote:
> No, as of today, kexec does not relocate vmlinux. At compilation time,
> vmlinux is compiled for a fixed address and vmlinux is loaded at that
> address. This compile address can be controlled with CONFIG_PHYSICAL_START,
> as you already mentioned in
--- Vivek Goyal [EMAIL PROTECTED] wrote:
No, as of today, kexec does not relocate vmlinux. At compilation time,
vmlinux is compiled for a fixed address and vmlinux is loaded at that
address. This compile address can be controlled with CONFIG_PHYSICAL_START,
as you already mentioned in your
Etienne Lorrain [EMAIL PROTECTED] writes:
Well, a self relocating image cannot be an ELF file because the code
to relocate the ELF cannot be executed at the wrong place.
If relocation is needed, I would better like not to link vmlinux at a
fixed address first. In fact I wonder if we are
On Thu, Feb 08, 2007 at 01:10:58PM +, Etienne Lorrain wrote:
> > > I assume you care about this ELF header because you are also a user of
> > > the ELF file vmlinux, aren't you?
> >
> > Yes I am. I use kexec boot loader which has capability to load ELF kernel
> > images (vmlinux). That's why
> > I assume you care about this ELF header because you are also a user of
> > the ELF file vmlinux, aren't you?
>
> Yes I am. I use kexec boot loader which has capability to load ELF kernel
> images (vmlinux). That's why I am concerned about linking real mode code
> in vmlinux as for kdump case
Vivek Goyal <[EMAIL PROTECTED]> writes:
> Kexec as a boot loader allows to load both ELF vmlinux file or bzImage.
> Hence for kdump, a user got the flexibility to either use vmlinux or
> bzImage for dump captruing purposes. Hence I am concerned about both.
>
> If real mode code is linked with
On Thu, Feb 08, 2007 at 09:48:31AM +, Etienne Lorrain wrote:
> Vivek Goyal wrote:
> > > Etienne Lorrain wrote:
> > > Yes, any PT_LOAD below 64 Kbytes can only be real mode, and real-mode
> > > cannot be loaded higher, and cannot be bigger than 640 Kbytes, anything
> > > different (like with
Etienne Lorrain <[EMAIL PROTECTED]> writes:
>> Currently relocation information is extracted from vmlinux and packed in
>> final bzImage after some processing. After execution of real mode code
>> and once the image is decompressed, all the relocations are performed and
>> then control is
Vivek Goyal wrote:
> > Etienne Lorrain wrote:
> > Yes, any PT_LOAD below 64 Kbytes can only be real mode, and real-mode
> > cannot be loaded higher, and cannot be bigger than 640 Kbytes, anything
> > different (like with virtual address at 0xC000) is Linux protected mode.
> > Considering the
Vivek Goyal wrote:
Etienne Lorrain wrote:
Yes, any PT_LOAD below 64 Kbytes can only be real mode, and real-mode
cannot be loaded higher, and cannot be bigger than 640 Kbytes, anything
different (like with virtual address at 0xC000) is Linux protected mode.
Considering the linker
Etienne Lorrain [EMAIL PROTECTED] writes:
Currently relocation information is extracted from vmlinux and packed in
final bzImage after some processing. After execution of real mode code
and once the image is decompressed, all the relocations are performed and
then control is transferred to
On Thu, Feb 08, 2007 at 09:48:31AM +, Etienne Lorrain wrote:
Vivek Goyal wrote:
Etienne Lorrain wrote:
Yes, any PT_LOAD below 64 Kbytes can only be real mode, and real-mode
cannot be loaded higher, and cannot be bigger than 640 Kbytes, anything
different (like with virtual
Vivek Goyal [EMAIL PROTECTED] writes:
Kexec as a boot loader allows to load both ELF vmlinux file or bzImage.
Hence for kdump, a user got the flexibility to either use vmlinux or
bzImage for dump captruing purposes. Hence I am concerned about both.
If real mode code is linked with vmlinux,
I assume you care about this ELF header because you are also a user of
the ELF file vmlinux, aren't you?
Yes I am. I use kexec boot loader which has capability to load ELF kernel
images (vmlinux). That's why I am concerned about linking real mode code
in vmlinux as for kdump case I shall
On Thu, Feb 08, 2007 at 01:10:58PM +, Etienne Lorrain wrote:
I assume you care about this ELF header because you are also a user of
the ELF file vmlinux, aren't you?
Yes I am. I use kexec boot loader which has capability to load ELF kernel
images (vmlinux). That's why I am
On Wed, Feb 07, 2007 at 02:55:39PM +, Etienne Lorrain wrote:
> Vivek Goyal wrote:
> >How do I know which program header is real mode code and the boot loader
> > is not supposed to load it? May be PT_LOAD header with physical addr 0?
> > What happens if changes happen and down the line we
Etienne Lorrain wrote:
I did try to remove by "sed" some structure easily converted, like:
mov 26(%ebx),%eax
by:
mov 26(%bx),%eax
for all registers esi,edi,ebx,ebp but it saved so few bytes that I did not keep
it.
Well, *of course*, since you still do all your pointer arithmetic in
Vivek Goyal wrote:
>How do I know which program header is real mode code and the boot loader
> is not supposed to load it? May be PT_LOAD header with physical addr 0?
> What happens if changes happen and down the line we start compiling
> real mode code for non-zero address?
Yes, any PT_LOAD
Eric W. Biederman wote:
> H. Peter Anvin wrote:
> > That's not a valid comparison, because you're using 32-bit registers to hold
> > 16-bit pointers, and then sticking 67 prefixes on completely unnecessarily.
>
> Regardless if the size is good enough we can use it :)
>
> For romcc I had a 3x code
Eric W. Biederman wote:
H. Peter Anvin wrote:
That's not a valid comparison, because you're using 32-bit registers to hold
16-bit pointers, and then sticking 67 prefixes on completely unnecessarily.
Regardless if the size is good enough we can use it :)
For romcc I had a 3x code bloat
Vivek Goyal wrote:
How do I know which program header is real mode code and the boot loader
is not supposed to load it? May be PT_LOAD header with physical addr 0?
What happens if changes happen and down the line we start compiling
real mode code for non-zero address?
Yes, any PT_LOAD below
Etienne Lorrain wrote:
I did try to remove by sed some structure easily converted, like:
mov 26(%ebx),%eax
by:
mov 26(%bx),%eax
for all registers esi,edi,ebx,ebp but it saved so few bytes that I did not keep
it.
Well, *of course*, since you still do all your pointer arithmetic in
On Wed, Feb 07, 2007 at 02:55:39PM +, Etienne Lorrain wrote:
Vivek Goyal wrote:
How do I know which program header is real mode code and the boot loader
is not supposed to load it? May be PT_LOAD header with physical addr 0?
What happens if changes happen and down the line we start
On Tue, Feb 06, 2007 at 01:12:05PM +, Etienne Lorrain wrote:
> > Building real mode code with kernel binary (vmlinux) has got another
> > disadvantage that it breaks using vmlinux for kdump purposes. One compiles
> > the kernel binary to execute from a different address but real mode
> >
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Etienne Lorrain wrote:
>> H. Peter Anvin wrote:
>>> I've long wished that someone would do a proper 16-bit x86 port of gcc;
>>
>>> however, the .code16gcc is usually good enough, although it produces code
>>> which is a lot bigger than it needs to
Etienne Lorrain wrote:
H. Peter Anvin wrote:
I've long wished that someone would do a proper 16-bit x86 port of gcc;
however, the .code16gcc is usually good enough, although it produces
code which is a lot bigger than it needs to be.
It is only that much bigger if you compare to 16 bits
H. Peter Anvin wrote:
> I've long wished that someone would do a proper 16-bit x86 port of gcc;
> however, the .code16gcc is usually good enough, although it produces
> code which is a lot bigger than it needs to be.
It is only that much bigger if you compare to 16 bits integer compilers,
Eric W. Biederman wrote:
Modifying the linux real mode assembler, nobody could even want to.
I have several times. It's just code. But I do agree it will likely
be more maintainable if we can convert it to C.
On that same token I wrote a compiler in romcc in another context so I
didn't
Etienne Lorrain <[EMAIL PROTECTED]> writes:
> I am not sure to understand: Gujin calls a function inside the ELF real
> mode program header of the Linux kernel. All the system is currently
> in real mode. There isn't any limitation in this function of the kernel to
> decide to print some message
Eric W. Biederman wrote:
> Etienne Lorrain <[EMAIL PROTECTED]> writes:
>> Well, if the function called at offset 0 in the real-mode section return
>> non zero, that is probably an error - that is Gujin interface, but do not
>> ask
>> me to change other bootloaders to handle that.
>> This
Etienne Lorrain <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Etienne Lorrain <[EMAIL PROTECTED]> writes:
>> > New features are more that this real-mode function can return an error
>> > to the bootloader to tell something to the user, so the user can select
>> > another kernel
Eric W. Biederman wrote:
> Etienne Lorrain <[EMAIL PROTECTED]> writes:
> > New features are more that this real-mode function can return an error
> > to the bootloader to tell something to the user, so the user can select
> > another kernel with the right processor, another video mode... with
>
Etienne Lorrain <[EMAIL PROTECTED]> writes:
> H. Peter Anvin wrote:
>> Actually, as far as I can see, he has re-invented having a real-mode
>> code chunk which then gets run before the protected-mode kernel. We
>> already have that!
>
> I did not claim to have invented anything there, this
H. Peter Anvin
> Etienne Lorrain wrote:
> > Also there isn't any more kernel size limit.
>
> What kernel size limit?
Sorry - there isn't any limit for the kernel size, for a long time.
Etienne.
Etienne Lorrain wrote:
Also there isn't any more kernel size limit.
What kernel size limit?
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
H. Peter Anvin wrote:
> Actually, as far as I can see, he has re-invented having a real-mode
> code chunk which then gets run before the protected-mode kernel. We
> already have that!
I did not claim to have invented anything there, this is just a quite
simple C code to execute instead of
Eric W. Biederman wrote:
Just for documentation the current interface is you come in through
the kernels 16bit entry point and get all of it's BIOS calls, or your
bootloader is responsible for getting the equivalent information
somehow.
From what little I skimmed part of what Gujin wanted to
H. Peter Anvin, Vivek Goyal wrote:
>> Either way, though, putting Gujin-specific code in the main kernel
>> output is a pretty dull thud.
>
> Agreed.
May I ask if you are refering to the Gujin structures under the
ROOT_EXTENSIVE_SEARCH compilation switch, or the
C structures describing the BIOS
> Building real mode code with kernel binary (vmlinux) has got another
> disadvantage that it breaks using vmlinux for kdump purposes. One compiles
> the kernel binary to execute from a different address but real mode code/data
> will continue to be at virtual/physical addr 0 and kexec can not
> First of all, if sending attached patches, *MAKE SURE* they're text/plain.
Sorry, next time I'll do.
> The standard way to do this is to have a command line argument named
> BOOT_IMAGE (as in BOOT_IMAGE=/foo/bar/baz). There is no reason to do
> this differently from every other
First of all, if sending attached patches, *MAKE SURE* they're text/plain.
Sorry, next time I'll do.
The standard way to do this is to have a command line argument named
BOOT_IMAGE (as in BOOT_IMAGE=/foo/bar/baz). There is no reason to do
this differently from every other bootloader.
Building real mode code with kernel binary (vmlinux) has got another
disadvantage that it breaks using vmlinux for kdump purposes. One compiles
the kernel binary to execute from a different address but real mode code/data
will continue to be at virtual/physical addr 0 and kexec can not load it
H. Peter Anvin, Vivek Goyal wrote:
Either way, though, putting Gujin-specific code in the main kernel
output is a pretty dull thud.
Agreed.
May I ask if you are refering to the Gujin structures under the
ROOT_EXTENSIVE_SEARCH compilation switch, or the
C structures describing the BIOS which
Eric W. Biederman wrote:
Just for documentation the current interface is you come in through
the kernels 16bit entry point and get all of it's BIOS calls, or your
bootloader is responsible for getting the equivalent information
somehow.
From what little I skimmed part of what Gujin wanted to
H. Peter Anvin wrote:
Actually, as far as I can see, he has re-invented having a real-mode
code chunk which then gets run before the protected-mode kernel. We
already have that!
I did not claim to have invented anything there, this is just a quite
simple C code to execute instead of the
Etienne Lorrain wrote:
Also there isn't any more kernel size limit.
What kernel size limit?
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
H. Peter Anvin
Etienne Lorrain wrote:
Also there isn't any more kernel size limit.
What kernel size limit?
Sorry - there isn't any limit for the kernel size, for a long time.
Etienne.
Etienne Lorrain [EMAIL PROTECTED] writes:
H. Peter Anvin wrote:
Actually, as far as I can see, he has re-invented having a real-mode
code chunk which then gets run before the protected-mode kernel. We
already have that!
I did not claim to have invented anything there, this is just a
Eric W. Biederman wrote:
Etienne Lorrain [EMAIL PROTECTED] writes:
New features are more that this real-mode function can return an error
to the bootloader to tell something to the user, so the user can select
another kernel with the right processor, another video mode... with
clean
Etienne Lorrain [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Etienne Lorrain [EMAIL PROTECTED] writes:
New features are more that this real-mode function can return an error
to the bootloader to tell something to the user, so the user can select
another kernel with the right
Eric W. Biederman wrote:
Etienne Lorrain [EMAIL PROTECTED] writes:
Well, if the function called at offset 0 in the real-mode section return
non zero, that is probably an error - that is Gujin interface, but do not
ask
me to change other bootloaders to handle that.
This function is
Etienne Lorrain [EMAIL PROTECTED] writes:
I am not sure to understand: Gujin calls a function inside the ELF real
mode program header of the Linux kernel. All the system is currently
in real mode. There isn't any limitation in this function of the kernel to
decide to print some message and
Eric W. Biederman wrote:
Modifying the linux real mode assembler, nobody could even want to.
I have several times. It's just code. But I do agree it will likely
be more maintainable if we can convert it to C.
On that same token I wrote a compiler in romcc in another context so I
didn't
H. Peter Anvin wrote:
I've long wished that someone would do a proper 16-bit x86 port of gcc;
however, the .code16gcc is usually good enough, although it produces
code which is a lot bigger than it needs to be.
It is only that much bigger if you compare to 16 bits integer compilers,
but
Etienne Lorrain wrote:
H. Peter Anvin wrote:
I've long wished that someone would do a proper 16-bit x86 port of gcc;
however, the .code16gcc is usually good enough, although it produces
code which is a lot bigger than it needs to be.
It is only that much bigger if you compare to 16 bits
H. Peter Anvin [EMAIL PROTECTED] writes:
Etienne Lorrain wrote:
H. Peter Anvin wrote:
I've long wished that someone would do a proper 16-bit x86 port of gcc;
however, the .code16gcc is usually good enough, although it produces code
which is a lot bigger than it needs to be.
It is only
On Tue, Feb 06, 2007 at 01:12:05PM +, Etienne Lorrain wrote:
Building real mode code with kernel binary (vmlinux) has got another
disadvantage that it breaks using vmlinux for kdump purposes. One compiles
the kernel binary to execute from a different address but real mode
code/data
Vivek Goyal <[EMAIL PROTECTED]> writes:
> On Mon, Feb 05, 2007 at 10:38:30PM -0800, H. Peter Anvin wrote:
>> Vivek Goyal wrote:
>> >
>> >That time, grub was working fine but lilo had broken on one of Andrew's
>> >machine. I could not reproduce the problem on my setup and had no clue what
>> >was
On Mon, Feb 05, 2007 at 10:38:30PM -0800, H. Peter Anvin wrote:
> Vivek Goyal wrote:
> >
> >That time, grub was working fine but lilo had broken on one of Andrew's
> >machine. I could not reproduce the problem on my setup and had no clue what
> >was the issue. Hence got rid of ELF header from
Vivek Goyal wrote:
That time, grub was working fine but lilo had broken on one of Andrew's
machine. I could not reproduce the problem on my setup and had no clue what
was the issue. Hence got rid of ELF header from bzImage which was non-essential
stuff for relocatable kernel. But that issue
On Mon, Feb 05, 2007 at 10:16:59PM -0800, H. Peter Anvin wrote:
> Vivek Goyal wrote:
> >
> >I don't know much about Gujin, but advantage here seems to be that it has
> >capability to load elf files and that's why the attempt to turn kernel
> >binary
> >into a compressed elf image. Why don't we
Vivek Goyal wrote:
I don't know much about Gujin, but advantage here seems to be that it has
capability to load elf files and that's why the attempt to turn kernel binary
into a compressed elf image. Why don't we then simply add an ELF header to
bzImage and Gujin and any ELF loader including
On Mon, Feb 05, 2007 at 04:37:43PM -0800, H. Peter Anvin wrote:
> First of all, if sending attached patches, *MAKE SURE* they're text/plain.
>
> >diff -uprN -X linux-2.6.20/Documentation/dontdiff
> >linux-2.6.20/arch/i386/kernel/setup.c
> >linux-2.6.20-gujin/arch/i386/kernel/setup.c
> >---
First of all, if sending attached patches, *MAKE SURE* they're text/plain.
diff -uprN -X linux-2.6.20/Documentation/dontdiff
linux-2.6.20/arch/i386/kernel/setup.c
linux-2.6.20-gujin/arch/i386/kernel/setup.c
--- linux-2.6.20/arch/i386/kernel/setup.c 2007-02-04 18:44:54.0
+
First of all, if sending attached patches, *MAKE SURE* they're text/plain.
diff -uprN -X linux-2.6.20/Documentation/dontdiff
linux-2.6.20/arch/i386/kernel/setup.c
linux-2.6.20-gujin/arch/i386/kernel/setup.c
--- linux-2.6.20/arch/i386/kernel/setup.c 2007-02-04 18:44:54.0
+
On Mon, Feb 05, 2007 at 04:37:43PM -0800, H. Peter Anvin wrote:
First of all, if sending attached patches, *MAKE SURE* they're text/plain.
diff -uprN -X linux-2.6.20/Documentation/dontdiff
linux-2.6.20/arch/i386/kernel/setup.c
linux-2.6.20-gujin/arch/i386/kernel/setup.c
---
Vivek Goyal wrote:
I don't know much about Gujin, but advantage here seems to be that it has
capability to load elf files and that's why the attempt to turn kernel binary
into a compressed elf image. Why don't we then simply add an ELF header to
bzImage and Gujin and any ELF loader including
On Mon, Feb 05, 2007 at 10:16:59PM -0800, H. Peter Anvin wrote:
Vivek Goyal wrote:
I don't know much about Gujin, but advantage here seems to be that it has
capability to load elf files and that's why the attempt to turn kernel
binary
into a compressed elf image. Why don't we then simply
Vivek Goyal wrote:
That time, grub was working fine but lilo had broken on one of Andrew's
machine. I could not reproduce the problem on my setup and had no clue what
was the issue. Hence got rid of ELF header from bzImage which was non-essential
stuff for relocatable kernel. But that issue
On Mon, Feb 05, 2007 at 10:38:30PM -0800, H. Peter Anvin wrote:
Vivek Goyal wrote:
That time, grub was working fine but lilo had broken on one of Andrew's
machine. I could not reproduce the problem on my setup and had no clue what
was the issue. Hence got rid of ELF header from bzImage which
Vivek Goyal [EMAIL PROTECTED] writes:
On Mon, Feb 05, 2007 at 10:38:30PM -0800, H. Peter Anvin wrote:
Vivek Goyal wrote:
That time, grub was working fine but lilo had broken on one of Andrew's
machine. I could not reproduce the problem on my setup and had no clue what
was the issue. Hence
86 matches
Mail list logo
