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  9:48 Etienne Lorrain
  2007-02-08 11:20 ` Eric W. Biederman
  2007-02-08 11:37 ` Vivek Goyal
  0 siblings, 2 replies; 22+ messages in thread
From: Etienne Lorrain @ 2007-02-08  9:48 UTC (permalink / raw)
  To: vgoyal; +Cc: H. Peter Anvin, linux-kernel, Eric W. Biederman

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 0xC0000000) is Linux protected mode.
> > Considering the linker used it is always the 4th program header, before there
> > were only 3 program header,third one stay the NOTE one.
>
> Well this is all a lot of speculation. This is not standard way of retrieving
> information from ELF. Number of program headers finally created keep on
> changing. Previously it was left to the linker and now people have changed
> it to 3 by specifically using PHDR directive.

  Well, the standard way is:
1 - the code program header, to be write protected if possible
2 - the (initialised) data program header, to be able to restart the program by just reload/re-entry,
    and after that (memsiz - filesz) of BSS
 Anything after is non standard. The number of program header is written in the ELF header,
but anything over 2 probably need a special loader for the extra treatment.
 That isn't usual to have something near zero, because it is better not to map
any memory there to catch null pointer dereference (in virtual memory system).

 I assume you care about this ELF header because you are also a user of
the ELF file vmlinux, aren't you?
  
> >  Just I did not completely understand why you need relocation (and the announce
> > was when I was in holidays far away). I know a simple kernel is needed to do
> > some debugging when the main kernel has crashed, this kernel is better loaded
> > at for instance 16 Mbytes. You probably do not want the same kernel as the main
> > one because it may crash the same way, and you start a loop - and even then
> > if you have exactly the same kernel it is easier to use the same write-protected
> > block of memory with different data sections.
> >  But I probably do not understand the problem so do not know what to write.
> 
> As long as one can make sure that test kernel boots (commonly the case with
> distros), same kernel can be used as capture kernel too. So the idea here
> is to be able to use same kernel binary as production kernel and capture
> kernel hence distros don't have to ship an additional kernel binary compiled
> for a different physical addr just for dump capturing purposes.

 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?

> 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 kernel.

  So here you are not really using the initial ELF program header of vmlinux,
but more the section header and my PT_LOAD section bother you, I better
understand. You cannot really claim you are only doing standard/usual
ELF treatment.

 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] 22+ messages in thread
