ELKS 0.5 Requirements?

[Mellvik]

@ghaerr,
you've mentioned ELKS turning the corner to 0.5 a couple of times recently. With silent applause from this end.

What open issues / missing functionality do you think must be covered on order to turn that particular corner?

IMHO - given the speed of improvements recently, we should increment versions (at least minor numbers, like 0.5.1) more often. And set goals - like the recently mentioned interrupt-driven serial output as a goal for 0.6.

This will make it easier for newcomers to follow the progress and also stimulating for developers - maybe we can tempt more of them to come on board.

-M

[cocus]

Can I ask for a simple thing to be added on the next version? A build identifier, like other kernels have. For instance, I always boot my SBC and I get ELKS kernel 0.4.0 (44496 text, 0 ftext, 5248 data, 37552 bss, 22734 heap), but that doesn't tell when it was built, by whom, using which compiler, etc, like most kernels do (like [ 0.000000] Linux version 5.11.0-43-generic (buildd@lcy02-amd64-036) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #47~20.0 4.2-Ubuntu SMP Mon Dec 13 11:06:56 UTC 2021 (Ubuntu 5.11.0-43.47~20.04.2-generic 5.11.22)).
This would greatly improve debugging (at least from my end!)

[ghaerr]

@Mellvik,

Thanks for opening this issue, this will help finalize what we ought to do before v0.5.0. I'll give some thought to what I think and respond shortly.

@cocus,

Can I ask for a simple thing to be added on the next version? A build identifier, like other kernels have.

We currently show the origin commit ELKS is built from, although this is only displayed by the shell running /etc/rc.d/rc.sys which does a cat /etc/motd:

ELKS built from commit 6a49e074

Also, the ELKS version number contained in /etc/issue is displayed by /bin/getty before login, as seen below.

Given that we all should be using the same toolchain, would this be enough, if built into the kernel instead of /etc/motd, or do you really need all those version numbers above? These could be combined or displayed differently depending on a desktop or embedded build, as well.

Thank you!

[Mellvik]

