Re : Re : Re : [PATCH] Compressed ia32 ELF file generation for loading by Gujin 1/3

[Etienne Lorrain <etienne_lorrain@yahoo.fr>]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/