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

Andrey Romanenko
2004-05-26T17:42:17Z

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