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

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

Re,

On Wed, May 26, 2004 at 02:19:54PM -0300, Eduardo Pereira Habkost wrote:
[...]
> > 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!
>
> Erm... shouldn't be this exactly the task of the scheduler? Simply the
> scheduler should be sure that the segment registers are updated and

Yes, but what's up if a user space program stores a 'far pointer' in the
memory? scheduler changes content of the segment registers, but scheduler
will NOT know that the user space programs use eg an array of far pointers
which should be altered as well etc ... The only way to workaround this
problem is let the process to do it if it want to use multi segment model
anyway though it's know to be ugly, sure :) But if it REALLY wants ? ;-)

> data is in the right place before switching to user code again. Before
> returning to the user process, the structure storing the 'context' will
> be updated before returning to user context. I think I didn't get what
> is the point.

Yes, I see, so the situation here is not the content of segment registers
but other registers and memory locations stores segment IDs by the user
space process itself perhaps as the part of far pointers or such ...

> I was thinking on this, too: things will be simpler if we explicitly
> state that user processes cannot touch the segment registers.

Sure you're right. But I think we should not reject to write multisegment
apps. To keep kernel simple, we can let the large amount of the complexity
to the user space, so we can say: "hey, if you really wanna do this mess
multisegment madness, you should write app with segidchange sighandlers
etc. so you have been warned but you CAN do it if you REALLY need this
stuff".

[...]
> If someday the compiler is supposed to support 'far' pointers, we could
> use them, but instead of storing the ES value on the pointer, and updating
> ES before accessing data, store the buffer handle on the pointer and call
> use_buffer() before using it. Yes, more expensive than simply setting
> the ES register, but would allow the OS to move the data, if needed.
>
> And that would be compatible with 286pmode, too. The difference is that
> on 286, we would need fewer copy operations, and fewer segment register
> changing. And if we want to have 286pmode-only, but slightly faster,

In 286 pmode even a multi segment process is relocatable, since kernel
can change the base address of the segment without changing the segment
IDs (called selectors in pmode), which is NOT true for real mode (and
this is the exact reason of my signal notification theory: to allow kernel
to reallocate a segment of a multi segment mode user space program while
running, so allow to defragment memory which can be done ie a kernel thread
or something similar which runs on IDLE or at out-of-enough-continous memory
situations).

- 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