Fix IOKitTest for M1 compatibility

[dbwiddis]

Fixes test failure reported in #1419

[matthiasblaesing]

Thank you for the update. The test system I currently have available still fails though. I get this:

   [junit] 
    [junit] Testcase: testIteratorParentChild(com.sun.jna.platform.mac.IOKitTest):	FAILED
    [junit] expected:<[AppleUSB]> but was:<[usb-drd1]>
    [junit] junit.framework.AssertionFailedError: expected:<[AppleUSB]> but was:<[usb-drd1]>
    [junit] 	at com.sun.jna.platform.mac.IOKitTest.testIteratorParentChild(IOKitTest.java:170)
    [junit] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
    [junit] 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    [junit] 

If I update that check to:

            assertTrue(controllerName.startsWith("AppleUSB") || controllerName.startsWith("usb-drd1"));

I hit the next wall:

    [junit] 
    [junit] Testcase: testIteratorParentChild(com.sun.jna.platform.mac.IOKitTest):	FAILED
    [junit] null
    [junit] junit.framework.AssertionFailedError
    [junit] 	at com.sun.jna.platform.mac.IOKitTest.testIteratorParentChild(IOKitTest.java:180)
    [junit] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    [junit] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
    [junit] 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    [junit] 

I have to see whether I can learn enough about the structure and have a go myself. I think this is a bit like #1419, if you have acccess and a feeling where to look, it becomes easy, but if you are missing either, you poke in the dark.

[dbwiddis]

There's a tool "IORegistryExplorer" if you have desktop access. For ssh, the command line to "explore" is ioreg -p <plane> where the relevant planes here are IOService and IOUSB. The output will show you the names and classes involved.

Looking back at the reported issue I can see the "controller name" as you are seeing and should have double-checked that with my "fix", but it also appears the "class name" of the root hub simulation is no longer "IOUSBDevice" which I didn't test for. It might be that rather than skipping the test, we just don't make assumptions about names. We're really testing the parent/child and non-null should be good enough.

USB Devices:
 usb-drd1
 |-- AppleT8103USBXHCI
 usb-drd0
 |-- AppleT8103USBXHCI
 pcie-xhci
 |-- AppleT8103USBXHCIFL1100
     |-- USB Receiver (Logitech)
 pci1b73,1100
 |-- AppleUSBXHCIFL1100
 pci1b73,1100
 |-- AppleUSBXHCIFL1100
     |-- ThunderSync3-16 (cambrionix) [s/n: 0000001484CDF670]
         |-- FT230X Basic UART (FTDI) [s/n: DM01XOGG]
     |-- ThunderSync3-16 (cambrionix) [s/n: 0000001484CDF670]
 pci1b73,1100
 |-- AppleUSBXHCIFL1100
     |-- PS15-USB3 (cambrionix) [s/n: 00000036C0C4888E]
         |-- PS15-USB3 (cambrionix) [s/n: 00000036C0C4888E]
         |-- USB2.0 Hub (cambrionix)
             |-- iPhone (Apple Inc.) [s/n: 00008030001A2CCC11D3802E]
         |-- USB2.0 Hub (cambrionix)
             |-- PP15S (cambrionix)
                 |-- PP15S (cambrionix)
                 |-- PP15S (cambrionix)
                 |-- PP15S (cambrionix)
                 |-- PP15S (cambrionix)
                     |-- FT230X Basic UART (FTDI) [s/n: DJ00JPX2]
         |-- USB2.0 Hub (cambrionix)
         |-- USB2.0 Hub (cambrionix)
             |-- iPhone (Apple Inc.) [s/n: ddbcd85aef2013b787d8f8d65e40f39bc9e4f253]
     |-- PS15-USB3 (cambrionix) [s/n: 00000036C0C4888E]
         |-- USB3.0 Hub (cambrionix)
         |-- USB3.0 Hub (cambrionix)
         |-- USB3.0 Hub (cambrionix)
         |-- USB3.0 Hub (cambrionix)
     |-- iPad (Apple Inc.) [s/n: 03dd14581f7c4bd686b4d7276dc59201fcee8cc2]
 pci1b73,1100
 |-- AppleUSBXHCIFL1100
     |-- Android Phone (HTC) [s/n: FA65RBN01184]
     |-- iPad (Apple Inc.) [s/n: c13d62e0c8bef04ff4b48b4748b020be76725d5d]

[dbwiddis]

(I'm thinking it would work if we restricted the child search to controllers beginning "pci" but also I think just removing the name check would work.)

[matthiasblaesing]

Based on your suggestion (to focus on the relationship) I pushed an updated version into #1419 and also ensured that appveyor is happy again. Could you have another look there?

[dbwiddis]

LGTM!