Re: [2.0.40 2.2.25 2.4.25] Fix boot GDT limit 0x800 to 0x7ff in setup.Sor not

[Coywolf Qi Hunt]

Coywolf Qi Hunt wrote:
> Coywolf Qi Hunt wrote:
>
> > Hello 2.4.xx hackers,
> >
> > In setup.S, i feel like that the gdt limit 0x8000 is not proper and it 
> > should be 0x800.  How came 0x800 into 0x8000 in 2.4.xx code?  Is there 
> > a story?  It shouldn't be a careless typo. 256 gdt entries should be 
> > enough and since it's boot gdt, 256 is ok even if the code is run on 
> > SMP with 64 cpus.
> > At least the comment doesn't match the code. Either fix the code or 
> > fix the comment.  We really needn't so many GDT entries. Let's use the 
> > intel segmentation in a most limited way. Below follows a patch fixing 
> > the code.
> >
> > I don't have the latest 2.4.24, but setup.S isn't changed from 2.4.23 
> > to 2.4.24.
> >
> > Regards, Coywolf
> >
> > ------------------------------------------------------------------------
> >
> > --- arch/i386/boot/setup.S.orig    2003-11-29 02:26:20.000000000 +0800
> > +++ arch/i386/boot/setup.S    2004-02-17 01:15:42.000000000 +0800
> > @@ -1093,7 +1093,7 @@
> >     .word    0                # idt limit = 0
> >     .word    0, 0                # idt base = 0L
> > gdt_48:
> > -    .word    0x8000                # gdt limit=2048,
> > +    .word    0x800                # gdt limit=2048,
> >                         #  256 GDT entries
> >
> >     .word    0, 0                # gdt base (filled in later)
> >
> >  
>
> Hello all hackers, from 2.0 to 2.4,
>
> In setup.S,  from the very beginning (in boot/boot.s for 0.01 kernel),
> all boot GDT limits are set to 0x800. GDT limit is the LIMIT, not SIZE.
> So all these 0x800 should be 0x7ff. And actually in the current 2.4.24,
> it is even an odd 0x8000 which I previously just sent a patch to fix to
> 0x800. But it should be set to 0x7ff really.  Until now only 2.6 sets it
> properly. Although these will never cause any runtime problem at all,
> they are ugly. Please consider fix them.
>
> Since it is always 0x800, i even get used to 0x800 rather then the
> proper 0x7ff. If leave it 0x800, it's useful to distinguish the boot GDT
> from the later final GDT setting in arch/i386/kernel/head.S. So fix it
> or not.
>
>
> Regards,
> Coywolf

hello,

Since still no one cares, here follows a cut from the intel bible which
every one should show his RESPECT to.


IA-32 Intel Architecture Software Developer's Manual
Volume 3: System Programming Guide
3.5.1. Segment Descriptor Tables
3-17 Page:81

"Because segment descriptors are always 8 bytes long, the GDT limit 
should always be one less than an integral multiple of eight(that is, 
8N-1)."


Please fix 0x8000 to 0x800 in 2.4, and 0x800 to 0x7ff in 2.0~2.4, ok?
This is my last appeal.


Coywolf


--
Coywolf Qi Hunt
Admin of http://GreatCN.org and http://LoveCN.org

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