LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
@ 2007-02-08 13:10 Etienne Lorrain
  2007-02-09  5:59 ` Vivek Goyal
  0 siblings, 1 reply; 14+ messages in thread
From: Etienne Lorrain @ 2007-02-08 13:10 UTC (permalink / raw)
  To: vgoyal; +Cc: H. Peter Anvin, linux-kernel, Eric W. Biederman

> >  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 have to be aware that kernel vmlinux
> might contain a special PT_LOAD type program header which will contain
> real mode code and it does not have to be loaded. Then I will run into
> guessing business which one is that real mode PT_LOAD  program header and
> my assumption might very well break in next few kernel release.

 So is kexec able to relocate this vmlinux? If kexec and Gujin do approximately
the same thing they should do it the same way. If you cannot get a PT_LOAD
section, maybe we can put a simple system in NOTE, or just create a
PT_LOAD16 if the linker accepts other values.
 I do not really like to relocate after vmlinux has been linked at a fixed address,
because I am not sure you can guess each address to relocate or not:
you can define permanent address in the linker file by simply "symbol = address"
and those should never be relocated. For instance the very high addresses
on ia32 may point to registers or FPU instead of memory, so may or may not
have to be relocated. I also would better like you not to relocate the real-mode
addresses.
 
> >  And you do not want to write protect the kernel code (if the CPU write protection
> > is not working, the hardware is not working so debug will be difficult, and a simple
> > CRC32 can tell kernel memory failure) and use twice the same code memory
> > (with different data area or saving kernel data elsewhere before reload).
> >  Is that related to module loading or instruction set detection/patch or multiprocessor?
>
> If I understand it right, you seem to be suggesting that I don't have to 
> reload the kernel text and I can only reload the data for second kernel?
> 
> We run the whole of the kernel from a mutually execlusive location from
> first kernel to mitigate the concerns that first kernel's ongoing DMA might
> corrupt second kernel. That's why first kernel's text can't be reused.

  So in some exception handler, you detect something is wrong and then
 jump to a new kernel. Maybe this class of bug (DMA or hardware bit flipped)
 should be detected even without this double kernel environment, by running a
 CRC32 on the kernel text section in this exception handler, displayed that in
 the crash dump.

> Secondly, it gives flexibility to user that either he can choose to use 
> the production kernel as capture kernel or an entirely different custom
> kernel can be used as capture kernel.

  IHMO if it is just capturing the memory, I would have a kernel without
 any modules (usb-storage drivers linked-in) and save to USB key the
 core. Automatically loading modules after the crash may be a problem.

> If real mode code is linked with vmlinux, then kdump will be broken.

 I do not want to break anything for fun. I need either a reason or a bug.

> bzImage is relocatable. If a new kernel image format is introduced
> (compressed ELF), then I will prefer it to be a relocatable one
> (if possible).

 It may be possible to do some kind of "ld -r -o vmlinux", but delaying
the decision where to run the kernel is just delaying: someone has to
decide, and even if Gujin do not decide It will ask the user who most
of the time will have no clue... and on which basis do you want the
bootloader to decide... maybe this SDRAM is faulty and usually the
SDRAM are 512 Mbytes so run the kernel at 512 + 16 Mbytes, but
only if there is more than 1024 Mbytes of SDRAM?

  Thanks,
  Etienne.


	

	
		
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re : Re : Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
@ 2007-02-06 20:30 Etienne Lorrain
  2007-02-06 20:55 ` Eric W. Biederman
  0 siblings, 1 reply; 14+ messages in thread
From: Etienne Lorrain @ 2007-02-06 20:30 UTC (permalink / raw)
  To: Eric W. Biederman; +Cc: H. Peter Anvin, vgoyal, linux-kernel

Eric W. Biederman wrote:
> Etienne Lorrain <etienne_lorrain@yahoo.fr> 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 called with few parameters, one is a string pointer
>>  if the function do not want to print the problem report itself.
>>  The function is called with an offset of zero in its own intel
>>  segment.
>
> So I think there are some backwards compatibility issues with your
> real mode code interface.  Setting a new flag that says to return instead
> of printing an error message and halting would be one way to handle
> this.

 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 not return at all, this function can
selectively do so by reading which bootloader ID it is using (another
parameter). It is not done mostly because "printf" is difficult to do
in assembler, Gujin has no problem.

> Is your real mode C code section relative such that it can be loaded
> at different addresses and still work?

  The code is relative - but not the data (first 4 Kbytes at %ds:0 and stack
 available) - but the whole lot at any segment boundary, i.e. every 16 bytes.
 Else Gujin would not work under DOS.

> The program header is for executable loaders the section header is for
> linkers and the section header is optional in PT_LOAD and PT_DYN
> executables.  Use of the section header by a loader is a bug.

  Unless if there is a problem, Gujin uses only the program header;
 it has a look in the section header just in case - that can be removed
 easily. I was wondering about a relocatable image there - but I do
 not know enough for that.

> There have been limitations but mostly with respect to page table size
> and the like but they were not limitations a bootloader had to deal with.

Was talking about this comment, but it is old:
/* 0x28000*16 = 2.5 MB, conservative estimate for the current maximum */
http://lxr.linux.no/source/arch/i386/boot/tools/build.c?v=2.4.28

> >   Well, you can generate with the proposed patch and boot with SYSLINUX,
> >  Grub and LILO, but trying to clean Linux real-mode code is where I begun.
>
> I haven't looked yet.  But I believe this is something that we can do,
> so long as cleaning and feature enhancement are not mixed in a bad way.
> Phrasing this another way.  What we can do with the interface is
> determined our interface to existing bootloaders and what bootloaders
> exist.  Basically it is the rule that we need to preserve backwards
> compatibility and changes generally need to be evolutionary ones.

  Well, if you want to preserve compatibility with other bootloaders,
 it is probably possible to put some source around the ELF kernel file,
 mostly taken from Gujin if you want (GPL), but I wonder why you would
 like to be compatible with LILO.
 Modifying the linux real mode assembler, nobody could even want to.

 Etienne.






	

	
		
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2007-02-12 19:47 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-08 13:10 Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3 Etienne Lorrain
2007-02-09  5:59 ` Vivek Goyal
2007-02-09 13:04   ` Etienne Lorrain
2007-02-09 19:42     ` Eric W. Biederman
2007-02-11 13:23       ` RE : " Etienne Lorrain
2007-02-11 20:49         ` Eric W. Biederman
2007-02-12 10:42           ` Etienne Lorrain
2007-02-12 12:29             ` Eric W. Biederman
2007-02-12 13:58               ` Etienne Lorrain
2007-02-12 14:06               ` H. Peter Anvin
2007-02-12 19:47                 ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2007-02-06 20:30 Re : Re : " Etienne Lorrain
2007-02-06 20:55 ` Eric W. Biederman
2007-02-06 21:00   ` H. Peter Anvin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).