Browse Prior Art Database

Logging kernel events in user trace buffer

IP.com Disclosure Number: IPCOM000015465D
Original Publication Date: 2002-May-21
Included in the Prior Art Database: 2003-Jun-20
Document File: 1 page(s) / 48K

Publishing Venue

IBM

Abstract

Abstract

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 1

Logging kernel events in user trace buffer

Abstract

This article describes a method and an application for logging kernel events in user address space. These events may be general kernel events, but the presumption is that they are events that are related to the specific task in which they are being logged.

Overview

In both kernel code and user applications, events are often logged as a tool to aid debug. Events in user space might include function calls or some other unit of processing. Events in kernel space might include hardware interrupts, timers or context switches. Two important limitations are that it is often difficult to get a single global ordering of the system events and that many of the kernel events pertain to a specific task or pair of tasks. For example, a context switch is an event that the kernel sees that is transparent to the application task, but the context switch pertains to the application task.

It is difficult for the application to log these events since it has no obvious handle on when the context switch or other kernel event happens. The technique described here uses a data structure that resides in user space and that the kernel can access and manipulate. The basic functions for the kernel to manipulate data structures exist for device drivers in the kernel. These device drivers normally need the capability to copy data from the user space to a device or from the device to user space. In this method, the functions are used to move the data in the event buffers from user space to kernel space and from kernel space to user space.

Race conditions & interleaving events

In this scenario, the user task and the kernel are sharing the data structure that contains the event logging. Like any two processes sharing a data structure, there must be mechanisms to prevent the standard race condition errors that shared data may have. However, the standard methods (flags and semaphores) are not viable for this kind of application. The goal was to make event logging in the application task a lightweight mechanism. To make a system call to a kernel semaphore function every time the application task was going to log an event would be unacceptable.

As an alternative, the kernel logs events in a small side buffer in the application space...