On 26-04-08 12:16, Andreas Leppert wrote:
Please do not set Mail-Followup-To or Reply-To headers when posting to linux
related mailing lists. They turn CCs into To for one, possibly screwing over
people's mail filters. Many people in this environment get upto thousands of
messages per day through various lists and filtering them to various message
boxes (and copies of mail from threads you're in to your inbox instead of
the list folder) is very much desired.
I'm reading "Understanding the Linux Kernel - 2nd Edition" and have some
problems with Chapter 2 - memory addressing.
1) Segmentation: Each time a logical address is loaded into a segmentation
register, the corresponding segment descriptor is loaded into a
non-programmable register. The segment descriptor tells me the linear
start address of the segment.
"Accesses to the GDT or LDT are necessary only when the contents of the
segmentation register change". When does this situation appears? I mean
if I have another logical address it is loaded into the segmentation
register and the corresponding segment descriptor is loaded
automatically.
No... a logical address in this sense is a 48-bit address, but you address
using only 32-bits of it -- 16 are taken from an existing segment register
implicitly. For example, a data reference (usually) takes the "ds" segment
register as the base register and an instruction such as:
mov eax, [esi]
loads eax with the 32-bit value at address ds:esi. There's nothing automatic
about the "ds" bit though. It contains whichever selector was loaded into it
last and the segment descriptor that belongs to that selector provides the
base address to add to the esi register to arrive at the address.
For some data referencing instructions (notably those that address through
esp or ebp) not ds but ss is the implicitly used segment selector, es is
used as the implicit destination for the stos and movs string instructions
and cs is the implicit segment selector for code references such as jmp
targets. You can override the implicit segment selectors by explicit segment
override prefix bytes to the instructions.
Nothing's automatic about them -- only implicit.
Why should I change the segmentation register which contains the segment
selector? Could you provide some examples?
Well, in Linux, you actually generally shouldn't, since Linux (to the degree
possible) doesn't use segmentation but if you _do_ use segmentation, you
definitely need to make sure that your segment register contains the right
selector for the segment you want to reference.
2) Is it correct that without segments I could not provide privilege levels
(user=3, kernel=0) ? If I haven't overseen anything, there are no flags
in the paging entries.
There are, although only user/kernel. See the "user/supervisor" bit (bit 2)
in the page table entries. In comparison with the segmentation based model
you miss out on ring 1 and 2, but you have 0 and 3 (more specifically you
have 0, 1 and 2 on the one hand and 3 on the other as for page protection
purposes the first three are treated equally).
You might consider this a strange design and you'd be right. Basically, the
IA32 architecture was intended to be used in its segmentation model with the
paging model thrown in as a bonus. VMS seems to have been the most direct
inspiration for the IA32 architecture with the paging model thrown in for
UNIX support specifically. Then ofcourse reality happened and VMS did not
(*) and segmentation sucked for everyone...
Linux doesn't use segmentation either:
3) "The 2.4 version of Linux uses segmentation only when required by the
80x86 architecture. In particular, all processes use the same logical
addresses, so the total number of segments to be defined is quite
limited". Why?
Because there's little point to it -- segmentation is complicated and while
probably not a specific objective originally, slow for example by needing
those selector reloads. You can't disable segmentation in IA32 in the same
way that you can disable paging but Linux basically just creates a single
segment that spans the entire 32-bit addresspace (base=0, limit=4G) and uses
it everywhere. It needs 4 versions of it, with the access rights set up for
kernelmode versus usermode and data versus code, but that's it.
Segment registers can also be needed for things such as APM support (by the
BIOS) and register fs these days is used to address thread local storage (or
was it gs...) and gs might be used for something similar by now but that's
all very non-fundamental. "Doesn't use segmentation" is.
4) I haven't coded in the kernel. But if I have an address (e.g. from a
malloc() return value), what kind of address is this? A 32-bit linear
address, a 48-bit logical address? I do not understand where the 48-bit
addresses are "created" which one needs for segments...
A 32-bit linear address.
I'm a bit confused with the whole paging / segmentation stuff, perhaps
you can help me a bit. Do you have some recommendations (links, books)?
The most important thing is to know that segmentation is not/hardly used
within Linux as above. Other than that, there's probably not much better
available than the IA32 architecture manuals. Just avoid all PSE-36 and PAE
crapola -- that's all just later hacks to expand the IA32 architecure. It
might be best in fact if you could get your hands on an original Intel 386
architecture manual. That way you can learn about the theory without being
distracted by practice too much...
(*) it spawned NT but while I know fairly little about NT design I believe
it was fairly quickly clear that segmentation wasn't all that wonderful for
its uses either. Ofcourse, there also was OS/2, the original version of
which was written for the 286 which didn't _have_ paging, only segmentation.
I believe OS/2 Warp was already using paging fairly exclusively though and
as we now know, OS/2 didn't quite happen either anyway.
Really amazing how a company that over its existence has made so many wrong
guesses has still managed to make so much money. The x86 almost must be the
inspiration for Linux just doing no planning at all... :-/
Regards,
Rene "Potshot" Herman.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
