Re: [PATCH 2.5.12] x86 Boot enhancements, boot protocol 2.04 9/11

["H. Peter Anvin" <hpa@zytor.com>]

Followup to:  <m11ycuy48d.fsf_-_@frodo.biederman.org>
By author:    ebiederm@xmission.com (Eric W. Biederman)
In newsgroup: linux.dev.kernel
>  
>  For backwards compatibility, if the setup_sects field contains 0, the
>  real value is 4.
> @@ -180,8 +199,14 @@
>    loadflags, heap_end_ptr:
>  	If the protocol version is 2.01 or higher, enter the
>  	offset limit of the setup heap into heap_end_ptr and set the
> -	0x80 bit (CAN_USE_HEAP) of loadflags.  heap_end_ptr appears to
> -	be relative to the start of setup (offset 0x0200).
> +	0x80 bit (CAN_USE_HEAP) of loadflags.  heap_end_ptr is
> +	relative to the start of setup (offset 0x0200).
> +
> +	If the protocol version is 2.04 or higher set the 0x40 bit
> +	(STAY_PUT).  This explictly tells the real mode code that you
> +	don't expect it to relocate itself to 0x90000.  No earlier
> +	protocols versions look at this bit so it is safe to set it
> +	unconditionally.
>  

Hang on here... this is bullsh*t.  The real-mode code should not be
relocated if the cmd_line_ptr field is set.  If you don't want to pass
a command line, set cmd_line_ptr to an empty string "".  There should
be no need for an additional protocol here; in fact, having two
protocols only means the boot loader has to do both, in effect, so
what's the point?!?

> +	With boot protocol 2.04 and above the initrd can be loaded
> +	as low as kern_base + kern_memsz.

It's still a bad idea, for several reasons:

a) Adds to the number of configurations that have to be tested, for
   absolutely no good reason.

b) It may be OK for the Linux kernel proper, but it is *NOT*
   acceptable for some other programs that use the Linux boot
   protocol.

	-hpa

 
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>