* Re: RE : Re: Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
@ 2007-02-11 20:49 Eric W. Biederman
  2007-02-12 10:42 ` Etienne Lorrain
  0 siblings, 1 reply; 22+ messages in thread
From: Eric W. Biederman @ 2007-02-11 20:49 UTC (permalink / raw)
  To: Etienne Lorrain; +Cc: vgoyal, H. Peter Anvin, linux-kernel

Etienne Lorrain <etienne_lorrain@yahoo.fr> 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 at a
>> >  fixed address first. In fact I wonder if we are talking of the same
>> >  kind of relocation: you seem to talk about "ld --pic-executable" while
>> >  I am thinking of "ld -r" to "locate" it at the bootloader loading time.
>> >   The main problem I see is that I do not have the code for that, and
>> >  I am going deeper/earlier into the generation of vmlinux, while comments
>> >  are "already you are too early, loading an ELF file is too complex for
>> >  a bootloader". The solution I have already is working.
>> 
>> Being very clear.  ld --pic-executable or ld -shared is essentially
>> what we are talking when we are discussing building a relocatable
>> kernel.  Something with the properties of an ELF ET_DYN executable
>> that does not use an interpreter.  ld.so is the only common executable
>> of this type in linux.
>
>  So we are talking of two different things.
>  You want to _compile_ the totality of the kernel as code and data
> relocatable - right now only modules are compiled that way.
>  On IA32 architecture, there is no problem having the code relocatable,
> because most/all calls and jumps are PC relative, so very few instructions
> need to be different.
>  The problem is having the data relocatable, then every access to memory
> has to be relative to a register, and so the register EBX is reserved
> for that by the compiler.
>  The IA32 processor does not have enough registers already, removing one
> of them makes the assembly seriously worse - mostly when dealing with
> 64 bits "long long" - you can only get two of them in register and a
> simple addition produces long and slow code.
>  Having the data relocatable could be done by using the base address of
> IA32 segments, but this does not seem to be the preferred method because
> segments use seems to slow down the processor a lot more.

There are two more options in addition to segments:
- Running at a fixed virtual address.
- Processing relocation entries to modify the initial code/data to
  live where we want.  We don't have the that shared libraries do of wanting
  to share text/data pages loaded at different addresses.

>  What I was talking of was "loading" a non relocatable kernel (compiled
> as usual without -fPIC/-shared) at any address, so not inducing slow
> down whatever the base address used. I said that it is possible, maybe
> quite easy to do so, but I do not have the code for it - and people
> say right now that an ELF bootloader is not what they want to.

The thing to pick up on is that we really don't want the gcc flag
-fPIC but if ld wasn't an idiot we would want the linker flag -shared.
Anyway we have working code merged that processes all of the
relocation entries and modifies the kernel to run properly where we
load it at.  This has all been done and merged at this point.  It's
only available to a bzImage loader but it is all there.  Currently the
only overhead is something like 5 or 10 percent overhead to hold the
relocation entries.

The only thing currently compiled with -fPIC is the kernel gzip
decompressor and it is carefully coded so it doesn't generate any
relocation entries that need processing.  It is just throw away code
so we don't much care about it's efficiency.

>  Now, if people wants to switch to a completely relocatable kernel,
> because they do not mind the slow down (that I am not really able
> to quantify) - and because anyway most of their kernel is modules,
> then Gujin can relocate that without _any_ problem; in fact it
> does already load in intermediate (HIMEM malloc'ed) memory under
> DOS to relocate it later (called 'late relocation' in Gujin code,
> done every times the code is not at the right address in memory,
> interrupt disabled and in protected mode).

Yes.  That is roughly what we are saying.  We want that at least
as a well defined option.

>  Loading and executing at whatever address is not a problem,
> and should be doable already in the real-mode function of the
> kernel called by Gujin, by modifying few elements of the
> structure passed in parameter of this real-mode function:
> it should be done after loading the E820 memory map for the
> BIOS parameter page.
> I am reading right now Gujin source and note that you may want
> to access array elf_reloc[] and variable nb_elf_reloc in this
> Linux function - will be added in next Gujin version.
>  You already can access type LOADER_str parameter "loader"
> where you can get runadr which can overwrite the ELF entry
> point address. The old ELF header is at loader.load_address
> if it is needed.
>
>  The main problem Gujin has, is to decide where to load a
> relocatable kernel, so this policy is left to the kernel and
> not to the user. For instance and as you made me think of, if you
> do not want for security reasons that the kernel memory could
> be modified by an attacker by using the legacy DMA, then you
> want to load it at an address which cannot be modified this way,
> i.e. over 16 Mbytes. Note that some chipset had an extension I/O
> address to extend this legacy DMA to 32 bits addresses, but it
> has not been documented and probably not implemented widely.
>
>  I do not know how many people are like me, but I am currently
> typing on a monolitic kernel because I find it a _lot_ simpler
> to do a ".config" once and make it slowly evolve with new kernel
> versions (answering No to most of the questions), than managing
> hundreds of module files each time I regenerate/remove a kernel.
>  The kernel I am working on is not relocatable because - well
> I do not have crash to debug...

Yes.   In this sense I'm a tool builder.  I build general capabilities
that can be used to solve specific problems.  A relocatable kernel
is a general capability and the only interesting problem to date
has been taking crash dumps.  To reduce the maintenance overhead I
try and remove the cases where you need an extra config option for
the new functionality.  If there is not overhead a config option just
makes things harder to test.

>  So I think that from the Gujin point of view, everything you need
> is done and working (but the access to elf_reloc)- please explain what
> you want more if not. If you want a solution to load now, you can
> use patch linux-2.6.20-rc5 in sourceforge, which uses an intermediate
> binary dump of the ELF file, and can be relocated the non ELF way.

This requires a more detailed examination.  The previous conversation
indicated that if we could replace setup.S, video.S and edd.S with
C versions it would be very interesting.  If we happen to change the
link so they are available in an ELF executable so much the better.

If we wind up adding two versions of the real mode code one written
in assembly and one written in C accessible by different means
by different bootloaders that is not interesting.

>  So, why do I want an ELF file loaded by a bootloader?

>  The main reason is to be able to use all the usual ELF tools to do
> all sort of things, like showing segments size and base address with
> "objdump" and "readelf", adding and extracting sections with "strip"
> and "objcopy", and dumping section content with either "objdump -m i8086"
> or "objdump" alone to display the assembly instructions after link,
> for real-mode or protected-mode, with symbols.
>  For all that, I need a 100% compatible ELF file structure - that is
> what I have already.

Yes.  That is nice. 

>  I know that to load this ELF kernel file the user will need a different
> loader like Gujin or your kexec. I know that I am asking you not to treat
> an impossible action (loading a section at address 0 over the interrupt
> table), and I say please.

It is my belief that we can solve this without hacks, and still have
a useable structure.

[snip]
>  So technically - and if I understand you correctly (feel free to correct
>  me) - you ask me to put the real mode code into the NOTE section, by
>  adding a few words header and concatening the code.
>
>  There is two way to do so, the first being simply to replace in
> vmlinux.lds.S (in the patch I sent) the lines:
>   .realmode 0 : AT (ADDR(.bss) + SIZEOF(.bss) - LOAD_OFFSET) {
>   ..... *(.init.text16) ...
>   } :text16 = 0x9090
> by something like:
>   .realmode 0 : AT (ADDR(.bss) + SIZEOF(.bss) - LOAD_OFFSET) {
>   LONG(8)
>   LONG(SIZEOF (.realmode))
>   LONG(1)
>   BYTE('R') BYTE('E') BYTE('A') BYTE('L')
>   BYTE('M') BYTE('O') BYTE('D') BYTE('E')
>   ..... *(.init.text16) ...
>   } :note = 0x9090

That would certainly get the job done.

>  The other way to do is to produce an independant link for the real-mode
> program (linked at base address 0), convert it to binary and include
> the resulting block into the NOTE segment. First that is a lot more
> complex (it can be done but is more complex), and two I loose all
> the debuging information I wanted in the ELF file.
>  I can still see the real-mode assembly by forcing objdump to interpret
> the NOTE section as real-mode code, but the offset calculated for
> assembly calls and jumps is wrong, I lost all symbols, in short it
> goes against what I wanted initially.

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.

Which means that we could do something goofy in the linker script
like we do with the current vdso.  So we could give it a virtual
address of 0 and a physical address in the init code section.
Allowing us to load it normally and then just drop it later.  Not
perfect but something that would not need special treatment by
a bootloader unless it wanted to copy the data from there into
some location in low memory and execute it.

For me the objective is not so much reusing the existing tools
(although that is a plus) but more to be able to build a unified
binary that can be used for everything, and will give us the freedom
to do interesting things with the kernel in the future, and hopefully
something that is more or less usable by portable bootloaders.  Having
a different file format and different rules for different
architectures is a pain.

Eric

^ permalink raw reply	[flat|nested] 22+ messages in thread
* 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; 22+ 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] 22+ messages in thread
* Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
@ 2007-02-07 14:29 Etienne Lorrain
  2007-02-07 17:12 ` H. Peter Anvin
  0 siblings, 1 reply; 22+ messages in thread
