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

[Etienne Lorrain]

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