The Librarification of Foenix/MCP

[pweingar]

I think there have been a couple of suggestions around the kernel being a sort of library... something to enable it to be used by other projects, or to be more easily expanded and tailored by the users. It's unclear to me what exactly that would look like, but I could see that being a useful direction for it. So I wanted to make a discussion for that to get ideas. I mentioned this elsewhere, but I'll put it here for the record: something that Stefany and I discussed earlier is that there might be two forks of the Foenix/MCP kernel... a stripped down one for the two of us, where it would be just what was necessary to make things go, support her testing new boards, and be the initial stock kernel, and then one the user community could take and use as they wish. But I could see that making the kernel more of a library or layered component, so to speak, could maybe mean there wouldn't need to be a separate fork of the kernel... but another project adding additional layers around the kernel. So this is why I'm interested in this idea.

Thoughts?

[pweingar]

Something that occurred to me while I was on my walk this afternoon: the kernel's use of the low bank of memory is mainly about convenience. GABE will copy the first 64KB of data from flash down to RAM before resetting the CPU (much as the C256 does). So that's an easy way to get initialized variables down into the kernel's memory. Also it's a block of RAM that won't get in an application's way and is needed anyway for the exception vectors.

That said, the kernel's code makes no assumption about the location of its variables. The only place where we specify the location of the stack, heap, and various segments is in the linker script. There's really no reason that we couldn't move that to some other memory location. Likewise, it would be possible to expose the kernel's routines as a library to a program, and let the program's linker script set the location. We might need to tweak the startup assembly file however to let the host program do some of the exception vector setup... not sure about that.

[vinz6751]

I'm playing with that to see what is the first hurdle I'll meet.
1 I've rewritten part of the startup script in C for simplicity. Only IRQ handlers needs to remain in ASM.
2 The foenixmcp.c is stripped from the code displaying version and the logo (that is moved to theCLI). It's no longer startable by itself (as it's a "lib").
3 The initialize() method of FoenixMCP will be renamed _INIT_foenixmcp so can be initialised automatically by VBCC's C library (see VBCC manual 3.5.10)
3 A main.c file is created for the CLI, it'll display the logo and information using information obtained via syscalls. The CLI has a startup code which jumps to the C lib __main which initialises the foenixmcp before the CLI main() is called.

And yes Peter, we can and should have the kernel and its variable anywhere. I'm not sure if we should assume we can use the first 64K as if the kernel comes as a library, it could be it that supports another flashed OS which needs the first 64K for its own purposes. Of course MCP needs some the first 68k vectors to provide its services, but the code and the variables should be able to be located anywhere else.

[pweingar]

Interesting... so you're basically making the kernel library a "client" of the CLI in a sense. I hadn't thought of that. I'll be interested to see this. the last part should be easily supported... the only thing in the kernel that makes assumptions about memory layout is really the sysinfo call in sys_general, which is supposed to figure out the exact model, CPU, and memory based on some of the GABE register settings. It may be that needs to change to accept values from a host OS.

[daschewie]

I think users that would like to see the kernel as a library plan install a different binary in the FLASH area for example EmuTOS. For most users a simple client library or direct syscalls would lead to smaller executables and avoid license issues.

[pweingar]

I'm afraid I'm not an expert with licenses generally... GPL projects can't link to BSD projects? I actually went with BSD because I wanted the least amount of restrictions for someone who wanted to use the code.

ETA: Although there are also restrictions due to FatFS... but for something like EmuTOS, that would probably be removed anyway, since EmuTOS has its own file system code.

[daschewie]

There is nothing wrong with the license you picked. It provides plenty of freedoms for people to do things. The GPL license requires any non-free libraries to adopt the GPL license for linking.

Turns out the Original BSD license was not compatible with the GPL, however the 3-Clause BSD license used by the Kernel is. I verified here: https://www.gnu.org/licenses/license-list.html#ModifiedBSD

[vinz6751]

I support the idea, as a start I think we should split out the CLI from the rest, or at least make sure that the CLI uses any things from the KernelMCP through the syscall interface, if that's not already the case, then have a different "make" target for it and the kernel. Then we can try how that flies.
Shall have a go at trying to do that ? Peter mentioned he has a A2560K branch so I'm not sure if doing any kind of code moving now would create merge conflicts later.

[pweingar]

The CLI is kind of a mess with regard to the sys_call structure... some things it's using sys calls for some things not. It's largely because I built the sys calls rather late in the process. I've been trying to convert stuff over as I touch it. The main conflict that will happen with the CLI and the A2560K branch is that I've added a number of hardware tests for the K, but I think those can be moved without too much problem.

[daschewie]

It would be good to dogfood the system calls in the CLI, I think Vincent found some bugs in the fsys directory calls that needs to be tested. Splitting the CLI from the Kernel will require some refactoring of the loaders. Currently the loaders are defined in the CLI, and the Kernel will need to use them to load the CLI. We would also need to look at memory mappings and having a separate stack. It will be a large effort, and a lot of testing will be needed.