root/Whitix/publications/kernel_configuration.tex

\documentclass[11pt,twocolumn]{article}
\usepackage{abstract,footmisc}
\begin{document}
\title{A new approach to kernel configuration and object management}
\author{Matthew Whitworth \\ Imperial College London
\\ \texttt{mtw07@doc.ic.ac.uk}}
\twocolumn[
\maketitle
\begin{onecolabstract}
Configuration of kernel objects in today's operating system kernels is either inconsistent, unstable,
unextendable or not unified. This paper introduces and explains the Whitix kernel's configuration
system, \texttt{SystemFs}, which features a consistent, stable and unified API and filesystem interface for non-peristent
create, read, update and delete (CRUD) operations on kernel objects and subsystems in user space and kernel space.
\end{onecolabstract}
]
\section{Introduction} \label{section:introduction}
From the beginning of Unix in the 1960s a stream model was used for device input and output. Using
standard system calls such as \texttt{open}, \texttt{close}, \texttt{read} and \texttt{write}, any application with
sufficient privileges, including the shell, could manipulate system devices with ease.

However, it was clear by the release of Bell Labs' Version 7 Unix that a simple read/write interface
for device I/O would not be sufficient for devices of ever-increasing complexity. The developers added a new system call,
\texttt{ioctl}, that would enable device creation, configuration and retrieval of information.

System developers and administrators soon required a way of retrieving information about the system in general,
along with its devices. Plan 9 from Bell Labs, the research successor to Unix, invented the \texttt{proc} filesystem.
Originally designed for process information exclusively, \texttt{proc} allowed the kernel to expose information about system
internals to any application. The filesystem was later adopted by the Linux kernel and the BSDs, and expanded to include virtually
everything about a running system.

The 2.6 release of the Linux kernel added another kernel filesystem, \texttt{sysfs}, intended to present the kernel's
device model to userspace in a read-only fashion to track device and subsystem updates and other system changes. Another filesystem,
\texttt{configfs}, was introduced in 2.6 for creating and destroying devices, as well as modifying device attributes,
but it has not seen wide adoption and kernel developers note that it duplicates many of the functions of \texttt{sysfs}.

The Windows NT line of kernels is thought to expose the device filesystem in a similar way to that of Linux, although
device files and system information is not mounted on the filesystem. The Windows Executive has an Object Manager, which manages
resource management in the kernel. Reference-counted objects, such as devices and file handles, are created and managed, and any system call
that modifies resource allocation goes via the Object Manager. However, to configure devices and other objects,
\texttt{DeviceIoControl}, a \texttt{ioctl} equivalent, must be used.

As of 2008, no desktop kernel offers a single interface for CRUD operations on kernel objects and subsystems. Whitix's
\texttt{SystemFs} plans to solve these problems. The new filesystem also addresses a number of disadvantages with the numerous
current approaches, listed below, as well as simplifying kernel system calls and increasing driver security.
\section{Current approaches} \label{section:current approaches}
\subsection{System and device information}
Current operating systems expose information about the system and its device through a filesystem interface. In Linux,
this is achieved through \texttt{/proc} and \texttt{/sys}, which contain information about the system and the system's devices respectively.
There a number of disadvantages with the current filsystems:
\begin{itemize}
\item temp
\end{itemize}
\subsection{Device configuration}
In a modern operating system, configuring drivers and their devices is usually performed through a 
single system call to the kernel, \texttt{ioctl} in UNIX derivatives such as Linux and
Apple's Darwin, and \texttt{DeviceIoControl} in Windows NT and its successors. This approach has several downsides:
\begin{itemize}
\item \textbf{No clear interface}. The \texttt{ioctl} system call lacks any kind of clear interface, and adding \\
a new \texttt{ioctl} case to a function is like adding another system call without a clear definition.
\item \textbf{No filesystem access}. Devices and kernel objects can only be configured by user applications calling \texttt{ioctl}. Technical users who wish to configure a device have to find an application that does so or create one themselves; the latter is \\
common if the device is very new or obscure.
\item \textbf{Lack of security}. Since \texttt{ioctl} is called from user code and accepts user parameters, a number of checks
must be performed on these parameters before they can be used. Failure to do so may result in buffer overflows or invalid data being written
to devices.
\end{itemize}
\subsection{Device creation and removal}
\section{SystemFs, a replacement}
\section{SystemFs operations}
\section{Implementation status}
\section{Future improvements}
\section{Conclusion}
\section{Acknowledgements}
\bibliographystyle{acm}
\bibliography{kernel_configuration}
\end{document}