Specifications

CHAPTER 6. REQUIREMENTS VERIFICATION 57
6.2 Performance
The performance requirements specify that the Input Abstraction Layer should only use a
reasonable amount of system resources while running. To evaluate the consumption of system
resources, the Input Abstraction Layer’s run-time behavior was observed with top(1). This
program provides a dynamic real-time view of the processes’ resource consumption running on
a system. The common requirements such as low memory usage and low CPU utilization are
fulfilled. The daemon does not have a negative impact on the general system performance.
The event loop of the Input Abstraction Layer’s daemon ensures the reliable delivery of input
events occurring on the different input interfaces. The user space applications using the Input
Abstraction Layer’s output interface to gather input events do not have to poll the interface
which is demanded by the performance requirements, too. Applications can utilize several D-
BUS bindings to create callback functions once an input event is sent to the D-BUS interface
of the Input Abstraction Layer.
To evaluate the period of time an input event takes to reach user space applications, the
kernel driver iallatency (Appendix D, §D.3) has been implemented. Using this driver, it is
possible to measure the time from the input device driver to the receiving of the event by a
user space application. Several internals of the Linux kernel have to be discussed first in order
to understand the approach of the implemented driver.
Depending on the input device’s implementation, input events are reported either by gen-
erating an interrupt or by storing the event in a specific hardware register, which needs to
be polled. Interrupt-driven devices are generating interrupts once an input event happens.
This interrupt is relayed by the device’s controller to the system’s interrupt controller which
sends a signal to the processor. Subsequently, the processor notifies the Linux kernel about the
interrupt, which handles it appropriately. The interrupt handling in Linux 2.6 is described in
depth in Chapter 5 of [Lov03]. For example, if a keypress on a regular keyboard is issued, the
keyboard controller generates an interrupt. The processor receives the interrupt and notifies
the Linux kernel about the interrupt. The kernel correspondingly calls the interrupt handler
for the occurred interrupt.
Devices which do not generate interrupts need to be polled. This polling can either be
initiated in kernel or user space. Device drivers which are polling in kernel space use kernel
timers for this approach. Beside others, a kernel timer (declared in <include/timer.h>) has
the members expires and data. The member expires specifies the point of time at which
the callback function defined by data is executed. Kernel timers are controlled by kernel’s
interrupt handler for the timer interrupt. If a device driver does not use kernel timers to poll
the device, the driver is required to export a user space interface to implement the polling. For
example, the driver creates an interface using the proc file system. Once a user space process
accesses this interface by issuing a system call (open(2), read(2)), a corresponding function
of the kernel driver is executed.
The addressed timer interrupt occurs every 1/HZ second. The kernel defines the HZ default
value to 1000 on the i386 architecture—the timer interrupt runs each millisecond. During each
timer interrupt the global kernel variable jiffies of type unsigned int is incremented by
one. Since jiffies is initialized with 0 at boot time, the system’s uptime can be calculated
with the values of jiffies and HZ:
uptime =
jiffies
HZ
s