Hi again! :)
On Fri, 4 Dec 1998, David Murn wrote:
> On Thu, 3 Dec 1998, Alan Cox wrote:
>
> > > The big problem isn't so much the binary, but the amount of RAM it needs
> > > at runtime. From memory, it chews up several hundred k of ram.
And the fact that the code segment is over 64K?
> > Time to write some swapping code
A swapping and virutal memory system (if possible) would I think let one
run programs that require more memory than there actually is... Perhaps
even a binary with a code segment of more than 64K? :)
> Swapping isn't the whole issue here. The excessive memory use is.
Nod, indeed, both seem to be issues. With swapping and enough swap space
though, excessive memory use is possible but of course clashes with
performance :)
Is there code in ELKS to swap to the disk? I couldn't find any but I
didn't look very hard.. There was a little comment in mm_alloc()
mentioning to "later check priority and swap"
This is an *interesting* thread, so many cool ideas! Maybe we will see
ELKS able to compile itself someday, that would really be groovy! :)
Hrm, something else I was thinking about and but is probably wistful...
I read somewhere a long time ago in some DOS internals book that there
was this simple formula to convert seg:offset addresses to a linear
address... But a linear address space would be a *lot* of work to
implement on the 8086 architecture, wouldn't it?
I apologize for my rather useless ideas and no code...
Is anybody working on a FAT filesystem, BTW... ? I might (keyword: might)
make an attempt at it although I've never done any real kernel
programming before.. I'd have to wait 'til school calms down some as well...
Anyway, lotsa kudos to Alistair Riddoch for all the work on the new
kernel release... ELKS now handles a serial console, neat!
Have a nice day everybody! :)
