Compile fails when SERIAL=pty

[ghaerr]

Compilation of EMU86 fails when SERIAL=pty set in config.mk:

Gregs-MacBook-Pro2:emu86 greg$ make
cc -g -Wall -Werror   -c -o list.o list.c
cc -g -Wall -Werror   -c -o op-common.o op-common.c
cc -g -Wall -Werror   -c -o op-id-name.o op-id-name.c
cc -g -Wall -Werror   -c -o op-class.o op-class.c
cc -g -Wall -Werror   -c -o emu-mem-io.o emu-mem-io.c
cc -g -Wall -Werror   -c -o emu-proc.o emu-proc.c
cc -g -Wall -Werror   -c -o op-exec.o op-exec.c
cc -g -Wall -Werror   -c -o emu-int.o emu-int.c
cc -g -Wall -Werror   -c -o emu-main.o emu-main.c
cc -g -Wall -Werror   -c -o op-print-intel.o op-print-intel.c
cc -g -Wall -Werror   -c -o emu-con.o emu-con.c
cc -g -Wall -Werror   -c -o con-char.o con-char.c
cc -g -Wall -Werror   -c -o char-stdio.o char-stdio.c
cc -g -Wall -Werror   -c -o serial-char.o serial-char.c
cc -g -Wall -Werror   -c -o char-pty.o char-pty.c
char-pty.c:101:3: error: implicit declaration of function 'cfmakeraw' is invalid in C99
      [-Werror,-Wimplicit-function-declaration]
                cfmakeraw (&tios);
                ^
1 error generated.
make: *** [char-pty.o] Error 1

I was trying to debug latest reported problem between EMU86 and ELKS https://github.com/jbruchon/elks/issues/932#issuecomment-846223069 with 8018X target.

Since 8018x target uses serial port as ELKS console, EMU86 has to be configured differently. I tried a couple configurations to no avail, then found this one.

Since 8018X version of ELKS uses serial port as console, and EMU86 has no other function of CONSOLE= in this case, IMO there ought to be an easy way for EMU86 to be use stdio for console/serial, without having to resort to special setup of pcat or pty. In other words, SERIAL=stdio should work when CONSOLE=stdio. Since that doesn't compile, I tried redirecting the serial port.

I don't think it should be a problem for both CONSOLE to be stdio and SERIAL=stdio in the 8018x case, since there is no other ELKS "console" output, and EMU86 won't read from stdio unless in ">" command mode.

I would get more into this but IMO it seems that this area of design of EMU86 is quickly becoming too complicated for user, and I now don't fully understand it.

Thank you!

[mfld-fr]

This warning does not occur on my Gentoo with glibc version 2.32, and there is no problem in the automatic build using config-advtech.mk and config-or566.mk on the latest Ubuntu after @tkchia fixed some feature macros in #5. It looks like this problem is specific to your host build environment. I suggest to search for the declaration of cfmakeraw in your libc headers.

[mfld-fr]

Again, CONSOLE=stdio has no meaning when there is no emulated console device (= keyboard + display). The fact that ELKS connects internally its 'console' abstraction to the serial port has no matter for EMU86, that only has to emulate that serial port.

Then the SERIAL= option is used to connect that emulated serial port to a real back-end. The stdio back-end just reuses the stdin / stdout of the EMU86 process for target I/O.

This is the same design as QEMU, with options to connect virtual devices to real back-ends. EMU86 debugger, whatever the CONSOLE= and SERIAL= options, always uses the stdin / stdout of the EMU86 process for user I/O (as the QEMU -monitor stdio option).

See also https://github.com/mfld-fr/emu86/pull/73#discussion_r636263572.

[ghaerr]

I suggest to search for the declaration of cfmakeraw in your libc headers.

I have fixed the macOS compile problem using the following patch. I'm not in a position to post a PR to EMU86 at the moment, can you apply it, thank you.

diff --git a/char-pty.c b/char-pty.c
index 8e331de..6da7739 100644
--- a/char-pty.c
+++ b/char-pty.c
@@ -3,6 +3,7 @@
 //-------------------------------------------------------------------------------

 #define _DEFAULT_SOURCE    // for cfmakeraw()
+#define _DARWIN_C_SOURCE    // for cfmakeraw() on macOS
 #define _XOPEN_SOURCE 600  // for posix_openpt() & ptsname()

 #include <stdlib.h>

[mfld-fr]

Done, thanks for the patch !

[ghaerr]

The fact that ELKS connects internally its 'console' abstraction to the serial port has no matter for EMU86, that only has to emulate that serial port.

I only mention things for future consideration and usability.

The EMU86 CONSOLE= option actually makes two assumptions: that of where the BIOS ROM I/O stream is redirected, as well as whether that stream should look/act like a PC Console (for instance with SDL).

To further clarify what I'm talking about, I originally wrote the SDL backend as a "streams" abstraction, rather than as a "console". That is, it should be usable to process any stream input/output, such as contents of serial I/O stream. Now, CONSOLE= is considered special case combining what could be multiple options.

For instance, nice option to EMU86 would be ability to run ELKS BIOS output to stdio, while redirecting 8251 emulated serial port to SDL. This would be done using BIOS=stdio, SERIAL=sdl. Then, when running ELKS, miniterm could be started and communicate to serial port which would show up in seperate box, the SDL window. This could greatly help debugging an interrupt-driven serial port.

My thoughts are that EMU86 has "console" API, which is fine. However, a subset of all console API is "stream" API, which is what I am discussing above. The stream API has but just three functions: con_put_key, con_get_key and con_poll_key.

Since stdio, serial, and sdl implement the stream API, it would be interesting to be able to connect emulated BIOS and hw serial port streams to sdl or stdio arbitrarily. This is an enhancement to, and a bit different, than the current CONSOLE= setting. EM86 assumes BIOS stream connection with CONSOLE=, possibly should be assignable separately.

So, because ELKS connects its console abstraction to serial port for 8018X, but BIOS for PC, these do have possible uses with a more flexible EMU86. I don't think it would be much work to un-bundle CONSOLE abstraction in EMU86.