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

Gábor Lénárt
2004-05-27T09:00:05Z

Re,

On Wed, May 26, 2004 at 05:49:42PM +0100, David Given wrote:
> > in my 286OS (which source was destroyed several years ago, when my sister
> > tries to drink my computer with some cola ...) there was a signaling
> > mechanism and the kernel can notify application that it SHOULD reload
> > segment IDs and this signal is unblockable one. Sure, still ugly, but at
> > least we haven't got reload segment IDs every time ;-)
>
> The only issue with this is, what happens if it's the code or data segments
> that have changed... you can't execute any user code until the segments have
> been updated and you can't update segments without running user code!

Good point :) Maybe user space program should assume that the signal
handler SHOULD BE PLACED in the first code segment and it should use
the first data segment, and before kernel give control to this 'special'
signal handler, CS, SS and DS is aligned to meet this requirement. Or
something similar. Well ...

> Ha! Great minds think alike, and fools seldom differ... I was going to propose
> something like this. Except from C, and only allowing a single extra segment
> (so that the user process never concerns itself with the contents of ES). I
> was going to call it the buffer area and allow you to do things like:

Hmm, yes, but keep in mind, that there is not only C in the world, someone
may write application in assembly for ELKS or whatever ...

[...]
> You'd get fast copying from a buffer to normal data and vice versa, but not
> from one buffer to another buffer (unless you were to implement another
> syscall so the kernel did it).
>
> Ideally you don't want your user process playing with the segment registers.
> Ever. That way lies madness, and horrible bugs when, e.g., the compiler
> decides to cache a selector on the stack without telling you, and the kernel
> changes the selector without updating the version on the stack...

Well, you're talking about the C implementation of a user space program
which uses multi segment memory model. However we can even think that
it's up to the user space ... Maybe only SOME program will use this, maybe
programs aren't written in C at all. And so on. So I think it's out of the
scope now, only the kernel infrastructure should be provided to be able
to write such a program at once ... The only point to open threads on this
topic is the idea, that kernel should be flexible enough to implement
this scheme as well easily.

And IMHO you can't blame ELKS because of some compiler bugs you've
mentioned. An operating system which runs on an architecture without
hw level protection there is no way to protect itself for all of the
possible bugs, so it's up to the compiler bugs as well. However eg in
286 pmode the situation can change. Maybe you should develope in 286 pmode
and test the system, because there is hw protection there which will trigger
exceptions on protection faults. Because of the unique handle of segment IDs
(user space programs should not assume anything about the meaning of segment
IDs) there should be NO difference between running on 286pmode or 8086 real
mode ELKS kernel, but in case of 286 pmode you can use hw protection and
maybe other debugging features as well to test 'bug-ness' of the application
so it does not crash the system on ELKS 8086 either ...

- 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