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

David Given
2004-05-26T23:19:48Z

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]