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

David Given
2004-05-26T16:49:42Z

On Wednesday 26 May 2004 16:10, Gábor Lénárt wrote:
> However,
> 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!

[...]
> But you can assume that its
> assembly programmer say: OK, CS (code segment register) points to code
> segment, DS (data segment register) points to data segment *AND* ES (extra
> segment register) points to the ACTUAL user data segment.

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:

{
resize_buffer(32*1024); /* request 32kB buffer area */
copy_from_buffer(data, 2*1024, 32); /* copy 32 bytes to data from 2kB
into buffer area */
}

However, I didn't mention it because I had vague memories that part of ELKS'
libc uses ES for some of its loops, and wanted to check on that.

But yeah, that would work. It might make a suitable compromise between
single-segment code and multi-segment code.

If you want to use more than one extra segment, however, you end up with
exactly the same problem as before --- the kernel doesn't know where the
segment addresses are in the app's address space. Giving the kernel a pointer
to where it's stored is really, really ugly.

Perhaps a better approach would be to have the kernel mediate all this; use
syscalls to tell the kernel to allocate out-of-process memory. (Or, actually,
a device driver would be better because then it would all get cleared up
automatically when the process exits.)

{
int handle1 = allocate_buffer(48*1024); /* request 48kB buffer area */
int handle2 = allocate_buffer(48*1024); /* and another one */

use_buffer(handle1); /* tell the kernel to look up what selector
handle1 refers to and set it to ES */
copy_from_buffer(data, 2*1024, 32);
use_buffer(handle2);
copy_to_buffer(3*1024, data, 32);
}

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...

--
+- David Given --McQ-+
| dg@cowlark.com | Wholesale theft is the sincerest form of flattery.
| (dg@tao-group.com) |
+- www.cowlark.com --+
-
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