From: Etienne Lorrain @ 2007-02-07 14:29 UTC (permalink / raw)
  To: Eric W. Biederman, H. Peter Anvin; +Cc: vgoyal, linux-kernel

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 over had crafted assembler, because I
> had no memory and had to inline every single function call because I
> didn't have someplace to put a return register.  So I have the
> scenario with the most code bloat.  I win!

 It is true that I try to put all my variables in big structures in Gujin, not only
because I think it is cleaner (when variables are related in their use) but also
because it reduces the problem of 32 bits addresses by using offsets to the
structure pointer, most of the time.
 In some cases, using 32 bits address prefix is better because offsets to ESP
are possible but in 16 bits you first have to copy SP to BP to reference stack
parameters. Also you can use any register as a pointer.
 Anyway, we are currently talking of 6-7 Kbytes of real-mode section for the ELF,
including root autodetection and command line generation - there is a lot of
source code to describe all those structures but no "code bloat".
 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.

Eric W. Biederman wote:
> This code is currently completely Gujin specific.  If concieved as a
> replacement for setup.S it has a chance of passing review.

  If someone ever want to transfer some code from Gujin to Linux,
 without reducing too much the functionalities, I would be more than
 happy about it - I could even try to help - but considering that I
 even do not have enough time to timely answer E-mails (considering
 my paying job) and I have a lot of other parts of Gujin to improve,
 I can not lead at all on this project.

  I am not sure this task is even possible, I do not know where
 should be the limit in between bootloader and kernel - considering
 that there is also the initrd (why people didn't switch to initramfs
 already?), and being able to debug the real-mode code (like those
 DBG*.exe Gujin files), return error code, check CRC32 is a minimum.

