Many USB storage devices are NVMe devices accessed through a USB-NVMe bridge chip, such as those by JMicron and Asmedia. These chipsets do not forward SMART data requests to the devices, but do have the capability to forward raw NVMe commands to the devices using vendor specific requests.
How can we provide access to SMART data for NVMe devices accessed through a bridge chip like this?
Many people used the OSX SAT SMART kext driver to provide access to SMART data for devices using USB-SATA chips, but it is a kext and doesn't support NVMe. See https://binaryfruit.com/drivedx/usb-drive-support#install-instructions
Would we need to implement a kext like that to make this work? Is there a DriverKit way to do this?
Many USB storage devices are NVMe devices accessed through a USB-NVMe bridge chip, such as those by JMicron and Asmedia. These chipsets do not forward SMART data requests to the devices, but do have the capability to forward raw NVMe commands to the devices using vendor specific requests.
How can we provide access to SMART data for NVMe devices accessed through a bridge chip like this?
...
Would we need to implement a kext like that to make this work? Is there a DriverKit way to do this?
I can see a few different ways this could be done, though they're are some issue as well:
-
The simplest option would be to use the IOUSBHost framework to send custom USB commands to the device from user app. I haven't specifically tested this, so their may be an issue with mass storage devices (see below for more info) but this is the simplest to implement.
-
USBDriverKit can also be used to create a DEXT that provides similar functionality.
The issue with both of these approaches is that the system only allows one client to control the device at a time. Either approach will fail if any volume is mounted because the mass storage stack will have control of the device.
My best advice for full "real time" access (like our exist SMART user clients) is to file an enhancement request asking for the system to provide an API solution for this.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
