All of lore.kernel.org
 help / color / mirror / Atom feed
From: Coywolf Qi Hunt <coywolf@lovecn.org>
To: root@chaos.analogic.com
Cc: Riley@Williams.Name, davej@codemonkey.org.uk, hpa@zytor.com,
	Linux kernel <Linux-Kernel@vger.kernel.org>
Subject: { Linux not only practical, but an ideal. } Re: [PATCH 2.4.24] Fix GDT limit in setup.S
Date: Thu, 19 Feb 2004 16:33:11 +0800	[thread overview]
Message-ID: <403474C7.5020304@lovecn.org> (raw)
In-Reply-To: <40340EF4.4050409@greatcn.org>

Coywolf Qi Hunt wrote:

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

Hello Richard B. Johnson,

I've just find out where the problem lying in your answer, that you are
not talking the same thing as i am. You are talking about the descriptor 
on which you are quite correct, while I am talking about GDTR, similar 
to selector, but not selector, could be called `selector' in GDTR. Two 
different things.


To All Hackers,

plz take my patch to make our kernel more perfect. Linux should be not 
only practical, but an ideal. And i have more such patches to send.


Regards,
Coywolf


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


  reply	other threads:[~2004-02-19  8:40 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
2004-02-19  8:33     ` Coywolf Qi Hunt [this message]
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=403474C7.5020304@lovecn.org \
    --to=coywolf@lovecn.org \
    --cc=Linux-Kernel@vger.kernel.org \
    --cc=Riley@Williams.Name \
    --cc=davej@codemonkey.org.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.