Greg Haerr writes:
>
> Al,
> I spent a good portion of the weekend fixing quite a few ELKS
> bugs, trying to get a good visual editor running. It seems I have succeeded.
> Following is the list of fixes that I have performed. I will attach in the next
> email the patches for elks 0.77 and elkscmd 0.77.
>
> o Ported elvis to ELKS
Is this based on the code that was in elkscmd?
> o changed all elkscmd srcs to use tcsetattr/tcgetattr instead of ioctl
I previously held back from doing this to make the minimal size saving, but
I guess it is not significant.
> o added /etc/termcap to elks distribution with elks terminal type
> BTW, the ansi elks console doesn't work. I can rewrite it quickly if nobody minds.
> The new elks terminal type "elks" is mostly vt52. I think it should be ansi.
> vt52 doesn't support attributes, and elvis needs at least reverse video.
Okay, we can make anis the standard one. People should still be able to
drop back to vt52 if they want a mimal cursor addressabel terminal. DOn't
remove that capabiltiy.
> o fixed nasty kernel mm_dup bug. When elks kernel does
> an fork(), it copies the data segment minus two bytes (why? for 64k overflow?)
> In any case, this resulted in the last user space environment variable getting
> smaller with each program execution. This bug took 5 hours to find.
I have spent ages trying to work out what was messing up the environment.
Well done.
>In the meantime,
> I found that the libc putenv() is completely buggy and doesn't work. I will rewrite
> this soon.
> o added TERM=elks to /bin/login exported environment.
> o added setenv and printenv to internal sash commands.
Please don't commit too much effort into sash. I don't really think it is
worth it. We need a proper shell, and ash is a much better candidate.
> o fixed nasty elks brk() bug. It turns out that elks never worked
> for any executable requesting the brk address > 32767. When the number reached
> 16 bits, the value was interpreted as a negative number and refused. This caused
> malloc() to fail in the user program. This is why elvis, as86, and many, many other
> large programs have never run. Elks never let programs have > 32k data segments!
> With this fix, I plan on self-hosting bcc and as86, which now will run...
I am sure I have had programs with larger data segments that 32K running
before. It sounds like brk() would not allow the data segment to grow to
more than 32K. Again, well done. This is a major breakthrough.
> o fixed ICANON bug in tty driver. Rawmode didn't work in elks. It does now.
> o added hardware bell to elks. When '\007' is written to a tty file
> descriptor, the pc speaker now rings at 800hz. The frequency is adjustable
> if anyone likes different bell frequencies.
Cool.
>
> Still to do:
> o fmemset() not implemented, workaround code in kernel is way slow.
> o all string functions need rewriting, the libc code is *really* slow. I will
> rewrite both of these in assembly for speed, using word moves etc.
> o putenv() needs total rewrite.
> o execve() code is too large
> o kernel sched algorithm could use a rewrite
> o dircon and bios tty drivers could use some massaging for vt52/ansi.
> o floppy driver is slow, should read sectors at full speed.
>
All sounds worthwhile. Thanks for letting everyone know what you are
working on (I know I am bad at this).
I think that a kernel release is called for before any more work gets done.
I hope I will be able to release it tomorrow.
Al
