"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
bo
--- "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 l
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 the
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 l
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
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
--- 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 you
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
> > 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
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 vm
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 vi
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 transfer
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 l
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
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
32-b
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 bel
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 b
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/
"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.
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 i
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,
b
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 ha
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 funct
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
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 is
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
Pl
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 th
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 do
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 load
> 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.
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 t
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 bzIma
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 shou
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 the
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 Guj
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
> >--- linux
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
+
++
43 matches
Mail list logo
