(ELF)

In order to sanely and easily port FMI/OS to non-x86 platforms such as SuperH, MIPS, and PPC, it would be extremely beneficial to be able to utilize the ELF binary format. While said ports could be done without ELF support, getting the userland mode to operate on a.out is extremely combersome and over all, not worth the effort to put it forth. Implementing ELF is, quite frankly, easier then getting MIPS and friends to work with a.out.

• currently the static ELF is supported in and for both kernel, boot modules and userspace programs. Once glibc is fully ported, we will have 100% ELF support alongside shared ELF libraries. See also: ElfSupport

(Networking)

• Redesign the ethernet support.
• Replace the TCP/IP stack with a more modern one, like "LWIP":http://www.sics.se/~adam/lwip/
• Implement network filesystem access.

See also: http://www.lava.net/~newsham/vsta/ and LwipNetworking

(PCI)

PCI support itself is pretty straight forward in FMI/OS. All it really requires is a libpci for PCI daemons to use in order to interact with the PCI bus, and a pcifs that gives a filesystem view of the PCI bus layout. The number of lines of code to pull this off are, sadly enough, less then the total number of lines of text in the emails that went back and forth arguing over the best ISR interface to use, which stalled PCI development.

(enable isr)

Many many moons ago a developer wrote a PCI daemon for FMI/OS. The daemon never made it into the main distribution because there were issues with needing shared interrupts in the ISR handler in order to properly handle PCI. Instead of working the problem out with a simple solution to kick start PCI development, the various developers argued over the best way to implement a low impact long-term solution to the ISR problem in regards to context switching. This is, putting it mildly, unexceptable (unacceptable ?). All that was achieved was that FMI/OS never became recognized as a PCI capable system, and quite a few PCI drivers that were available for FMI/OS never made it into the system, making FMI/OS more difficult to work with than it needs to be.

(libfb)

