arch: add homebrew API #1765
arch: add homebrew API #1765
Conversation
|
Hello @and3rson, Yes, this approach should work well, at least for experimentation. It will be interesting to see how much INT 0x88 needs to be expanded for getting/setting parameters outside ELKS. (It is possible, for instance, that many parameters might be accessible through a standardized PK-88 BIOS emulation of the BDA, rather than introducing a new method). If it turns out that only a very few items need to be configured/supported through INT 0x88, it might be better to keep them hard-coded in config.h, but we'll see :) I'd like to discuss making a few changes before commit; I'll comment directly by each file changed for your consideration. Thank you! |
|
|
||
| #define ARG0 2 | ||
|
|
||
| .code16 |
There was a problem hiding this comment.
Although likely not currently strictly needed here, lets add .arch i8086, nojumps before .code16, to enforce strict early 8088 execution capability.
| .global int88 | ||
|
|
||
| int88: | ||
| mov %ds,%dx |
There was a problem hiding this comment.
Does INT 0x88 modify DS? If not, this and line 16 aren't needed. My recommendation would be that INT 0x88 save all registers other than AX (=return value) and flags. ELKS itself (and user land programs) allow BX, CX and DX to be trashed across C function calls, with return value in AX (or DX:AX for longs); the callee must save SI, DI and BP if used.
| #define SETUP_VID_COLS setupb(7) /* BIOS video # columns */ | ||
| #define SETUP_VID_LINES setupb(14) /* BIOS video # lines */ | ||
| #endif /* CONFIG_HW_HOMEBREW */ |
There was a problem hiding this comment.
I would prefer that this entire #ifdef CONFIG_HW_HOMEBREW section be moved past line 46, so that the standard CONFIG_ARCH_IBMPC settings remain together, even if it means having to use #undef SETUP_VID_LINES etc in that section.
(Note also we prefer #ifdef CONFIG_xxx rather than #if defined(CONFIG_xxx). You're welcome to fix the #if defined(CONFIG_MK_88) below as well - I missed that when it was submitted).
| #include <linuxmt/types.h> | ||
| #include <stddef.h> | ||
|
|
||
| byte_t int88 (byte_t fn); |
There was a problem hiding this comment.
May I suggest using int rather than an 8-bit value for both the argument and return value for int88? Allowing a 16-bit return value allows for returning any value including pointers, and a benefit of not passing a char allows the C compiler to zero-extend onto the stack, alleviating the need for extra instructions in the .S file for accessing the argument.
In general, both linuxmt/types.h and stddef.h aren't needed; for instance if just byte_t were needed, including arch/types.h would be all that's needed.
| @@ -19,6 +19,7 @@ | |||
| #include <linuxmt/chqueue.h> | |||
| #include <linuxmt/ntty.h> | |||
| #include <linuxmt/kd.h> | |||
| #include <linuxmt/homebrew.h> | |||
There was a problem hiding this comment.
I would suggest including linuxmt/homebrew.h in config.h in the #ifdef CONFIG_HW_HOMEBREW section. In this way, we won't need to add a homebrew.h include in every file that happens to require the SETUP_xxx values.
|
Hi @and3rson, are you still interested in moving forward on this? Thank you! |
This PR supersedes #1761 and adds a new hardware sub-platform -
CONFIG_HW_HOMEBREW, which is a subset of IBM PC. When enabled, certain config parameters will be queried using INT 0x88, thus allowing custom BIOSes and bootloaders to modify ELKS kernel setup process during runtime by implementing their own INT 0x88 handler.Currently there are only two functions that are used by BIOS console:
This allows us to keep the machine-specific parameters out of kernel code.
Why INT 0x88?
Let me know what you think about this approach. It's similar to what's been suggested by @ghaerr in the original PR.