> First of all, if sending attached patches, *MAKE SURE* they're text/plain.

  Sorry, next time I'll do.

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

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

quoted text
>> +       @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.

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

quoted text
>    -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
-
unsubscribe notice
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/