The dynax cross platform open source driver development framework provides common C++ driver and device classes to ease kernel und user mode driver development as well as driver interface integration in user mode applications. The kernel framework is based on interface implementations for KMDF (Windows), IOKit (macOS) and Linux (planned).

The dynax driver framework consists of two main parts:

• the kernel driver platform abstraction providing platform independent
  • C++ skeleton with virtual methods for driver event handling and standardized default event handling
  • device classes for USB, PCI(e), FW, etc.
  • resource classes for isr handling and device resource access
  • threading and synchronisation classes
  • generic interface classes for PortClass Audio/MIDI and CoreAudio
  • generic streaming interface
• the user mode driver interface providing platform independent
  • driver and device classes for interfacing hardware
  • user mode only driver device classes for USB (IOUSBFamily, WinUSB)
  • notification mechanism for standardized default PNP handling
  • communication and synchronisation classes
  • generic streaming interface
  • generic interface classes for CoreMIDI and CoreAudio server plugins, ASIO
• also it features a command line test suite conducting
  • automated driver unit tests
  • automated streaming test
  • configuration and informational device and driver access

Implementation design rules:

• light weight implementation, adding as less as possible overhead
• synergetic code usage
• enable the user to reduce the code only to tasks handling specific device features
• sparse as possible implementation code
• strictly uncompromised object orientated design
• separation of flow and error control
• typesafty avoiding unclassified pointers and casting wherever possible
• strict RAII (let only the compiler create the code of balanced initialization and deconstruction)
• destruction always succeeds: a destructor never throws an exception.
• all object parameters are reasonably checked (ofcourse pointer validity can not be ensured without overhead, so its only checked against null pointer.
• it is always valid to directly forward an dx/dxd object as a parameter to another dx/dxd object. Validity is ensured.

User space

• Object construction might fail with exception.

Kernel space

• Object construction might fail with object status. Always check object status!

git repository

please request git read access by inquiring to dxd@d.nosp@m.ynax.nosp@m..at

• https://dynax.at/dxd.git
  • stable release at tags of main branch
  • unstable current develop branch

Speed

The framework is lightweight. It precisely executes only the needed kernel KPI. If drivers are slow than due to a bad design and its inherent workarounds. dxd provides the means to help with a clean design, with less pitfalls. dxd takes care about tedious and error prone KPI requirements and therefor avoids the implementation of slow workarounds due to KPI misinterpretation and OS bugs.

C++ in the Kernel???

The dynax driver framework uses a subset of C++ without real exception handling and RTTI runtime type information.
However dxd does provide some kind of exception handling semantics based on macros. This way you can get at least most of the error handling out of the way of the drivers program flow.
There is a rather religious discussion about C++ and kernel development. You can loose your time and join the discussion or just get your driver done - probably faster in C++, better structured and platform independent with the support of dxd.
dxd classes do provide a way around most kernel pitfalls. Its uncompromised object orientated design helps keeping your code safe, fast, small, nice and clean.
you may spent the extra spare time and do something useful.