Tom has been busy fixing and extending relayfs in the last few months. We now have a fully functional printk on relayfs, allowing dynamic resizing and very large buffers at startup. Your feedback and testing is always welcome.

Thanks to the dedicated work of Tom Zanussi (IBM), the first implementation of relayfs is now available for download. Click on the sidebar to download the patch. Patches are also available for running the Linux Trace Toolkit, one the many anticipated clients, on relayfs. These patches and details on their use are available here.

• printk() on relayfs
• LTT on relayfs

As the Linux kernel matures, there is an ever increasing number of facilities and tools that need to relay large amounts of data from kernel space to user space. Up to this point, each of these has had its own mechanism for relaying data. To supersede the individual mechanisms, we introduce the "high-speed data relay filesystem" (relayfs). As such, things like LTT, printk, EVLog, etc. should all use relayfs to get their data to user-space. The use of relayfs would, for example, avoid lost printk's. It would also result in the standardization of the way in which large amounts of data are transferred from kernel space to user space.

The main idea behind the relayfs is that every data flow is put into a separate "channel" and each channel is a file. In practice, each channel is a separate memory buffer allocated from within kernel space upon channel instantiation. Software needing to relay data to user space would open a channel or a number of channels, depending on its needs, and would log data to that channel. All the buffering and locking mechanics are taken care of by the relayfs.