Driver softwares are important part of Operating System as it allows the OS to communicate with a hardware device or a software component. Drivers act as a translator between the OS and the device or component, enabling them to exchange data and instructions. Drivers runs in high priviledge level or the Kernel Land. The Kernel land is highly priviledged level, means it has all the power over the hardware. In XenevaOS, the driver software uses Kernel provided functions to communicate with hardware and prepares an environment for the Kernel to control the hardware. Both are inter-dependent.
Development of XenevaOS is done purely under Windows environment. Xeneva project uses Visual Studio and its compiler collection. Visual Studio 2013, 2019 or later version are recommended. [NOTE]:Before beginning driver development, please make sure to setup Xeneva development environment, visit Build Instructions.
XenevaOS project includes certain Naming conventions.In XenevaOS driver development naming conventions plays a crucial role in supporting Backward compatibility. Early XenevaOS supported FAT32 file system with no long name entry support. XenevaOS drivers names are limited to maximum 8 characters extra three characters are reserved for extension, as FAT File system without long file name entry supports maximum 11 characters in file name. We recommend limiting the driver name up to 8 characters.
Current version of XenevaOS supports only Kernel mode drivers. The Kernel mode drivers are divided into two types:
You can read detailed information about each driver in About XenevaOS Driver
Information on Initialization and Unloading of XenevaOS drivers can be found here. Xeneva Driver must implement two basic driver functions:
See here for a simple driver example.
Memory Management is very important part of XenevaOS driver development. It’s the most critical aspect of the system stability, as improper handling of memory can lead to severe crashes or unpredicatable behavior. Since drivers operate at a low level with direct access to system resources, any mistake in Allocation, Deallocation, or Access can corrupt kernel memory, causing system instability or even a complete crash. Proper use of Physical Memory Allocation/Deallocation and kernel heap Allocation/Deallocation are recommended. Memory management are divided into three parts-
Once the system enters userspace the physical addresses are not accessible, trying to access physical address will cause the system to enter Page Fault Exception. For example consider, ‘0xFE000000’ a physical address and is an address of some hardware. Writing to this address will cause some commands to the hardware. Say, we write the value “1” to offset 0x4 of the physical address ‘0xFE000000’ which looks like *(0xFE000000 + 0x04) = 1,which will cause the hardware to enter into reset state. And suppose this entire situation happened after Xeneva entered user space and starting of user services. This will cause the system to enter Page Fault Exception, because before the system transition into user world, the entire physical memory mappings are cleared from the Kernel address space and the physical memory mappings are always present in lower half of address space, the lower half is completely cleared for user space memory mappings. Somewhere we need a trick to map this hardware address so that we can access the hardware through this mapped address. And here we use Xeneva MMIO Mappings.
There are two reason -
MMIO are mapped through ‘AuMapMMIO’ function call, AuMapMMIO(uint64_t physicalAddr, size_t sizeOfTheAddress), Once mapped successfully, it will return the virtual address where you can write to give command to or control the hardware.
Section describing PCIe management, interrupt handling and synchronization, Memory Management, and Kernel resource allocation will be available soon