Based on our knowledge of the internals of BSD-like general-purpose operating systems and our experience with the implementation of the NetApp Auto-diagnosis System, it appears that it should be relatively straightforward to implement an auto-diagnosis subsystem based on the techniques presented in this paper in BSD-like systems. Like in ONTAP, a kernel thread can be used to implement continuous monitoring. The rules and thresholds used by the continuous monitoring logic can be chosen based on field information about the problem situations being targeted. The continuous monitoring logic can be partitioned into sub-logic blocks for each major OS subsystem.
The specific active tests to be implemented will also depend on the field problems being targeted. Protocol augmentation and cross-layer analysis can be used as guiding principles in the design of such tests. The implementation of active tests triggered automatically by the in-kernel auto-diagnosis logic should be relatively straightforward. If a command-based approach (like our diagnostic commands based approach) is to be used for user interaction, the BSD kvm kernel memory interface may be used for transferring information between the in-kernel continuous monitoring logic and user-land diagnostic commands. Alternatively, an approach based on the /proc file system may be used.
Special interfaces will be needed for commands to trigger in-kernel active tests. Again, several alternative approaches are possible. The tests may be enumerated and made available as a series of system calls or different ioctls for a special diagnostics pseudo-device. For some active tests, it might also be possible to write the tests entirely in user-space using low level kernel interfaces (e.g. raw IP sockets). Extensibility can be provided by implementing the kernel portion of the auto-diagnosis logic as one or more loadable kernel modules.