[nvmewin] the working order of faking NVMIdentify()

[Luse, Paul E]

Not sure if you got a response to this or not but it only does that for Chatham so none of this is really relevant for anyone else.  Chatham and Chatham2 do things differently, if your device cannot accept the cmd you want to send then you of course have to intercept it on the submission side as Chatham does.  If it can handle the command but you want different data you intercept it on the return side like we do with Chatham2.

From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P
Sent: Thursday, June 07, 2012 4:39 PM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] the working order of faking NVMIdentify()

Hi, I am a little confused on how the driver fakes returning an NVMIdentify value I was hoping someone could tell me how it's doing it?

I see in NVMeProcessIoctl() there is a case for ADMIN_IDENTIFY.  But there is nothing ordinary being called that tips me into the driver handling supplying data for an NVMIdentify.  I see it happening in the initialization module, in NVMeInitCallback(), which is eventually called by NVMeRunning().

The reason I ask this is I may want to do something similar to the NVMe GET LOG PAGE command, return a set value every single time for a debugging case.

The INT side will be in NVMeInitCallback() which decodes the command being completed within the routine (it's a shared completion routine for all init commands).  Look at case NVMeWaitOnIdentifyCtrl: and you will see where Chatham2 jumps in and hardcodes the response data via HardCodeChatham2Data().  We don't do any log page commands as part of init so you will have to slip it into one of the existing states (like where we do all the set/get features) or make a new state.  If its debug code that you aren't going to contribute then you can whatever you like, if you think there is value in adding plumbing for log pages at init then please add a whole new state handler.  Give me a buzz if you want a quick tutorial on how to do that.

If on the submissions side, look at NVMeRunningWaitOnIdentifyCtrl() and you'll see where I hardcode all of the ID data right there in line and then at the very end there I setup the next state to call and call it via the arbiter function.

-Paul





Thanks,
Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20120610/3a2ec425/attachment.html>