Re: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas]

Gábor Lénárt
2004-05-26T11:57:33Z

Hello,

On Wed, May 26, 2004 at 01:43:03PM +0200, Mario Premke wrote:
> > Why? On 16 bit protected mode (80286) you CAN alter the starting
> > address of
> > a segment while refeering the same selector before and after this action
> > (this is because in protected mode the segment register only contains a
> > 'selector' which is an index in the descriptor table which describes the
> > segment). Sure, real mode does not allow this, because in real mode the
> > content of the segment register is simply the starting address of the
> > segment divided by 16, allowing maximum of 1Mb address space
>
> Is it possible to use the the content of the segment register in real mode
> as a selector in protected mode - so assuming GDT and possibly LDT are
> properly set up, would a real mode program run in protected mode?

Ehhm, I see. Sorry I did not understand your point.

OK, now I see, but I haven't got the point. I mean, if you have a syscall or
whatever to allocate a memory as a separate segment, you would get a 16 bit
ID which can be load in the segment register. And this is NOTHING for a user
space application that this is real mode segment register contant (so real
address divided by 16) or a selector in pmode, user app should only load
this number into the segment register. In this way (if we don't allow a user
app to caculate segment register values only allow to get these values from
the OS) user space program does not need to now ANYTHING about the real
connection between the memory and the content of a segment register. It's up
to the kernel. If you do this right, a 8086 ELKS program should also run in
ELKS for 286-protected-mode. The only need - as I've described below - that
values used to load into segment registers are 'allocated', 'queried' etc
from the OS so there is no assumption about the "real meaning" of the value
used to load into segment registers. Sorry my English is not so good, but
maybe I was able to describe the theory of mine.

Using 286 pmode also gives some nice features. Like memory defragmentation.
I mean, allocating several memory blocks than freeing some may result in
having enough memory but not disallowing allocation of large memory block
because not enough continuous memory block. In 8086 (real) mode there is
nothing to do here, since we can't move memory blocks: we have already
give segments register values to user space programs which values have got
direct meaning for the starting address of the segment in real mode (OK
maybe some VERY ugly trick can be done: we provide a mechanism to send
signal or whatever to user space program to recalibrate all of its segment
allocations but this would be VERY VERY VERY ugly and complex and also
it's very far from the C and UNIX way, I think ...). But in 286 protected
mode, you can alter the starting address of the segment without chaning the
descriptor value which refeers the segment itself. The only need is a memory
defragmention kernel daemon or something similar which copies the memory
and then alter the descriptor table. Sure, some locking should be provided
to avoid to run of the process whose memory region is being moved.

- Gábor (larta'H)
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html