When are we going to release 0.8.0?

[tyama501]

Hi,

There are huge number of enhancements and bug fixes since 0.7.0 release,
and it has been a while since 0.8.0-dev gets 0.8.0-pre.

When are we going to release 0.8.0?

[ghaerr]

Agreed we need to get 0.8.0 out. I had initially planned on getting it out several months ago, and got part way through the long list of improvements and contributors for a release doc. Then a number of new opportunities came, including OS/2 executables and Watcom support. After that more lots more contributions and I've been writing a lot of code and new bugs found... Some more good programmers have contributed new features and games.

The revision was incremented to v0.8.0-pre3 last week. I have a few more cleanups I'd like to get in. Given ELKS new capability for running games, including Emoria, Snake and Doom, I had thought about the idea of releasing a separate "games" disk, but with Doom it can't be distributed on 1440k floppies.

What does everyone think about what needs to be in v0.8.0? Should it be cut ASAP, do we need to accept contributions that work with it and be made available somewhere else, etc? Or do we just need a stable v0.8.0 so that a downloadable binary is readily available?

I am interested in hearing about what issues matter for this release.

[tyama501]

Well, I haven't thought about the game disk:)
The OpenWatcom version of the ELKSmoria is not ready yet since I have been playing around with other stuff, so it would be the limited version by gcc-ia16.

I think there were several bug fixes and enhancement for FAT file systems.
So I recommend to use new release for
new users.

Anyway let's hear other users comment.

Thank you.

[floriangit]

FWIW, I tested 0.8.0-pre3 (044b2a4) today on my 286 AMD/Intel with HDD and FDD.
First I learned the CMOS battery died. Exchanged and working again. Then the BIOS forgot and needed to know my HDD layout and only has a fixed array of 40 entries or so to select. I selected one that most closely - but not fully at all - matches the sectors/cylinders etc. which are printed on my 40 year old HDD. So my observations might partly be related to that "miss" selection.

• whether I boot from fd0 or from hda1 I always get the warning that my filesystem (Minix) should be fsck'ed. When booted from floppy I ran fsck /dev/hda1 and it exited with 0 without any output. Still when booting hda1 after that, it gives this warning every time.
• after booting from 0.8.0-pre3 from floppy and doing a sys /dev/hda1 I ran once into the printk of elks/arch/i86/drivers/block/bioshd.c:580
• I noticed the wrong source code comment in elks/arch/i86/drivers/block/bioshd.c:551 : it's 5 times, not 3.
• I've not yet tested doom, since it seems it's not included in master and I need some extra steps?

Other than that things work fine on my end: vi, sl, find, ls and - of course! - beep!
Extra gaming disk(s) sounds exciting, even if it would mean to copy stuff multiple times (like in DOS times) from boot to boot or with multiple disks.

[ghaerr]

Thanks for the testing.

Try running fsck -lvf /dev/hda1, I think the f option may be necessary to force a check and write the result so that the warning disappears on the next boot.

Currently for various reasons, the warning message will always reappear for MINIX filesystems that have been mounted, unless fsck is run again. I can relook at that issue again if you think this isn't or shouldn't be proper behavior. I don't really like it, but IIRC there are some decent reasons for it.

Extra gaming disk(s) sounds exciting, even if it would mean to copy stuff multiple times (

It would be nice, but the .wad file for Doom is bigger than a 1440k disk, so we'd have to get into special utilities just to distribute the game disks. Doom is a work in process by a contributor and lives at https://github.com/FrenkelS/elksdoom.

[floriangit]

Thanks for your reply. Some more testing today revealed other things. But those may also have been present in the previous version, so take it with your own judgement (plus my HDD might be doubtful anyhow!):

I'm using net start slip with defaults, but baudrate I need to set to 9600 (never worked in default baudrate) on both ELKS/client.
When transfering the elksdoom files (haha, I admit I looked and tried anyhow) via FTP the following was observed on ELKS:

During transfer of the "large" files I got several console outputs:
tcp: BAD CHECKSUM (0x40a6) len 1004

And when I ended the FTP session on the client side I also got twice:
tcp retrans: seq 466+0 size 0 rcvwnd 65536 unack 466 rt0 32 rtt 2 (RETRY 2 cnt mem 20)

Try running fsck -lvf /dev/hda1

I tried and the recommendation on next book did not vanish. I don't have any technical insights into that, so of course it's ok when you say it makes sense for ELKS to have it that way.

[ghaerr]

Your TCP errors are likely the result of losing serial characters over your slip connection. Many PC systems are not fast enough to handle 19.2K and sometimes 9600 because of the relatively high interrupt overhead in the kernel. For this reason, we added CONFIG_FAST_IRQ{4,3} which allow operations at 38.4k. This replaces the serial read character interrupt with a very fast routine built for slip transfers.

I'm not sure why the fsck isn't causing the boot message to go away. I'll try to look into it, but that may not happen before 0.8.0 is released, but I'll try. Thank you for your testing!

[ghaerr]

I will put together a Draft v0.8.0 release issue, detailing the huge number of feature enhancements and credit to contributors, sorted by category. We can then determine how much testing may need to occur for any of the changes, and move forward with getting a v0.8.0 out. It has been just over a year.

[ghaerr]

Version 0.8.0 is released! Prebuilt floppy and HD images are available here: https://github.com/ghaerr/elks/releases/tag/v0.8.0.