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

[David Given <dg@cowlark.com>]

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