Misc questions...

[floriangit]

(1) Here https://github.com/ghaerr/elks/blob/master/elks/arch/i86/drivers/char/kbd-scancode.c#L309 I can see there is no connection of the character drivers with the filesystem (which makes sense). Does this imply (https://github.com/ghaerr/elks/blob/master/elks/arch/i86/kernel/reset-ibm.c#L9), there is neither a sync nor unmounting applied before doing the reboot? The code comment also alludes to this.

I have the situations that things sometimes hang, yet CTRL-ALT-DEL works and reboots. It would feel better to add at least some basic sync-to-disk there? (not that I have very important data, though, lol).

(2) do we need reset-stubs.c?

(3) ash job control: I can send a process into the background suffixing it with &, I can also use fg to bring it into the foreground. However bg and CTRL-Z functionality is missing, which feels a bit odd, but maybe is accounted to the limited implementation at that time?

[ghaerr]

Hello @floriangit,

Currently, CTRL-ALT-DEL does not call other system functions (like sync) before forcing a hard reset. This is a bit debatable, but when the system is hung and the kernel in a bad state, it may not be a good idea to call complex system functions like sync, as the resulting I/O could in fact corrupt the system and/or disk image further. On a non-protected, non-MMU system, when the system is hung, it thus usually better to just reset rather than trying to rectify the problem.

do we need reset-stubs.c?

These are used in the associated Makefile for the non-IBM PC builds.

However bg and CTRL-Z functionality is missing,

Foreground programs can be stopped via CTRL-Z, and restarted via fg or kill -CONT, but the ash shell we yave predates fully working job control, and the kernel itself must implement a large variety of extra signals and ioctls in order to make everything work. Thus, ELKS support is rudimentary, and only works well for simple jobs that are not stopped waiting for input. When a stopped job waiting for input is restarted from the shell, the shell also remains waiting for input, and things getting messy from there.

The ash job control is still somewhat useful when using the combination of jobs, fg and CTRL-Z for simple situations (and also kernel signal testing) where one wants to interrupt a certain process to quickly start another, then switch back. jobs can also be used without job control and is useful for displaying any processes running in the background by the current shell.

[floriangit]

Many thanks for your reply @ghaerr.

On a non-protected, non-MMU system, when the system is hung, it thus usually better to just reset rather than trying to rectify the problem.

Ok, that makes sense to me now.

The ash job control is still somewhat useful when using the combination of jobs, fg and CTRL-Z for simple situations (and also kernel signal testing)

I can show you a simple QEMU use-case, where things do not make sense to me / do not work:
I pressed CTRL-Y (since German keyboard) after starting foo.sh

[ghaerr]

I can show you a simple QEMU use-case, where things do not make sense to me / do not work:

Hmmm, can you retry this test running just sleep 30 directly, rather than within a shell script? I suspect the real problem is that (for various reasons, and possibly incorrectly), the shell itself is ignore the SIGSTOP. Thus is continues to run while sleep is stopped.

[floriangit]

same result. First I thought, that sleep is a shell builtin and we are anyhow inside shell's territory, but /bin/sleep is there and the ash source code does not have any sleep results when grepping....

[ghaerr]

The issue is that the shell jobs is not reporting the stopped job, right?

In the screenshot above, you would have to kill -CONT 12 (not 6) in order to restart the sleep.

I'll investigate this further, but in general, ELKS' implementation of jobs is definitely not fully implemented. I'm also thinking that the sleep program itself dies (or possibly exits normally) when it gets stopped. Testing typing CTRL-Z after sleep 100 in the shell just now seemingly shows that - sleep has exited.

[ghaerr]

I debugged the above with sleep and sleep does show in jobs immediately after a CTRL-Z. However, it appears that sleep exits when restarted (that is, the select system call it is waiting on returns -EINTR). This happens when fg is executed, after which sleep immediately exits.

Thus for embedded shell script testing, we should probably use another command than sleep. I suspect there is still a problem with sh ignoring CTRL-Z in scripts, as I added ignoring SIGTSTP in order to get the interactive shell not to stop when CTRL-Z was typed.