Greg Haerr writes:
>
> I have come up with the following ideas that I think ELKS needs. I am prepared
> to undertake all these, but thought I'd post to see if anyone else is interested
> or has any comments whatever...
>
> 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)
> b. file redirection from the shell doesn't work well (kernel or libc? )
> c. pipes don't work well (probably kernel bug)
> d. crashes after rm, bad block numbers in fs (I think Alistair may
> have just fixed this in 0.0.74)
Get 0.0.74. The minix fs stuff in 0.0.73 was very broken due to broken
bit operations. See BUGS file in the 0.0.74 source tree for details of how
I debugged this code.
>
> 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.
It wasn't re-written very much. The way we handle the inode structure was
modified to make it more memory efficient, and the minix V2 support was
removed as it was excessive. Many functions in the elks minixfs code are
completely unchanged from the Linux versions (other than conversion to K&R
style).
>
> 2. Movement toward self hosting bcc, as86, and ld86. I'm working on this
> and have gotten several comments from Rob deBath and Alistair. Thanks. Hopefully
> the 64k cseg and dseg limits won't kill us. Bcc requires -Mf to link.
Self-hosting is a great ideal, and a very good way of thrashing bugs out of
the system. Certainly worth investing some time into.
>
> 3. What about the idea of adding "char _far *" support to BCC? This would
> be relatively easy, and allow far pointer addressing while still keeping totally
> 8086 compatible, and running in small model. Initial support would include just
> pointer declaration and reference, not necesarily compares, etc.
> Also, I would like to add the C++ "//" command syntax.
> Making the compiler ansi-prototype compliant would be a huge step forward.
> With an existing #define, the compiler will compile ansi prototypes. I don't think
> it will automatically perform function parameter type casting, which is what's
>really needed.
I would prefer to keep the compiler clean myself. The segmented nature of
elks at the moment makes the whole system much easier to deal with, make
swapping possible, and I don't think we gain enough from using far
pointers to make it worth while. The main problem at the moment is that
most processes are wasting huge ammounts of data memory because the large
default chmem value, and the annoying way the data segment has to be layed
out. Having a half-ansi compiler is just confusing. A tool which checks
that functions are being used with the correct number of paramaters woudl
be very useful, and easier to do than such a fundamental modification to
the compiler.
>
> 4. Build a standard distribution from the dev86, elks and elkscmds efforts that
> completely compiles itself, then produces boot floppies for floppy and hd based
>systems
> that then runs only the code that was just compiled.
>
I think the three belong as individual packages, but elks and elkscmd need
to be tied more closely together. The contents of elkscmd are of no use to
anyone else.
Al
