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

[David Given <dg@cowlark.com>]

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]