Keeping this issue warm (and knowing that I'm somewhat repeating myself), I'd like to put
-> ktcp timeout (say 10 secs as you suggested @ghaerr) on non-responsive connection requests.
It's killing me (sloppy fingers) as I have to go to the garage to reboot the machine every time a non existent address has been used with (say) ftp.

I'm currently tracing down the last (!?!) timing related memory leak in ktcp, which we've seen a couple of times before, and then lost. Now, with two ELKS systems back to back I have a very repeatable setting for narrowing down this problem (as well as provoking some others).

-M

[ghaerr]

Request adding ktcp timeout on non-responsive connection requests.

Noted. I'm thinking perhaps we should release a v0.5 first, then jump into this, and your referenced memory leak bug, since TCP is pretty stable in normal use environments. Adding timeouts to ktcp is a fundamental (but pretty basic) change, and I'm pretty happy with the TCP stability we have at the moment, frankly. Same for your tracking down of smaller and smaller memory leak or other TCP failures.

We also have an outstanding disk I/O bug #1119, but that can wait, as can a number of smaller open issues, I would think.

We haven't heard back from @cocus as to whether a hard-coded commit reference and/or version number would be OK, or whether the entire toolchain version should be compiled in somehow, and whether this needs to be in v0.5 or not. Frankly, I'm not sure the commit reference currently displayed at login helps that much, since most users are having to build from current repo source. More discussion is needed on what version info is actually needed for more effective debugging or version tracing.

In general, ELKS probably needs more frequent releases, rather than big, "important" releases, as we don't really have the user base to make running or maintaining a specific released version that important. That is, having version numbers which kind of place a time/date "era" around the functionality, along with more frequent version number increases might work to show progress, document features, and attract more users.

To more specifically answer @Mellvik's stated question of "what missing functionality or open issues need to be completed before release", I'd say none really other than what users might demand; a lull in bugs found (like now) might be a good time to release a version at this stage of ELKS development.

We do have a PC-98 port in mid-progress, but that's working pretty well and I'm guessing we'll continue to see enhancement PRs regardless of version number on that, as well as for the ongoing 8018X port.

[Mellvik]

OK @ghaerr, that's a fair assessment, to which I pretty much agree. Including increasing the frequency of releases. Maybe we should be working on the 0.6 list instead, submit whatever we have pending and put a pole in the ground marked 0.5. Indeed it is time. As to commit reference, I think usefulness is the only metric. The tools are predetermined and pretty much stable. And I find the current setup useful. Having the git commit reference easily at hand has turned out to be very useful when tracking down problems. A direct reference to the got log, perfect starting point for bisects. Having a version number might look good, and I certainly don't object to that, but I would insist on keeping the commit ID. I have some ftp, ftpd and sash changes coming. ktcp-to-ktcp turns out to be a interesting challenge. They don't really like each other. Like - both sides insisting on having their particular retransmit packet accepted first, before continuing. That can wait. —M

…

31. jan. 2022 kl. 17:14 skrev Gregory Haerr ***@***.***>: Request adding ktcp timeout on non-responsive connection requests. Noted. I'm thinking perhaps we should release a v0.5 first, then jump into this, and your referenced memory leak bug, since TCP is pretty stable in normal use environments. Adding timeouts to ktcp is a fundamental (but pretty basic) change, and I'm pretty happy with the TCP stability we have at the moment, frankly. Same for your tracking down of smaller and smaller memory leak or other TCP failures. We also have an outstanding disk I/O bug #1119 <#1119>, but that can wait, as can a number of smaller open issues, I would think. We haven't heard back from @cocus <https://github.com/cocus> as to whether a hard-coded commit reference and/or version number would be OK, or whether the entire toolchain version should be compiled in somehow, and whether this needs to be in v0.5 or not. Frankly, I'm not sure the commit reference currently displayed at login helps that much, since most users are having to build from current repo source. More discussion is needed on what version info is actually needed for more effective debugging or version tracing. In general, ELKS probably needs more frequent releases, rather than big, "important" releases, as we don't really have the user base to make running or maintaining a specific released version that important. That is, having version numbers which kind of place a time/date "era" around the functionality, along with more frequent version number increases might work to show progress, document features, and attract more users. To more specifically answer @Mellvik <https://github.com/Mellvik>'s stated question of "what missing functionality or open issues need to be completed before release", I'd say none really other than what users might demand; a lull in bugs found (like now) might be a good time to release a version at this stage of ELKS development. We do have a PC-98 port in mid-progress, but that's working pretty well and I'm guessing we'll continue to see enhancement PRs regardless of version number on that, as well as for the ongoing 8018X port. — Reply to this email directly, view it on GitHub <#1109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3WGOAPFD7AUUAYWF6DEDTUY2YMVANCNFSM5MCZ7T7Q>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.

[ghaerr]

Maybe we should be working on the 0.6 list instead, submit whatever we have pending and put a pole in the ground marked 0.5. Indeed it is time.

Agreed. Lets get a few of your remaining changes into PRs, and get a v0.5 cut. I'll open a separate v0.6 afterwards with my list, and we can each add our own requests to that.

While you're at it - can you please test #1119 on real hardware to see whether this is a QEMU vs hardware issue? I don't plan on fixing this in v0.5 though.

I would insist on keeping the commit ID.

No problem!

ktcp-to-ktcp turns out to be a interesting challenge. They don't really like each other. Like - both sides insisting on having their particular retransmit packet accepted first, before continuing.

Off topic - we'll have to talk about that in another issue, later. I'm worried this will become a big problem, as I've realized that one of the reasons ELKS TCP works is that the "real" full TCP specification allows for talking with simpler implementations, but definitely not the other way around. There is simply lots of stuff missing from ktcp that might have to be added to get ELKS-to-ELKS working well. We may have to make a decision on more precisely the purpose of ELKS TCP is about before jumping into this.

Thank you!

[Mellvik]

@ghaerr,

Maybe we should be working on the 0.6 list instead, submit whatever we have pending and put a pole in the ground marked 0.5. Indeed it is time. Agreed. Lets get a few of your remaining changes into PRs, and get a v0.5 cut. I'll open a separate v0.6 afterwards with my list, and we can each add our own requests to that.

Good plan, I'll have a PR ready some time tomorrow.

While you're at it - can you please test #1119 <#1119> on real hardware to see whether this is a QEMU vs hardware issue? I don't plan on fixing this in v0.5 though.

I just tested this, and cannot replicate the reread problem on real hardware. ELKS does mount a 360k floppy fine, while displaying the 'wrong' data, see clip below. The 2nd pair of FAT messages are (obviously) for the HD.

ktcp-to-ktcp turns out to be a interesting challenge. They don't really like each other. Like - both sides insisting on having their particular retransmit packet accepted first, before continuing. Off topic - we'll have to talk about that in another issue, later. I'm worried this will become a big problem, as I've realized that one of the reasons ELKS TCP works is that the "real" full TCP specification allows for talking with simpler implementations, but definitely not the other way around. There is simply lots of stuff missing from ktcp that might have to be added to get ELKS-to-ELKS working well. We may have to make a decision on more precisely the purpose of ELKS TCP is about before jumping into this.

OK; I sense we have some real fun coming … thanks, m —————————————— Direct console, scan kbd 80x25 emulating ANSI (3 virtual consoles) ttyS0 at 0x3f8, irq 4 is a 16450 ttyS1 at 0x2f8, irq 3 is a 16550A ttyS2 at 0x3e8, irq 5 is a 16550A xms: A20 was off now on, using int 15, 256 xms buffers eth: NE2K at 0x300, irq 12, MAC 00:80:29:ef:d9:51 bioshd: hda BIOS CHS 610,16,63 bioshd: hda IDE CHS 993,16,63 /dev/hda: 993 cylinders, 16 heads, 63 sectors = 488.7 Mb /dev/fd0: 80 cylinders, 2 heads, 18 sectors = 1440.0 kb /dev/fd1: 80 cylinders, 2 heads, 15 sectors = 1200.0 kb Partitions: hda:(0,1000944) hda1:(63,997857) device_setup: BIOS drive 0x0, root device 0x380 PC/AT class machine, Unknown x86 CPU, 640K base RAM. ELKS kernel 0.4.0 (52416 text, 12704 ftext, 8016 data, 41856 bss, 15662 heap) Kernel text at 2d0:0000, ftext f9c:0000, data 12b6:0000, top a000:0, 501K free fd: /dev/fd0 found ELKS parm block, has 80 cylinders, 2 heads, and 18 sectors VFS: Mounted root 0x0380 (minix filesystem). Running /etc/rc.d/rc.sys script fsck -r /dev/fd0: /dev/fd0 is clean, no check. fd: probing disc in /dev/fd1 fd: /dev/fd1 probably has 80 cylinders, 2 heads, and 15 sectors FAT: me=f9,csz=1,#f=2,floc=1,fsz=7,rloc=15,#d=224,dloc=29,#s=2400,ts=0 FAT: 1200k, fat12 format FAT: me=f8,csz=16,#f=2,floc=1,fsz=244,rloc=489,#d=512,dloc=521,#s=997857,ts=9978 57 FAT: 498M, fat16 format Starting networking on eth ktcp -b 10.0.2.15 10.0.2.2 255.255.255.0 ktcp: ip 10.0.2.15, gateway 10.0.2.2, netmask 255.255.255.0 ktcp: ethernet 00.80.29.ef.d9.51 mtu 1500 Starting daemons 'telnetd' 'ftpd -d -d' ELKS built from commit 5d36b17 Mon Jan 31 19:02:37 2022 ELKS 0.4.0 login: root # ls /mnt1 command.com dos ibmbio.com ibmdos.com #

[ghaerr]

ELKS does mount a 360k floppy fine, while displaying the 'wrong' data, see clip below.

Thanks for testing this. I assume for 'wrong' data, you mean it reports CHS 80/2/15 (1200k) rather than CHS 40/2/9?
However the ls /mnt is correct, right?

I will add your test response to the #1119. It seems my originally reported problem is that the retry error is only with QEMU. However, with ELKS thinking the disk is 1200K rather than 360k, a quick top-level directory listing may not try reading sectors outside the 360k sectors/track limit of 9, and thus not show the real problem.

Lets take this discussion over to #1119, and I'll add this to the list for more testing. I don't have any real hardware with multiple floppies.

Thank you!

[Mellvik]

31. jan. 2022 kl. 19:16 skrev Gregory Haerr ***@***.***>: ELKS does mount a 360k floppy fine, while displaying the 'wrong' data, see clip below. Thanks for testing this. I assume for 'wrong' data, you mean it reports CHS 80/2/15 (1200k) rather than CHS 40/2/9? However the ls /mnt is correct, right?

That's it.

I will add your test response to the #1119 <#1119>. It seems my originally reported problem is that the retry error is only with QEMU. However, with ELKS thinking the disk is 1200K rather than 360k, a quick top-level directory listing may not try reading sectors outside the 360k sectors/track limit of 9, and thus not show the real problem. Lets take this discussion over to #1119 <#1119>, and I'll add this to the list for more testing. I don't have any real hardware with multiple floppies.

Sounds good. Thank you.

…

-M

[toncho11]

Hi,

Is there a way to also print the architecture when ELKS is starting?
There is no uname command? I think busyelks does not support "uname".
It will be cool to see at both boot and with uname something like that:

ELKS 4.0 on IBM PC (or compatible) running at 4.77 Mhz

[cocus]

We haven't heard back from @cocus as to whether a hard-coded commit reference and/or version number would be OK, or whether the entire toolchain version should be compiled in somehow, and whether this needs to be in v0.5 or not. Frankly, I'm not sure the commit reference currently displayed at login helps that much, since most users are having to build from current repo source. More discussion is needed on what version info is actually needed for more effective debugging or version tracing.

Sorry, I'm always busy and I couldn't even reply!
I agree that having the commit number hardcoded somewhere is not that useful, but I assume that at least the build time would be useful. For instance, every time you issue a build, even if you didn't change anything, let that string change. That's way more useful because you have a reference of which ELKS you're running off of. I know that much of that info is available on the "full" rootfs (which I don't use it as of now, so I don't get any of that), but having the build timestamp on the kernel would be cool.

In general, ELKS probably needs more frequent releases, rather than big, "important" releases, as we don't really have the user base to make running or maintaining a specific released version that important. That is, having version numbers which kind of place a time/date "era" around the functionality, along with more frequent version number increases might work to show progress, document features, and attract more users.

Agreed!

[ghaerr]

Hello @cocus,

Thanks for your reply!

but I assume that at least the build time would be useful. For instance, every time you issue a build, even if you didn't change anything, let that string change. That's way more useful because you have a reference of which ELKS you're running off of. I know that much of that info is available on the "full" rootfs (which I don't use it as of now, so I don't get any of that), but having the build timestamp on the kernel would be cool.

I'm understanding more of what you're looking for, (some kind of time stamp with possible version information), but I'm not sure yet how exactly one might get to or read this information, especially with the current differences between desktop and embedded systems, consoles, logins, filesystems, etc.

I'm going to suggest that we leave this out of the v0.5 cut, but discuss it more and then work towards a design that works for you just afterwards. The design will need to meet your needs, but also work given possibly no /bin/init, /etc/motd, /etc/issue, etc, yet still be accessible or visible. Perhaps we're talking about an early kernel printk, but not sure whether we should drag in lots of date printing code into the kernel.

even if you didn't change anything, let that string change.

No two binaries would then ever be identical (which could be good or bad), but how is it that one ties a build to any specific source, if the build number is never constant? A way to tie to some version of source would be nice, instead of just an incrementing build number. Perhaps a config-configurable method of "version-stamping" the kernel, where the "version" could be a time, version, etc, derived from a configurable printf-like format string. That way, the embedded systems version could be configured differently than "standard", the way you like/need/want it.

Thank you!

[toncho11]

Hi,

I have tested the current version and I do not see any bugs. I tested networking also.
I suggest that you tag the code as version 0.5 and release the binaries.

[ghaerr]

I suggest that you tag the code as version 0.5 and release the binaries.

Agreed. I'll start putting together the new features / enhancements list and a PR with version change, pending anything else that might want to be added last-minute.

[Mellvik]

I support this. My updates to ftp/ftpd/sash are non-critical in the sense that things work fine as is. They can come later. I'd like to get the ktcp issue we're working on, out of the way before submitting another ftp-related PR. —M

…

6. feb. 2022 kl. 16:10 skrev Gregory Haerr ***@***.***>: I suggest that you tag the code as version 0.5 and release the binaries. Agreed. I'll start putting together the new features / enhancements list and a PR with version change, pending anything else that might want to be added last-minute. — Reply to this email directly, view it on GitHub <#1109 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3WGOAZTN4SGLOQVCT5RQTUZ2FPTANCNFSM5MCZ7T7Q>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.

[tyama501]

Hello.
Here are the known issues and todo list for PC-98. I think these are works after 0.5.0.

• Hard disk partition needs PC/AT style partition table to mount.

• Cannot boot from hard disk since there is no boot code for hd

• Reboot command

• probing FD drive number

• Support FD1440, FD1232 simultaneous

• dd command for FD1232 not working.
  (It would be nice if we can solve this before release)

Thank you.

[tyama501]

dd command for FD1232 not working.
(It would be nice if we can solve this before release)

Solved. Thank you.

[ghaerr]

Hello @cocus,

Thanks for your comments requesting version information in ELKS. I've got that on my list, we can discuss further when you have time. I'm closing this issue as v0.5.0 has been released.

Thank you!

[cocus]

Thanks for your comments requesting version information in ELKS. I've got that on my list, we can discuss further when you have time. I'm closing this issue as v0.5.0 has been released.

Sure enough! Thanks!