From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Given Subject: Re: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas] Date: Wed, 26 May 2004 17:49:42 +0100 Sender: linux-8086-owner@vger.kernel.org Message-ID: <200405261749.42017.dg@cowlark.com> References: <20040526115733.GQ12951@vega.vega.lgb.hu> <200405261517.47059.dg@cowlark.com> <20040526151030.GC15905@vega.vega.lgb.hu> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20040526151030.GC15905@vega.vega.lgb.hu> Content-Disposition: inline List-Id: Content-Type: text/plain; charset="iso-8859-1" To: linux-8086@vger.kernel.org On Wednesday 26 May 2004 16:10, G=E1bor L=E9n=E1rt wrote: > However, > in my 286OS (which source was destroyed several years ago, when my si= ster > 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 segm= ents=20 that have changed... you can't execute any user code until the segments= have=20 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 cod= e > 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=20 something like this. Except from C, and only allowing a single extra se= gment=20 (so that the user process never concerns itself with the contents of ES= ). I=20 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'=20 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=20 single-segment code and multi-segment code. If you want to use more than one extra segment, however, you end up wit= h=20 exactly the same problem as before --- the kernel doesn't know where th= e=20 segment addresses are in the app's address space. Giving the kernel a p= ointer=20 to where it's stored is really, really ugly. Perhaps a better approach would be to have the kernel mediate all this;= use=20 syscalls to tell the kernel to allocate out-of-process memory. (Or, act= ually,=20 a device driver would be better because then it would all get cleared u= p=20 automatically when the process exits.) { int handle1 =3D allocate_buffer(48*1024); /* request 48kB buffer area = */ int handle2 =3D 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=20 from one buffer to another buffer (unless you were to implement another= =20 syscall so the kernel did it). Ideally you don't want your user process playing with the segment regis= ters.=20 Ever. That way lies madness, and horrible bugs when, e.g., the compiler= =20 decides to cache a selector on the stack without telling you, and the k= ernel=20 changes the selector without updating the version on the stack... --=20 +- David Given --McQ-+=20 | dg@cowlark.com | Wholesale theft is the sincerest form of flatter= y. | (dg@tao-group.com) |=20 +- www.cowlark.com --+=20 - To unsubscribe from this list: send the line "unsubscribe linux-8086" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html