MAGNeT currently exists as a prototype implementation, and as such, its user interface is not highly refined. We plan to improve the interface by allowing the user to set various MAGNeT parameters (i.e., the kinds of events to be recorded, the size of the kernel buffer, etc.) at run-time rather than at kernel compile-time. This is possible by making the current /proc file writable and would greatly increase the usability and flexibility of MAGNeT.
Another potential area of improvement in MAGNeT is the mechanism used to store saved data from the kernel buffer to disk. As it is currently implemented, the mechanism works but requires a user well-versed in how to operate MAGNeT (or a script which takes care of the details for the user). A better approach may be to utilize kernel threads to perform all steps of the instrumentation. With this methodology, the need for the special device file, the file created by mkmagnet, and the kernel/user shared memory would be eliminated. In addition, kernel threads may lower MAGNeT's current low event loss rate by reducing the need for a context switch to save data. However, the execution of kernel threads can break an application's usage-pattern transparency which MAGNeT currently is able to achieve. Additionally, kernel threads may remove the ability of easily integrating MAGNeT data-collection facilities into new user applications. The use of kernel threads may be explored for future versions of MAGNeT, along with other options for improving this interface, such as the Turbo Packet scheme used by Alexey Kuznetsov to increase tcpdump's performance under Linux.
Timing with the CPU cycle counter can be problematic on contemporary CPUs which are able to change their clock rate in response to power-management policies. If the kernel can detect such changes, MAGNeT can easily hook into the clock-rate change detection code and output a new MAGNET_SYSINFO event with the new timing information. This would keep timing relatively consistent across CPU clock-rate changes. However, there is currently no way for production Linux kernels to detect CPU clock rate changes at run-time. 10