* Rusty Russell <[EMAIL PROTECTED]> wrote:

> +/* The boot Global Descriptor Table: after boot we allocate a per-cpu copy */
>       .align L1_CACHE_BYTES
>  ENTRY(boot_gdt_table)
> -     .fill GDT_ENTRY_BOOT_CS,8,0
> -     .quad 0x00cf9a000000ffff        /* kernel 4GB code at 0x00000000 */
> -     .quad 0x00cf92000000ffff        /* kernel 4GB data at 0x00000000 */
> -
> -/*
> - * The Global Descriptor Table contains 28 quadwords, per-CPU.
> - */
> -     .align L1_CACHE_BYTES
> -ENTRY(cpu_gdt_table)
>       .quad 0x0000000000000000        /* NULL descriptor */
>       .quad 0x0000000000000000        /* 0x0b reserved */
> -     .quad 0x0000000000000000        /* 0x13 reserved */
> -     .quad 0x0000000000000000        /* 0x1b reserved */
> +     .quad 0x00cf9a000000ffff        /* boot: 4GB code at 0x00000000 */
> +     .quad 0x00cf92000000ffff        /* boot: 4GB data at 0x00000000 */
>       .quad 0x0000000000000000        /* 0x20 unused */
>       .quad 0x0000000000000000        /* 0x28 unused */
>       .quad 0x0000000000000000        /* 0x33 TLS entry 1 */

actually, the reason for the small boot GDT was that some systems 
wouldnt even boot with a larger GDT. (there was some BIOS interaction, 
forgot what it was - iirc it was mach-visws and also some other older 
box)

the 'simplification' you do here is actually how Linux worked before it 
was fixed for those systems.

so i'd be quite nervous to touch this area of the GDT code. (I'd support 
a renaming though, gdt_table is indeed ugly.)

        Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to