| 1 |
On Friday 22 December 2006 01:02, Mike Doty <kingtaco@g.o> wrote |
| 2 |
about 'Re: [gentoo-amd64] Re: Emerging package as both 64 and 32 bit': |
| 3 |
> Duncan wrote: |
| 4 |
> > Simon Stelling <blubb@g.o> posted 45866BE0.20905@g.o, |
| 5 |
> > |
| 6 |
> > excerpted below, on Mon, 18 Dec 2006 12:22:24 +0200: |
| 7 |
> >> Neil Bothwick wrote: |
| 8 |
> >>> What's wrong with the GRUB source package? |
| 9 |
> >> No problem, but it's 32bit. |
| 10 |
> > Indeed... for backward compatibility, amd64/x86_64 boots in 32-bit |
| 11 |
> > mode. Actually, I /believe/ it boots in 16-bit real mode, just like an |
| 12 |
> > x86, [...] but AFAIK the difference between compiling 16-bit and 32-bit |
| 13 |
> > code is simply a few compile-time switches, so it uses a standard |
| 14 |
> > 32-bit toolchain. |
| 15 |
> You're referring to real mode(16 bit). the BIOS will load the |
| 16 |
> bootloader in real mode, the bootloader will switch to protected mode(32 |
| 17 |
> bit) and if you have the right kernel, it will switch to extended |
| 18 |
> mode(64 bit) |
| 19 |
|
| 20 |
Also, it's technically possible for the bootloader to switch into extended |
| 21 |
mode before loading the kernel, but not done (in GRUB, at least) for solid |
| 22 |
technical reasons. (IIRC, there's some memory mappings that have to be |
| 23 |
set up before entering extended mode.) |
| 24 |
|
| 25 |
-- |
| 26 |
"If there's one thing we've established over the years, |
| 27 |
it's that the vast majority of our users don't have the slightest |
| 28 |
clue what's best for them in terms of package stability." |
| 29 |
-- Gentoo Developer Ciaran McCreesh |
Archives