On Sun, 24 Jan 1999, Greg Haerr wrote:
> 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.
Yeah, that makes sense...
>
> 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?
>
That sounds feasable. In fact it's probably a good first use of
the memory, before implementing swap to pmode memory. (Which isn't too
much work, either)
> 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.
>
Good job...
> In regards the your comment about the 32k DS problem, I didn't follow you.
> What's the current problem and your proposed solution?
>
Al's mentioned that even processes which use very little DS take
up 32K which is bad in real mode. The e-mail mentioned a possible
re-orginzation.
- Chad
> 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
> >
> >
>