> LILO is a lot saner then Grub, and it still supports more filesystems...
> Just because it memorizes it all before you shut down the system for
> simplicity doesn't mean lilo is worse.

  LILO is quite good, but I cannot talk too much of other bootloader
 because I simply do not use them enough (excluding ISOLINUX).
 At least LILO do not switch too early to protected mode, like Gujin.
 The thing I do not like about it is that there isn't much checks done,
 like a CRC32, so you may load the right sectors from the wrong disk.
 Also, "ioctl (file_desc, FIBMAP, &block)" seem to be less and less
 supported, either by filesystems themselves of by lower layers like
 LVM and the like. The standalone Linux executable "showmap" in Gujin
 show problems sometimes.
 
 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] 22+ messages in thread
* Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
@ 2007-02-06 17:23 Etienne Lorrain
  2007-02-06 17:34 ` H. Peter Anvin
  2007-02-06 18:12 ` Eric W. Biederman
  0 siblings, 2 replies; 22+ messages in thread
From: Etienne Lorrain @ 2007-02-06 17:23 UTC (permalink / raw)
  To: H. Peter Anvin, Eric W. Biederman; +Cc: vgoyal, linux-kernel

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 current real mode assembly:
 it is a rewrite with obvious advantages/disadvantages.
 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 error messages - not a crash dump because this assembly
 instruction is not for that processor.
  I am still saying that the bootloader knows the root filesystem to
 be used by the kernel it loads, and that ELF is a clean format to
 store different sections to be loaded into memory at predefined
 addresses. Also there isn't any more kernel size limit.

 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] 22+ messages in thread
* Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
@ 2007-02-06 13:23 Etienne Lorrain
  0 siblings, 0 replies; 22+ messages in thread
From: Etienne Lorrain @ 2007-02-06 13:23 UTC (permalink / raw)
  To: Eric W. Biederman, vgoyal; +Cc: H. Peter Anvin, linux-kernel

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 could even be used
in the kernel?

Eric W. Biederman wrote:
> From what little I skimmed part of what Gujin wanted to do was sane
> at first glance. Just boot a gziped vmlinux like the other
> architectures.  The problem was the 16bit code.

 So without ROOT_EXTENSIVE_SEARCH defined.
 It is so usefull when you have loads of distributions...
 But yes, maybe that part should be in another file, maybe
 not a complete directory for a single file.
 There is also a special problem with ia32, the number of processor
 involved and their partial compatibilities, that Gujin try to help with.

> So there may be some good ideas buried in there somewhere, but it
> likely to take some doing, and patches that I have to save before
> I read them are a real pain!

 Last time I used this web interface it did not encode text files...

> Eric

 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] 22+ messages in thread
* Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
@ 2007-02-06 13:12 Etienne Lorrain
  2007-02-07  6:44 ` Vivek Goyal
  0 siblings, 1 reply; 22+ messages in thread
From: Etienne Lorrain @ 2007-02-06 13:12 UTC (permalink / raw)
  To: vgoyal, H. Peter Anvin; +Cc: linux-kernel, Eric W. Biederman

> 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
> as that physical memory is not available at all. Kdump skips the real mode
> code execution.

 But that is exactly what you want and need for kdump, isn't it?
 The ELF file did not change, the program header has the last index at
address 0 that you do not want to load because you do not want to
execute the real-mode code. Load the rest and provide the 4 Kbytes
parameter page - it should work.

> 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 Gujin, should be able to load
> it? (As Eric had done in one of the implementations in the past?) Why to 
>create the new infrastructure?

 Because I think when a program evolves it has to get simpler to generate,
run and maintain/debug - while doing more stuff. The number of assembler
lines has to reduce because they are difficult to maintain.
 Removing a ELF header to modify the binary and stick another ELF header
is not exactly what I think simpler - a bit like linking at a fix address and
then modifying the whole set.

HPA wrote:
> Well, Gujin wants additional code too.
> Putting an ELF header on bzImage broke some bootloaders (GRUB, I believe),
> so that's not going to happen again. See the relocatable bzImage thread...

  I also refuses to load a big file at a fixed address before asking the BIOS
 for information, I only crash once the memory when I am pretty sure everything
 seems alright, interruption disabled, just before jumping to the kernel
 entry point. Cannot do that with bzImage. Cannot easily debug without
 this feature.

> Thanks
> Vivek

  Thanks for you comment.
 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] 22+ messages in thread
* Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3
@ 2007-02-06 12:49 Etienne Lorrain
  0 siblings, 0 replies; 22+ messages in thread
From: Etienne Lorrain @ 2007-02-06 12:49 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: linux-kernel

> 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.

  I was more thinking as a command line like the shell command line,
  I can probably modify that. It is only to guess the root filesystem,
  I do not know if BOOT_IMAGE= usually contains the fully qualified path.
  Gujin just adds this string from the "name" field of the GZIP file,
  so it can be manually adjusted.

> Why build the real-mode code as part of the kernel binary?  If you have 
> to reference kernel symbols, you can do that with the -R option to ld. 
> Bundling it into the kernel binary just to then extract it later is 
> silly at best.

  Gujin do not reference any kernel symbol; the complete file is loaded
  at once at a variable memory address. Then Gujin moves the real-mode
  section at a valid address and execute it, then it moves the code and data
  protected mode at a valid address and execute it.
  In this mode Gujin just act as an ELF program loader.
  The variable memory address is good when you are running DOS/HIMEM
  for instance to debug hardware/BIOS - it does not crash random address
  before requesting BIOS services like all other bootloaders.

>> +       @echo  "  /boot/linux-$(KERNELRELEASE).kgz - create a boot kernel for the Gujin bootloader"
> This doesn't exactly fit very well the standard pattern.  Something like 
>  make gujin TARGET=... would be more like it.

  For me, the make parameter is the file you want to get - up to "make" 
  to sort out how to generate it.

> Given how many of your files are highly Gujin-specific, and have generic 
> names, please put them in a subdirectory (e.g. arch/i386/boot/gujin/).

  I do agree that there is a functionality I am not sure of the interface, that
  is the automatic root detection. Nearly everybody put the kernel in its
  own distribution filesystem (Fedora kernel in Fedora root filesystem, Debian
  kernel in Debian root filesystem...) or only has a single distribution.
  The bootloader is loading this kernel file - so it knows exactly which
  disk/partition to propose as root to the kernel.
  So under the compilation switch "ROOT_EXTENSIVE_SEARCH", there
  is the exposed Gujin interface to help the real-mode function of the
  ELF file decide what to do.

  I do disagree that the BIOS interface like "union drive_info" of realmode.h
  is Gujin stuff, it is just that I a lot prefer a C interface with a clean
  structure than "#define OFFSET_OF_THIS_BYTE, #define MASK_OF_THIS_BIT"
  everywhere, I prefer programing in C than programing in CPP.
  Ok, most of the fields are not used - even by Gujin - it is just how the BIOS
  documentation describes them.

>    -hpa

  Thanks for your comments. Sorry I could not answer immediately but
  I had to sleep a bit. I try to reply to the other messages together.
  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] 22+ messages in thread

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

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-08  9:48 Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3 Etienne Lorrain
2007-02-08 11:20 ` Eric W. Biederman
2007-02-08 11:37 ` Vivek Goyal
2007-02-08 12:10   ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2007-02-11 20:49 RE : " 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
2007-02-08 13:10 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-07 14:29 Etienne Lorrain
2007-02-07 17:12 ` H. Peter Anvin
2007-02-06 17:23 Etienne Lorrain
2007-02-06 17:34 ` H. Peter Anvin
2007-02-06 18:12 ` Eric W. Biederman
2007-02-06 13:23 Etienne Lorrain
2007-02-06 13:12 Etienne Lorrain
2007-02-07  6:44 ` Vivek Goyal
2007-02-06 12:49 Etienne Lorrain

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).