Development

As a break from the kernel development I started thinking about user mode applications, what library's I will support and the kernels system call interface. Even though I'm not going down the POSIX road for system calls I could still port lib C across, probably GNU's libC. The docs specify how to create stubs for the system calls you do not support and the library functions that rely on them will fail gracefully. It might be more feasible to port a reduced C library across to AMOS, possible the diet libc or something similar. This leads to the question of whether to support dynamic linking. Ideally yes but it may not make it into the 1.0.0 release.

I am going to use the cool Tiny Shell library to help create a basic user shell application. A more advanced shell can be ported across (or written from scratch!) at a later date. The tiny shell library doesn't require a C library which suits at the moment. Only console read and write support is needed. It supports command history, auto completion, help and usage information. The shell will have some internal commands to perform operations like spawning a new process and navigating and manipulating the file system. Although I have this coded and ready, the kernels process manager subsystem will need to be finished and the process loader written before we can start running this stuff.

More code committed to CVS, should probably run off a 0.4.0 build at some point soon. Have finished the guts of VFS and completed the DFS also. Have begun back coding the FAT file system driver. Currently we can mount a FAT file system via vfs_mount() and list the contents of directory's with the vfs_list() function. The next goal is to finish the FAT driver and move on to process loading and creation in the process manager sub system. The floppy driver only supports reading at the moment so that will need to be expanded to perform write operations also! Ideally I want IDE hard drive support by the 1.0.0 release but we will see how strapped for time things get by the March deadline.

Committed a reworking of the IO subsystem and included the first steps in the file system. Ala the diagram below, the file system will be composed of a thin layer called the Virtual File System (VFS) which will marshal all file io between the file system drivers and the user. The basic calls like open(), close(), read() and write() will be available as system calls to user space. The default file system driver will be for the FAT format. A Device File System (DFS) driver will be present to allow file io operation to be performed on device drivers. The DFS will communicate with the IO subsystems IO controller layer to marshal communication between the device drivers. File system drivers will register themselves with the VFS whereby we can proceed to mount a volume of that type into the main file system tree. A system call of mount() and unmount() will be available for this. A system call load() will be available to dynamically load new drivers into the system.

The project is coming along nicely, although I’ve neglected the blog for a good while. The IO subsystem is nearly in place and some default device drivers have been written. I have drivers for the keyboard, VGA video display, virtual consoles (AMOS supports 4 virtual consoles, you can switch between them with keys F1 to F4), a simple floppy driver is in place that currently only supports read operations. A bitbucket (read /dev/null) driver is also available. The Virtual File System (VFS) has a bare bones FAT file system driver that can read directory contents at the moment.

Next on the development agenda is to complete the IO Subsystem and finish the default drivers. Then the VFS will be written and the FAT file system driver completed. I will then concentrate on the Process Manager and get process loading sorted along with implementing the system call interface.

The latest code as always is in CVS.