whitix.org

If you’ve been following the development of Whitix, you may have noticed talk of a new filesystem, the Information and Configuration Filesystem (IcFs). What does that mean? What does it do? In this new series of articles, I hope to answer some of the questions and reveal the inner workings of this new unified approach to operating system configuration and device management, and how it interacts with the KeObject subsystem.

A short history

From the beginning of Unix in the 1960s a stream model was used for device input and output. Using standard system calls such as open, close, read and 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, 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 proc filesystem. Originally designed for process information exclusively, 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, 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, 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 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, DeviceIoControl, a ioctl equivalent, must be used.

Device configuration

In a modern operating system, configuring drivers and their devices is usually performed through a single system call to the kernel, ioctl in UNIX-like kernels such as Linux and Apple’s Darwin, and DeviceIoControl in the Windows NT kernel. This approach has several downsides:

• No clear interface. The ioctl system call lacks any kind of clear interface, and adding a new ioctl case to a function is like adding another system call without a clear definition.
• No filesystem access. Devices and kernel objects can only be configured by user applications calling 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.
• Lack of security. Since 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.

Device management

In the age of hotplugging,  devices are removed and added to a running system constantly. A variety of applications need to know when such changes occur, usually by waiting for a new device to appear.  Device management under UNIX-like operating systems has generally been performed using ioctl, and more recently sysfs (in Linux), which expose devices (abstracted as “kernel objects”, or kobjects, using composition). Linux’s sysfs implementation has the following disadvantages:

System information

Coming soon..

Until next time..

No desktop operating system kernel offers a single interface for CRUD operations on kernel objects and subsystems. Whitix’s IcFs plans to solve these problems. The new filesystem also addresses a number of disadvantages with the numerous current approaches. In the next article, we’ll cover the disadvantages of ioctl and other OS-specific ways of configurating and manging devices. Thanks for reading!

Tags: development