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

[Andrey Romanenko <bigral@i.com.ua>]

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