Re: [XENBUS PATCH v3 4/9] xenfilt: Add Xenbus device precedence mechanism

[Owen Smith <owen.smith@xxxxxxxxx>]

On Mon, Aug 4, 2025 at 4:35 PM Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx> wrote:

     Count = Relations->Count;
@@ -458,11 +460,32 @@ FdoEnumerate(
         ListEntry = Next;
     }

+    ActiveIndex = Precedence = 0;
+    for (Index = 0; Index < Count; Index++) {
+        ULONG   ThisPrecedence;
+
+        if (PhysicalDeviceObject[Index] != NULL) {
+            status = PdoGetPrecedence(PhysicalDeviceObject[Index],

There doesnt seem to be a reason for this call to be in pdo.c (it doesnt access a PXENFILT_PDO object) - it could be contained in driver.c, keeping most of the changes in fewer locations.

 

+                                      &ThisPrecedence);
+            if (ThisPrecedence > Precedence) {
+                ActiveIndex = Index;
+                Precedence = ThisPrecedence;
+            }
+        }
+    }
+
     // Walk the list and create PDO filters for any new devices
     for (Index = 0; Index < Count; Index++) {
 #pragma warning(suppress:6385)  // Reading invalid data from 'PhysicalDeviceObject'
         if (PhysicalDeviceObject[Index] != NULL) {
-            (VOID) PdoCreate(Fdo, PhysicalDeviceObject[Index], Fdo->Type);
+            LONG    ForceActivate = 0;

I'd prefer an enum to LONG, which should make it easier to identify force activation states at a glance.

 

+
+            if (Precedence > 0)
+                ForceActivate = Index == ActiveIndex ? 1 : -1;
+            (VOID) PdoCreate(Fdo,
+                             PhysicalDeviceObject[Index],
+                             Fdo->Type,
+                             ForceActivate);
             ObDereferenceObject(PhysicalDeviceObject[Index]);
         }
     }

Moving and renaming PdoGetPrecedence to driver.c and making the current DriverGetPrecidence only visible inside the driver.c file, would help with readability.

Owen