From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrey Romanenko Subject: Re: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas] Date: Wed, 26 May 2004 19:00:30 +0300 Sender: linux-8086-owner@vger.kernel.org Message-ID: <40B4BF1E.6080004@i.com.ua> References: <20040526115733.GQ12951@vega.vega.lgb.hu> <20040526130618.GY12951@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> List-Id: Content-Type: text/plain; charset="iso-8859-1"; format="flowed" To: linux-8086@vger.kernel.org Hi there, G=E1bor L=E9n=E1rt wrote: >So my ONLY though with this long novel ;-) -> at least we should provi= de >the possibility for multi segment processes ... Sure, at startup proce= ss >shoulde REQUIRE kernel for multi segment mode. In this way there is no >slowdown or other resource bottleneck of this scheme if we don't want = it. >But if we want it, kernel prepares eg the above described signaling >machanism and other stuffs I was talking about. > =20 > I think all this "novel" sounds very resonable. We have vast of sources= =20 on the NET written with this 64kb segments in mind (yes those old=20 sources still may be very useful for ELKS -GEM,libraries and so on.);=20 Besides, there is FreeDOS project full of usable for our situation=20 goodies. From the other hand we have MINIX and UZIX utilities sources=20 that small enough to be compiled as 2 segment executables - so we need=20 to keep existing executable schema. Eventually, guys look at OLD DOS -=20 this operating system started with COM files and than moved forward to=20 all those exotic mamory models available - that seems absolutely natura= l=20 way. I've got also question about proposed solution for segment base address= =20 changing by SIGNALs. Is there another way of managing this? Lets say=20 user process upon memory allocation forced to "register" all places=20 where it plan to keep 16bit segment address (CPU registers or memory=20 locations) and kernel changes all those values upon process context=20 loading according to current situation. It seems to me that all system=20 related tasks should be performed by kernel but not by user process (th= e=20 memory managment such a task). thanks, Andrey - 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