From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Given Subject: Re: AW: [Fwd: Re: EDE - Personal Suggestions and Ideas] Date: Thu, 27 May 2004 00:19:48 +0100 Sender: linux-8086-owner@vger.kernel.org Message-ID: <40B52614.10908@cowlark.com> References: <20040526115733.GQ12951@vega.vega.lgb.hu> <200405261517.47059.dg@cowlark.com> <20040526151030.GC15905@vega.vega.lgb.hu> <200405261749.42017.dg@cowlark.com> <40B4D6F9.4070507@i.com.ua> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <40B4D6F9.4070507@i.com.ua> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux-8086@vger.kernel.org Andrey Romanenko wrote: [...] > by this code you just change one user-mode process memory manamgent by > athother one - same mistake. Ah, no. All this code is doing is accessing memory with ES. Actually setting up ES is strictly the job of the kernel. The user code doesn't know what's in ES, doesn't care, shouldn't even be looking. [...] >> 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. >> > seems :) you very like the idea to give task of memory managment to > user-mode process, isn't it? Uh, no. The exact opposite. People have said that the 64kB RAM limit of a process is too small; I'm trying to come up with a technique of quickly accessing more than 64kB of memory *without* resorting to the big, slow, insecure, dangerous and ugly technique of far pointers and multisegment executables. What I'm suggesting is a compromise that will allow us to keep the 16-bit pointers and clean design of the existing system, and also allow us to quickly access another 64kB of memory that's outside the process' own address space. Yes, the same effect could be performed using temporary files. But temporary files are *really slow*. In order to copy data out of a temporary file, you have to actually wait for the disk to move. Copying out of ES can be done in about four instructions. Frankly, I'd rather do without it completely --- I'm sure you're all sick of hearing me say that an application that needs more than 64kB of RAM is too big on ELKS. But this would give the option of fast access to another 64kB in a clean way that doesn't break the existing design --- should anyone want it... -- [insert interesting .sig here]