On Mon, 25 Feb 2008 10:13:17 -0800, "H. Peter Anvin" <hpa@zytor.com>
said:
quoted text
> Alexander van Heukelum wrote:
> > 
> >  arch/x86/kernel/head64.c |   45 +++++++++++++++++++++++++++------------------
> >  1 files changed, 27 insertions(+), 18 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
> > index 38f32e7..b684552 100644
> > --- a/arch/x86/kernel/head64.c
> > +++ b/arch/x86/kernel/head64.c
> > @@ -49,33 +49,42 @@ static void __init copy_bootdata(char *real_mode_data)
> >  	}
> >  }
> >  
> > -#define EBDA_ADDR_POINTER 0x40E
> > +#define BIOS_EBDA_SEGMENT 0x40E
> > +#define BIOS_LOWMEM_KILOBYTES 0x413
> >  
> 
> Linus has specific comments in the 32-bit code that states we do not 
> want to use address 0x413 for anything - if nothing else because it's 
> often lowered when there is boottime code involved like CD-ROM booting 
> or PXE.

Hello hpa,

I failed to find a comment referring to 0x413 or int 0x12 in
arch/x86/kernel. I do know the comment in Documentation/i386/boot.txt,
however, suggesting that "INT 12h" _should_ be used, but that it would
be pointless for zImage and old bzImage kernels, because they _have_
to be started from 0x90000 anyway. New bzImage kernels do not have
this limitation, and smart bootloaders simply put them at much
lower addresses, like 0x40000. (I know: you know.) My point is just
that the argument not to use 0x413 in the bootloader is not valid
for this case.

That leaves the possibility that code/data is inserted at the top of
conventional memory by either the BIOS or some kind of bootloader.
My view on this is that this code/data should be preserved: it
was specifically asked from us by lowering 0x413. One just loses
a tiny bit of usable memory, and if the program booting the kernel
knows better it can unload the driver if it wants to. It's just
not a kernel problem.

quoted text
> Either way, the code should be shared between 32 and 64 bits.
> There is nothing bitsize-specific about it!

Of course. That's also why I already added the old-Dell case ;).
But one problem at a time, please!

Greetings,
    Alexander
-- 
  Alexander van Heukelum
  heukelum@fastmail.fm

-- 
http://www.fastmail.fm - I mean, what is it about a decent email service?

--
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/