[lkml]   [2002]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2.5.12] x86 Boot enhancements, boot protocol 2.04 9/11
Followup to:  <>
By author: (Eric W. Biederman)
In newsgroup:
> 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


<> at work, <> in private!
"Unix gives you enough rope to shoot yourself in the foot." <>
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:25    [W:0.115 / U:4.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site