public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Coywolf Qi Hunt <coywolf@greatcn.org>
To: root@chaos.analogic.com
Cc: Riley@Williams.Name, davej@suse.de, hpa@zytor.com,
	Linux kernel <Linux-Kernel@vger.kernel.org>
Subject: Re: [PATCH 2.4.24] Fix GDT limit in setup.S
Date: Thu, 19 Feb 2004 09:18:44 +0800	[thread overview]
Message-ID: <40340EF4.4050409@greatcn.org> (raw)
In-Reply-To: <Pine.LNX.4.53.0402161504490.15476@chaos>

Richard B. Johnson wrote:

> On Tue, 17 Feb 2004, 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.
>>
> 
> 
> The first element has nothing to do with the number of GDT entries.
> It represents the LIMIT. Because the granularity bit is
> set meaning 4 kilobyte pages and 0x8000 * 0x1000  = 0x8000000
>                                       |      |
>                                       |      |_______ Page size
>                                       |______________ GDT value
> This is the size of address space that is unity-mapped for boot.
> 
> The granularity is also not the number of GDT entries. It
> represents the length for which the GDT definition applies.
> 
> Because this GDT is used only for booting, somebody decided that
> there would never be any boot code beyond 2 GB so there was no
> reason to make room for it. If you change the number to 0x0800,
> you are declaring that neither the boot code nor any RAM-disk
> combination will ever exceed 0x800 * 0x1000 = 0x800000 bytes.
> Therefore you broke my imbedded system. Do not do this.
> 
> 
>>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
>>

Thank you for you kindly reply, though I really don not agree with you.
But thanks very much, since you are the only one replying me. I CCed to
all the 2.0 2.2 2.4 maintainers.


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


  parent reply	other threads:[~2004-02-19  1:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-16 19:07 [PATCH 2.4.24] Fix GDT limit in setup.S Coywolf Qi Hunt
2004-02-16 20:44 ` Richard B. Johnson
2004-02-19  0:54   ` Coywolf Qi Hunt
2004-02-19  1:18   ` Coywolf Qi Hunt [this message]
2004-02-19  8:33     ` { Linux not only practical, but an ideal. } " Coywolf Qi Hunt
2004-02-17  3:51 ` [2.0.40 2.2.25 2.4.25] Fix boot GDT limit 0x800 to 0x7ff in setup.S or not Coywolf Qi Hunt
2004-02-21  3:39   ` Coywolf Qi Hunt
2004-02-21  4:12     ` H. Peter Anvin
2004-02-23  5:30       ` Coywolf Qi Hunt
2004-02-23 14:02 ` [PATCH] Fix GDT limit in setup.S for 2.0 and 2.2 Coywolf Qi Hunt
2004-02-23 14:21   ` David Weinehall
2004-02-25  0:10     ` Pavel Machek
2004-02-23 14:43   ` Richard B. Johnson
2004-02-23 15:28     ` Richard B. Johnson
2004-02-23 16:21       ` Richard B. Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40340EF4.4050409@greatcn.org \
    --to=coywolf@greatcn.org \
    --cc=Linux-Kernel@vger.kernel.org \
    --cc=Riley@Williams.Name \
    --cc=davej@suse.de \
    --cc=hpa@zytor.com \
    --cc=root@chaos.analogic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox