Review of aims
Provide an overview of the features making up an OS
This project provides a good overview of some of the core components required for a functioning operating system. This includes features of the kernel or core of an OS; methods of booting; managing memory and the provision of a file system. The background chapter had to be succinct for the purpose of the final aim of this project as whole books, manuals, and University semesters can be dedicated to simply the concepts an OS. This paper could have included material covering the management device drivers, networking, and provisions for sound and graphics. However, with time constraints and a near endless list of possibilities it could not have been more extensive in its topic coverage.
Discuss the portability of these features and the development of an architecture-free setup
Portability is covered in background and implementation, dealing with the boot process and specific CPU architecture instructions, respectively. Whilst this aim was not succinctly required for the purpose of developing a minimal OS, dealing with this topic is necessary in understanding part of the technical aspects of an OS. For future considerations, tailoring the development of the minimal OS for different, unrelated CPU architectures is worth considering. There is no mention of the methods and techniques other CPUs perform in order to complete similar tasks in memory management. Thus, providing a true abstraction, rather than just putting all the CPU-specific in its own subdirectory, may be more complicated.
Preform an examination of the minimal requirements for the implementation of a minimal OS for a choice of architecture
The strengths and weaknesses of the x86 architecture are discussed in background. Whilst deciding on it may have been the easier approach, it still does not compromise the overall design of the minimal OS. Measures can be taken, such as those discusses an architecture-free setup with the previous aim, to overcome the weaknesses. In addition to this, Chapter 3 detailed the features made available by the x86 architecture in order to begin working with an active memory ready for program execution cycles. This provided the means of delivering the basic operating system.
Discuss the requirements an OS must provide to meet the interpretation and functioning of a high-level language
Design details the minimal features necessary for providing program execution of a high-level language, such as JavaScript, and ends with a concrete list of all the necessary C functions needed for a high-level language engine, such as Duktape, to run. By doing this, the programming goals of the minimal OS was laid out, defining exactly the interfaces to be implemented. This step was critical for the overall goal of the project as it not only quantified the implementation but acts as method of determining the minimal functional requirements for providing any high-level language. This same approach, therefore, can be applied to other languages not considered in this paper to develop a similar minimal OS with similar capabilities.
Develop a guide and implementation of a simplistic OS including the infrastructure required by that of a high-level language
The guide provided in implementation only contains the infrastructure necessary for the minimal OS to start running JavaScript files. Whilst developed OS for this project makes use of an EXT2 file journaling system and an interface for processing keyboard interrupts to accept inputs to navigate directories and load files into memory, this was not a necessary goal of the minimal OS. This chapter could have contained these additional topics but did not. One justification for this is that rest of the OS from architecture and memory initialisations onward can be implemented in JavaScript and so providing these features were only included as a means of testing and evaluating the basic OS infrastructure \end{enumerate}
Revisions to Design and Implementation
Whilst the overall structure of the OS, specifically the source tree, remains viable, nuances such as how and where to put device drivers currently remains disputed. For instance, the keyboard and screen are considered devices worthy of remaining inside the kernel/ directory as they explicitly references abstractions to CPU architecture. This may not be the case for all devices nor should all devices have access to this kind of capability. In the latter case, exploits and vulnerabilities may emerge as a consequence and could be used to maliciously raise the privilege level. Therefore, greater provisions should be taken for devices which require access to I/O ports.
Future work
Whilst provisions have been put in place to provide the CPU with tasks with protected allocated memory, there are no measures taken to benefit from this initialisation. ISRs are implemented, but only account for system critical failures and dealing with the keyboard. There is a lot of opportunity still to provide a mechanism of executing tasks both dynamically (on-demand) and concurrently.s
The User Interface to the OS is very minimalistic. Its current visual representation echoes comparisons from OSs developed in the previous millennium. Whilst this may have a certain novelty, there is ample opportunity to provide procedures for displaying graphical images and renderings.
Furthermore, there is no arrangement of users. Throughout this thesis, an omnipresent OS ‘user’ has been referenced for the purpose of distinguishing the privilege levels offered by both the CPU architecture and memory management. This has simply been an operator of the computer itself rather than a distinguished, identifiable, and unique user themself. OSs available today typically offer a multi-user environment, providing someone access to the computer with a personal and safe working environment and storage directory. Both the security and personal persistent storage should be considered to complete this OS. This may take the form of a login screen requesting a username and password, and read and write access to a directory.
In addition to this, the kernel has not allocated segments for use by of the user. At this point JavaScript files can be executed but they are sharing memory space with regions of the OS which should be protected. Even though the OS itself may not have any practical uses yet, this protection is necessary is preventing unexpected memory errors. This can be implemented easily using the current interfaces.
Finally, Duktape offers a wide array of functions and capability. The current methods utilised in the OS for the purpose of managing the execution life-cycle of JavaScript are lacking considerably and require a significant degree of sophistication. In this implementation, strings are simply read into a buffer and passed onto Duktape for execution. Duktape offers extensive capability for managing how JavaScript is interpreted. Further provisions should be implemented, this includes dynamically loading and mapping native C functions to the engine itself; creating a standard procedure for loading, executing and deloading the Duktape engine; offering Duktape the ability to manage memory itself (giving JavaScript the power once architecture-specific initialisations are complete); and, consequently, delivering further OS fundementals, potentially, through JavaScript.
Final Remarks
With the overall goal of creating an operating system capable of running on a computer which supports x86 architecture, this thesis and project presents itself complete. The ability to run JavaScript files minimally on the OS, however, was a huge breakthrough, one which was doubted from the very beginning. Whilst initially the goal of this project was to simply develop a ‘Mini OS’, this additional capability required extensive additional work and research and so the process to complete this task was a huge personal undertaking. I was delighted with ability to work on this project from the start as I knew it would help develop my programming skills, clarify concepts, and prepare myself for future work. Whilst there were moments during the project where I felt incapable of “fixing the seemingly endless stream of bugs”, it always turned out to be simpler than expected. The languages and tools I was exposed to during this project, such as GNU Assembly/NASM and objdump have already started to help me with personal projects. Additionally, the quirks and strength of C is something I had not quite realised until now.