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 20:42:17 +0300 Sender: linux-8086-owner@vger.kernel.org Message-ID: <40B4D6F9.4070507@i.com.ua> References: <20040526115733.GQ12951@vega.vega.lgb.hu> <200405261517.47059.dg@cowlark.com> <20040526151030.GC15905@vega.vega.lgb.hu> <200405261749.42017.dg@cowlark.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200405261749.42017.dg@cowlark.com> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux-8086@vger.kernel.org Hi David, David Given wrote: >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! > > that is the result of breaking general rule - do not allow user-mode processes to manage kernel tasks :) >{ > 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 */ >} > > by this code you just change one user-mode process memory manamgent by athother one - same mistake. >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. > > WHY??? almost the same situation happens on the real hardware with 386 cpu - difference only that kernel does have another way to acomplish this task (by changing apropriate tables in own memory space); I consider this situation almost equal - we just update locations pointed by process itself insted of those defined by 386cpu architecture. And at the end of the story I see C++ compiler that supports ONLY 32bit pointers and make translation of 32bit-virtual addresses to 8086's xxxx:xxxx - format addresses absolutely invisible for programmer of multi-segment exe module. >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? thanks, Andrey