Chad,
Thanks for commenting on my msg. In regards to
thrashing because of double or triple indirect block lookup,
that can be easily solved by placing data blocks on the LRU
end of the buffer queue, and putting inode and indirect blocks
on the MRU end.
Also, your point about using bios to get memory from pmode
would allow us to use a fancier scheme (like the existing linux kernel's)
where the kernel uses all available ram for buffers, until user program
memory requests demand it. Do we have to be running in pmode
in order to get other memory? Or is that what the EMM specs are
for?
I've gotten bcc to run in 64k (actually 128k) with the -Mf option. The code
segment is 62k, so we're getting close to the limit. I'm working on getting
everything
to run in 128k split I/D on the target host. I totally agree that bcc is
the way
to go, because it seems to be the best small free C compiler.
In regards the your comment about the 32k DS problem, I didn't follow you.
What's the current problem and your proposed solution?
Greg
[EMAIL PROTECTED]
-----Original Message-----
From: Chad Page <[EMAIL PROTECTED]>
To: Greg Haerr <[EMAIL PROTECTED]>
Cc: '[EMAIL PROTECTED]' <[EMAIL PROTECTED]>; '[EMAIL PROTECTED]'
<[EMAIL PROTECTED]>
Date: Sunday, January 24, 1999 4:17 PM
Subject: Re: ELKS development ideas
>
> (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
>
>
