(delurking for a short time... I'm still on the list, just haven't
put any time into things for a _long_ time... I think things are
progressing quite well though.)
> 1. Currently the ELKS low level interrupt processing seems to
> work great. I've never had it crash when just sitting around or running
> a debugged program. However, the file system crashes regularly. The
> following items could be worked on:
> a. remove 519K file size limit (ie. implement indirect block lookup)
My fault. :) When I was working on getting file I/O up at any
level under ELKS I was using a real PC with 360K drives. Ergo I was too
short-sighted to add double indirect block setup. :) Also this could be
potentially touchy if too much file I/O is going on, in theory if this
wasn't done quite right and things were too busy there would be
considerable thrashing as the block with the indirect buffers gets
constantly reloaded. Such loads are needless to say somewhat unlikely.
> b. file redirection from the shell doesn't work well (kernel or libc? )
This could be a part of (c) since one of the ways to do this is to
use pipes.
> c. pipes don't work well (probably kernel bug)
I'm not familiar with the way pipes were implemented, and I dunno
if this was fixed in .74, but there are probably always going to be
memory-related limitations. E.g. you _really_ don't want too many pipes
bigger than >1K.
> d. crashes after rm, bad block numbers in fs (I think Alistair may have
> just fixed this in 0.0.74)
>
Al said it was fixed...
> A big question here: why was the minix fs rewritten for ELKS, rather
> than just using the linux-386 code? I realize there was good reason for
> the buffer rewrites, because of 86 model considerations, but the
> original linux minix fs code works.
The fs code wasn't rewritten, just reworked. :) Basically it was
the result of much hacking by Alan, myself, and Al. (And anyone else I
forgot.) The two-level buffer setup was put in to minimze code changes
and get enough space for the system to work adequetly. There is a
performance flaw in this in that the buffer is recopied. Not too
noticible on a fast system, but on an 8086 (or the closest currently made
equivalent, a P6-gen CPU with both L1+L2 turned off :) it does have an
effect.
Other things, while I'm de-lurked:
- A possible alternative to the current DS setup (with the 32K
problem) might be:
2-16 byte magic at 0x0000. (Useful for null pointer writes, etc.)
stack (2-4K, changed at link time only)
data+BSS
chmem area (adjustable after link)
- bcc in 64K would be really nifty. An optimizer would also be
nice. Even as is bcc is (a) usable, ELKS code is already set up to work
with it, and (b) it's free. When you put those two together bcc becomes
very valuable in spite of it's shortcomings.
- 286 protected mode would be absolutely nifty... it's a matter of
writing direct hardware drives which are both real and PM mode compatible
and the PM code itself. I never even dared it, but it's certainly
do-able. Done right it would even help the real mode version.
- Using the BIOS calls to get memory from pmode is also possible,
and it would be a sort of fast swap system. EMM code is doable too but
you need hardware specs and AFAIK there are no new ISA EMM boards in
production. I doubt the memory that went on them is even in production now.
That's all I can think of at the moment... back to lurking :)
- Chad