There was a proposed replacement for the current framebuffer layer in Linux codenamed Ruby (see here: "backstreet ruby":http://www.ltn.lv/~aivils/?proj_id=ruby). The tree had a simplified core and allowed for extremely simple-to-write framebuffer drivers. I think one of the working examples is like 53 lines. Anyway, taking the Ruby fbcore and making it a libfb for FMI/OS would allow the fast and easy porting of fb servers to FMI/OS. There was even a layout for a graphics fs that avoided ioctl's and would fit nicely into FMI/OS's filesystem namespace.

See also: issue redminemarkdownextraformatter1

(libfs)

Most servers share a common set of code routines for handling incoming mesages. This common code can be quantified into a library interface that removes all the code duplication, as well as a few bugs with regard to message passing. It will also make it easier to port drivers from other sources, such as the Linux kernel, to the FMI/OS platform.

• currently wkt's libminifs is imported as libfs and progress is underway to convert existing servers to use it

1 (New SCM)

This milestone refers to the original goal of migrating the source code off of CVS. Most of the work in dealing with this resulted in a side-tool called cscvs written by major. All VSTa history was converted to Tla/Arch and usage of CVS was discontinued.

As of recent the TLA/Arch tool has slowly fallen behind in functionality and support, while the Bzr-ng tool has moved forward quite rapidly. Bzr itself is an evolved version of Bazaar, which was a python fork of tla/arch. With that said, milestone one is effectively being recycled as all the old archives and tools are migrated from tla/arch to bzr.

• support distributed operation. i.e. each developer can commit to their own repository as well as be able to selectively pull changes from other developer repositories.

• support handling move/rename of files and directories

• must be able to cleanly handle complex merge operations given a deep ancestry between branches

• Convert as much SCM history as possible to the new subsystem so developers who are interested in any past work, or past logs, won't have to deal with two different SCM tools.

2 (Initial Source Cleanup)

• A new source tree layout that is more intuitive to the developers needs to be implemented.

• The currently revised Makefiles are a temporary fixup. A new clean build system needs to be put in place. Each component needs to be able to be compiled completely stand-alone from the rest of the tree.

• The old source has numerous problems that prevent compilation, like invalid asm code, invalid C code, conflicting types for POSIX standard routines, alignment problems, so on and so forth.

• While the source tree now compiles it still has a large number of issues at the asm level in regards to alignment and what not.

• The kernel needs to be able to be compiled without the requirement of a FMI/OS-specific compiler.

• After the code reorganisation, and considering the number of various tiny issues in the source as well, the FMI/OS filesystem tree won't properly boot and run. This needs to be taken care of before any low level library or interface restructuring occurs.

3 (Testing Framework)

Need some way to do automated tests of the latest source tree. This would be nice to have on something like a weekly schedule. The basic idea is to validate that any new changes made during the week not have caused any fundamental issues, like breaking the kernel's ability to boot. "QMTest":http://www.codesourcery.com/qm/qmtest looks like it might be a good candidate for this purpose.

4 (Kernel Cleanup)

• primitives - The core of the VSTa kernel lacks any reusable primitives. There are no basic linked list primitives, lock primitives, hashing primitives, bit operation primitives, ect.. This results in mass amounts of duplicated code that is difficult to maintain. Correcting bugs in something like linked list handling requires huge changes to the entire code base. We desperately need valid primitives for a large variety of basic data types to make refactoring the kernel less painful.

• x86 ICU rewrite - The current 8259 interrupt handler code in VSTa is not interrupt safe, no that was not a joke. This results in a rather large number of odd issues. Further more, spurious interrupts on interrupts thought to be disabled will result in a kernel assertion unless the interrupt is on IRQ7. This is particularly painful as it is possible for an interrupt to be reenabled w/out permission of the ICU code.

• scheduler - The current scheduler is not only incredibly huge for what it does, it lacks some fudemental functionality that is greatly desired. Like proper job control. Another area of concern is that the scheduler expects the caller to hold semaphore locks before the scheduler is entered, which makes the code that much more convoluted. There are a large variety of better algorithms to choose from for process scheduling. Perhaps the most attractive is the 0(1) scheduler currently in use in the Linux 2.6 kernel. This schedueling algorithm is used in a number of real-time embedded systems (Ed Skinner at MontaVista software teaches about this schedueler in his real-time operating systems class). This algorithm works by using a bitmap where each bit corresponds to an element in an priority array. Each element in the array contains a link list of all runnable tasks for that priority, the head of the list is the first runnable task at that priority. What happens is that in effect your operation for finding the next runnable task looks like: task = priority![FindFirstSet(bitmap)] The first task on the linked list is returned and assigned. From there you just need to tear down the old task and fire up the new one. The work of adding a process back to one of the link lists simply becomes appending the task to the end of the link list for that priority when it becomes runnable and setting the appropriate bit high in the bitmap. If the task is preempted, then you simply round-robin it to the end of the list, or the end of the next lower priority list if you are going to consider process starvation. We don't need to track sleeping processes because they will be given to us when they are woken back up via either a timer, and interrupt, or an ipc message. Fixing this up is dependant on the primitives cleanup.

• semaphores - Semaphores as they currently exist can be fairly racey on SMP. Part of the issue is that the semaphores themselves do not handle the task of saving the jump address for a slept process but instead hand that off to the scheduler who deals with it via setjmp/longjmp, which ends up painfully overloading the scheduler itself besides being ugly. The semaphores really need to be replaced with simpler priority driven ones, likely using the same findfirstset bit trickery as proposed for the scheduler.

• spinlocks - Old VSTa spinlocks are hopelessly useless for SMP work. They do not spin, and they barely lock. Replace with something that does.

• memory management - While the current memory management subsystem does in fact do its job as expected, it is likely the single most convoluted, unorganized, and painfully poorly written piece of code in the entire kernel. Further more, it is most of the kernel. This needs to be flat out replaced, but in doing so we will impact the IPC subsystem as it is written with a bit to much knowledge about how the memory manager functions.

• msg passing - Besides being ridden with untold number of bugs and deadlock conditions, the current message passing layer lacks the functionality for doing proper asyncronous I/O operations. It also forces daemons to behave in certain ways that may not be desirable. Once such example is that msgsend forces the client to go into an I/O wait state. What would be nice is if we replaced msgsend w/ a new msgcall that forced the client into an I/O wait state there by implying that the communication path being set up requires the client block. If the client does not have to block for the message, it could use a modified msgsend that simply attaches the msg to the servers queue and control is returned back to the client if it still has allowed time on the CPU. An example of where this would be particularly useful is in the case of journaled file systems where a filesystem would msgcall for the journal writes, and once those are done could msgsend the filesystem updates. Once the replies come back for the updates it could msg_call to clear the journal entries.

5 (Userland cleanup)

• A large number of FMI/OS'isms exist within the current libc. Most of these can cleanly be moved out to a FMI/OS specific library, aka libfmi. Once this is done it should be possible to drop in alternative libc's such as "newlib":http://sources.redhat.com/newlib/, "uclibc":http://www.uclibc.org/, and "GLibC":http://www.gnu.org/software/libc/libc.html into the FMI/OS framework.

• The old FMI/OS libc is licensed under the GPL. This will cause numerous problems in porting various non-GPL-compatible applications to FMI/OS. If the old FMI/OS libc is stripped of all libc'ish routines, and the remainnig FMI/OS specific routines are placed into a libfmi, then an LGPL licensed libc can be used in front of the libfmi and remove many license issues.

• Clean up the header files so that headers are part of their appropriate sources instead of being crammed together in their own directory. This is especially true for the kernel headers, libc headers, and the FMI/OS specific headers. The current layout semi-reflects how they might be installed, but is fairly useless for source maintanance.

• This problem item is semi-related to the code restructuring item. The basic requirements are that each component in the tree needs to be able to be compiled independent of the tree, but that means each component needs to have some way of knowing if it is to use an in-tree header from another package it depends on, or a header from the system.

See also: LibC, issue redminemarkdownextraformatter1