Windows inbox NVMe driver vs OSR NVMe driver

Hi all, apologize for asking this if it sounds stupid, I am new to this group. Perhaps this has been asked before already. With Windows 8.1 / Server 2012 R2 are now come with a buildin driver supporting NVMe. How user can use a third party NVMe driver (i.e. OSR developed NVMe driver) instead when inbox NVMe driver still in the system? In other words, how can I change the system driver loading order so it knows always load third party NVMe driver instead of using inbox MS driver?

Thanks ahead for the kind reply!

Does your hardware work with the included NVMe drivers? Or is the
situation more like you present a device id that is matched by the NVMe
driver, but your device doesn’t actually function correctly?

To get your YOUR driver to be chosen over the included NVMe driver you can
do a number of things: 1) make your driver have a “better” PnP ranking
match, 2) have an installation program that forces your driver to a
specific device using the setup API’s, 3) have a way for you device to
change it’s device id, so on command it stops being a device the NVMe
driver is compatible with, 4) you have a device installer class
coinstaller that modifies the driver selection algorithm (this is often a
bit of a chicken and egg problem though, as your coinstaller generally
would not get installed until the first install of your driver so can’t
filter the driver selection process before it’s installed), 5) you expect
the user to manually update the driver with your driver as the search
path. Given that NVMe is typically a server technology, it’s not
unreasonable to require users to have your drivers preinstalled in the
image loaded onto a new server. Datacenter customers don’t install OS’s by
inserting a retail install DVD into a drive, they frequently use automated
system configuration tools (like System Center). If this is the case, what
your customers may want is a driver package that easily is loaded by the
automatic configuration tools, and lots of the driver selection issues you
might find in a local development environment are just not an issue in
production.

Related to this is you could get your driver that is a better PnP ID match
findable on Windows Update, so on initial install the OS pulls your driver
from the Microsoft update server instead of falling back to a generic
driver.

You might also consider filtering the request to the NVMe driver, letting
it handle generic ones, and you translate custom ones into something that
can be passed through the NVMe driver.

There are other devices that have a similar situation: 1) video cards will
often default to a software based basic driver is no hardware specific
driver is found, 2) same for SATA controllers. You might experiment with
the behavior some of these other devices have, and decide if you like the
user experience supported by other IHVs.

What get’s a bit trickier is if you the IHV, get your driver included with
Windows, using very specific PnP ids, and then you decided you want to
load some new generation of drivers. I believe this is especially tricky
if your included driver supports a bunch of devices, that all have very
specific PnP ids in the included INF, and you want to then have some
subset of those use a different driver. Also note that over the years, the
PnP match algorithms have evolved.

If you’re ok having a user experience of running a user mode driver setup
program, you can pretty much force what you want to happen. If you want
during OS install, or first device detection, for the OS to just find your
optimal driver from the cloud, it’s a little harder (although often still
doable).

I would suggest you carefully understand how you customer’s operations
will likely be installing your device/drivers, as this really determines
what they need to work smoothly. Some sequence of steps that you find
simple on one development system, may be really annoying in a remote
automated operation environment. It may also be the case that a bunch of
manual steps to build a master image that will be applied against 5000
systems might not be viewed as annoying at all, especially as those steps
will likely get scripted, and the script improved over time. Also note
that datacenter folks like installing specific versions of things, not
“the latest version that happens to download today”, as their whole
operation environment may be version controlled. For a consumer device,
you need to assure the out-of-box experience is simple and painless and
correct for a wide variety of target configurations.

Just my $0.02 (although since I have mostly worked on enterprise
datacenter products for the last decade, perhaps my suggestions are worth
$0.03).

Jan

On 2/4/15, 7:40 AM, “xxxxx@gmail.com” wrote:

>Hi all, apologize for asking this if it sounds stupid, I am new to this
>group. Perhaps this has been asked before already. With Windows 8.1 /
>Server 2012 R2 are now come with a buildin driver supporting NVMe. How
>user can use a third party NVMe driver (i.e. OSR developed NVMe driver)
>instead when inbox NVMe driver still in the system? In other words, how
>can I change the system driver loading order so it knows always load
>third party NVMe driver instead of using inbox MS driver?
>
>Thanks ahead for the kind reply!

The answer to this, like all really good technical questions, is “it depends.” This is essentially what Mr. Bottorff indicated.

Ultimately, the problem is very simple to solve… but the specific steps required will depend on who “you” are, what hardware you want to support, and a whole host of other things.

If you want answers that are specific to the OSR NVMe Driver, please email your contact at OSR and we’ll be happy to answer your questions in detail. But, be assured, no matter what… the answer is “it’s simple… we do it here at OSR every day.”

Because this is not the OSR Product Support forum, and we don’t allow commercial activity on this list, I’m going to lock this topic. That’s not because you’ve done anything wrong or asked an improper question. Rather, it’s because we, as the owners of this forum, don’t want anyone reading this to misunderstand and think we’re using this list for OSR’s private purposes.

Don’t hesitate to email OSR directly and we’ll be very happy to help.

Peter
OSR
@OSRDrivers