IOCTL_HAL_INITREGISTRY and its place in the boot order

I'll start by saying that this is intended for OEM platform developers.

When you develop an OSDesign it usually supports several hardware configurations. One of the first questions that arises is where in the boot process can we decide what is the configuration we are running on and which drivers should we enable. For this purpose Microsoft introduces IOCTL_HAL_INITREGISTRY.

This OAL IOCTL is called in the boot phase. The description by Microsoft is:

It is called before other applications are started, so the OAL can modify registry settings used by all applications.

This is where this post comes in. From what I have experienced, using Hive Based registry, the registry that is available in this function is the Hive Boot section. Any change that is done to the registry will be merged (override) to the boot phase of the device manager.

The delicate points to pay attention to are:

1. Changes that have been saved before the last restart are not reflected in the current state of the registry.
2. After this function finishes the device manager is loaded. This means that boot phase one relies on the updated registry. So, if you add driver entries in this functions you may encounter weird problems in the loading order of drivers (suddenly drivers will load in boot phase one when they were not supposed to be avialble yet).

To solve number 2 I use the following solution:
Say I have two hardware implementations for a USB controller (revision 1.2 of the HW has a differnet controller than revision 1.1). This means I need two different code paths to initialize the hardware. Admittedly, there are many ways to implement this, but what I do is put two different drivers in the source code and add two different entries in the registry. When the IOCTL_HAL_INITREGISTRY is called I update the flags entry of the corresponding drivers based on the revision of the board.

Additional reading:
How to set up an OAL IOCTL