How to implement NVMESMARTLib for USB-NVMe bridge chip?

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?

Answered by DTS Engineer in 794635022

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:

  1. 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.

  2. 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

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:

  1. 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.

  2. 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

Hi Kevin,

As you say neither of these is suitable since the volume is expected to be mounted and in use. I think this is still possible with a kext though?

I will file an enhancement request since a DriverKit solution would also work on iOS / iPadOS which relates to the other question you answered for me the other day.

As you say neither of these is suitable since the volume is expected to be mounted and in use. I think this is still possible with a kext though?

Yes, but that's not an approach I can really encourage. We're aggressively discouraging KEXT development and I can't recommend the engineering effort required, given that reality.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks Kevin,

I have created FB14275983

How to implement NVMESMARTLib for USB-NVMe bridge chip?
 
 
Q