Closed EAGrahamJr closed 10 months ago
Looks like I'm making a few too many assumptions in LocalSystemInfo while attempting to detect the local board. What O/S are you running the remote client on? I see it is reported as "Linux-amd64" - I made the assumption that all Linux runtimes have '/proc/device-tree/model' and '/proc/device-tree/compatible'. I run macOs so don't normally test this - let me try in a VM.
Ah - the deal is I'm specifically using the GRPC remote provider, so I don't think there should be a local-library check at all.
Yep - saw that. The LocalBoardSystemInfo is triggered by the call to load the system utils JNI library in DeviceFactoryHelper. I use that as a useful general initialisation point to load this library. The only operation that I think could be called in this scenario is the sleepNanos method that I don't believe is actually required - LockSupport.parkNanos should be used instead. Agree?
Concur - if a provider is set via the property, I don't see why loading the library would be required.
Ok, have removed it from there. It probably is a useful warning message when being loaded from the DefaultDeviceFactory given how much of the auto discovery relies on it.
Well, I just managed to chase my own tail, so I'm not sure how much help I'm going to be untangling this. When running tests with this set:
System.setProperty(DEVICE_FACTORY_PROP, "com.diozero.internal.provider.mock.MockDeviceFactory");
I'm getting this now:
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
22:29:42.567 [main] WARN com.diozero.sbc.LocalSystemInfo.populateFromDeviceTreeModel - Unable to process file '/proc/device-tree/model': java.nio.file.NoSuchFileException: /proc/device-tree/model
22:29:42.601 [main] WARN com.diozero.sbc.LocalSystemInfo.populateFromDeviceTreeCompatible - Unable to process file '/proc/device-tree/compatible': /proc/device-tree/compatible: java.nio.file.NoSuchFileException: /proc/device-tree/compatible
at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at java.base/sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:181)
at java.base/java.nio.channels.FileChannel.open(FileChannel.java:298)
at java.base/java.nio.channels.FileChannel.open(FileChannel.java:357)
at java.base/java.nio.file.Files.lines(Files.java:4132)
at java.base/java.nio.file.Files.lines(Files.java:4227)
at com.diozero.sbc.LocalSystemInfo.populateFromDeviceTreeCompatible(LocalSystemInfo.java:206)
at com.diozero.sbc.LocalSystemInfo.<init>(LocalSystemInfo.java:129)
at com.diozero.sbc.LocalSystemInfo.getInstance(LocalSystemInfo.java:101)
at com.diozero.internal.board.GenericLinuxArmBoardInfo.<init>(GenericLinuxArmBoardInfo.java:75)
at com.diozero.internal.provider.mock.MockDeviceFactory$MockBoardInfo.<init>(MockDeviceFactory.java:348)
at com.diozero.internal.provider.mock.MockDeviceFactory.<init>(MockDeviceFactory.java:108)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at com.diozero.sbc.DeviceFactoryHelper.initialise(DeviceFactoryHelper.java:69)
at com.diozero.sbc.DeviceFactoryHelper.getNativeDeviceFactory(DeviceFactoryHelper.java:108)
at com.diozero.internal.spi.AbstractDeviceFactory.<init>(AbstractDeviceFactory.java:57)
Closing this as original issue has been fixed long ago...
While this doesn't actually stop anything from working, it is a little annoying and it seems like if the remote provider is set up, this wouldn't necessarily be invoked (working on my expander board):