Re: [PATCH] swap real_to_prot() and prot_to_real() (Re: [PATCH] i386-qemu port)

[Robert Millan <rmh@aybabtu.com>]

On Sun, Jun 21, 2009 at 09:56:42PM -0400, Pavel Roskin wrote:
> On Sun, 2009-06-21 at 21:52 +0200, Robert Millan wrote:
> > When doing the i386-coreboot port I made this choice completely backwards.
> > 
> > I thought real_to_prot() was only useful on i386-pc, because we needed it
> > for returning from BIOS, and prot_to_real() was useful elsewhere, because
> > the Linux loader would use it.
> > 
> > Turns out we need real_to_prot() on i386-qemu for the initial transition
> > to i386 mode, AND we don't need prot_to_real() anywhere other than i386-pc,
> > because OSes that expect to be loaded in i8086 mode are going to rely on
> > BIOS calls.
> > 
> > So this patch swaps them.  real_to_prot() goes to realmode.S and
> > prot_to_real() back to startup.S.
> 
> You have my approval as long as it compiles and doesn't introduce any
> warnings.

Done, no warnings.  I decided to keep prot_to_real() in its current place
though.  It's probably going to be useful when we support processing ROMs
in i386-coreboot (e.g. for biosdisk or vbe).

> I'm attaching the script I'm using to test all platforms at once.  The
> compiler path needs to be adjusted, as well as the target names, as they
> affect search for the target compiler.  That's the version with qemu
> support.  If every Log2make is empty, please go ahead.

Thanks.  Btw, maybe you find this useful:

-MAKE_JOBS=8
+MAKE_JOBS=`getconf _NPROCESSORS_ONLN || echo 1`

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."