GeckOS was originally written for a 6502 computer with an MMU, so that each process could have its own memory map and needed no relocation for binaries. So, the kernel managed the communication across memory maps using SEND/RECEIVE and Streams. Already V1 then learned to run without an MMU, and used relocatable binaries.
V2 then saw a complete rework mainly of the scheduler. This allowed using Threads in a three-staged management: 1. memory map environments 2. processes (task) 3. threads. Also, the lib6502 shared library was implemented for V2 to allow for easier developmen of programs.
One shortcoming that was not fixed was that interprocess communication still mainly worked with SEND/RECEIVE and Streams. SEND/RECEIVE uses a message buffer at the fixed address $0200 in an environment, so it had to be protected by a semaphore. Streams were still using a byte-wise transfer of data across the kernel buffer.
The plan for GeckOS-NG (codename for Geckos-V3) is to implement the following improvements.
Each of the three concepts and designs and API drafts will be discussed in a separate document.
-
GeckOS-NG-Buffers:: Unify SEND/RECEIVE and Streams with a buffer-oriented communications API, that specifically allows for shared memory streams and optimizes the number of kernel calls.
-
GeckOS-NG-Locator:: Provide a "locator" service that replaces the FSM filesystem locator with a generic solution that can be used to lookup real names, and other types of elements. Use this to map drive names like "fd0", "8", or "sda1" to drive numbers and server process ids. Also, this is the means to identify and address dynamically changing devices, like USB-connected mice or keyboards, or storage. It could also be used to identify networking devices.
-
GeckOS-NG-Terminal:: Establish the concept of a controlling terminal, that receives signals like Ctrl-C or Ctrl-Z from devices. This would also enable job control in the shell - that at this point can only wait for a child to end, or send it in the background altogether. In addition, an (optional) terminal process will be established that allows windowing of shells - similar to Linux tmux as an example.
-
GeckOS-NG-romfs:: how to improve ROM handling, and enable o65 file handling in ROM, as well as other filesystems.
These APIs are preliminary and the discussion documented here is basically a scratchpad of ideas that will be further refined, and at some point implemented.
The Buffers interface replaces the SEND/RECEIVE and Streams APIs at the same time.
The main concept of the API is the Buffer. A buffer is a memory area that is defined by a start address, a length, and a type that defines how read and write pointers, as well as changes to start address and length are handled.
Channels replace streams. Once a communication is established and the channel buffer is given to the kernel, only the channel number is used for further calls.
Currently drives are addressed by number. There is no way to have symbolic drive names, or dynamic drive allocations. A Locator service replaces the fsm, so that drive names can be looked up dynamically. This works together with the new Channel API.
In addition, the locator can dynamically handle device names (e.g. for dynamic USB changes in devices, liked newly plugged in mouse or keyboard)