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

Gábor Lénárt
2004-05-26T13:06:18Z

On Wed, May 26, 2004 at 02:39:44PM +0200, Mario Premke wrote:
> > 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
>
> If a stupid real mode program can't recognize being run in pmode it could be

No, it's not stupidity at all, I think it should be a RULE, not to depend on
the 'subarchitecture' (8086_real vs 80286_pmode) at all! Because it allows
an ELKS/8086 sw can run on ELKS/286_mode system, I mean binary
compatibility. Of course it may be wrong for kernel API compatibility (where
eg in memory layer there are big differences), but it's another issue.

> possible to develop 286-pmode for ELKS without changing the rest of the
> system (user space programs) in the first place (anyway there are only 64k
> data + 64k text programs currently)

Exactly. Sure, the system initalization (switching into protected mode), the
pmode dependent architecture (exception handlers, descriptor table
management, memory layer etc) should be different, but otherwise in case of
GOOD design the other parts of the system (and the user space) even needn't
know about the fact that this is ELKS protected mode or ELKS real mode ...

> When it comes to far pointers you must use a selector which number
> correspondens to the segment adress of the far pointer in the real mode

Since "far pointers" are consists of a "selector" and an "offset" part and
"selector" part is ALWAYS requested/queried/etc by the system (which is
a smaller part of the kernel which actually KNOWS about pmode/real mode
difference of course) the requestor needn't know about the details on this
topic, period. I mean something similar (only pseudo syntax though!!):

far char *p=sys_far_malloc(4096);

Where far_malloc() should some syscall or whatever to the system which
allocates 4096 bytes long segment SOMEWHERE. The returned far pointer
is a 4 byte value in type: a word descibing the segment, and a word
describing the offset (probably zero here). Then you can refeer the
memory, like:

*(p+2)=1;

This should set byte at SEG:(OFS+2) where SEG and OFS are values originated
by the memory layer when far_sys_malloc() was called. So the trick is memory
layer knows about the REAL meaning of "SEG", but our application shouldn't,
it should only blindly trust in this value, and not assume that it means
anything (like the phys_address/16 at 8086).

Attention! *(p+4096)=1 in ELKS/pmode would trigger a memory protection
exception (over the size of the segment) while in ELKS/8086 it simply
overwrites something which shouldn't be overwritten, but we haven't got
better idea, since there is no hw level protection and we want to allow
to use smaller segments than 64K as well ...

In a nutshell: segments should be considered as read-only values after
getting them from the system.

> program independly of the actual memory position the descriptor points to -
> if I get it right ...

Right. Do you have any problem with this theory or it was only a summary of
my brainstorming written in bad English? ;-)

- 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