I'm not an expert so I'm not sure what way is best. But I see at least 4 solutions: * There seems to be a way to get the extended function table through StorPortNotification/GetExtendedFunctionTable. This would provide some of the newer functionality even with older storport, but is potentially an undocumented hack * Avoid using the modern functionality and implement an old-storport compatible storahci, which implies using only memory from the adapter extension, and probably a few more things * Rely on a "modern" storport and do the testing in a newer Windows version. Then when ROS gets storport it simply needs to be a "modern" version * Do not use storport and implement msahci rather than storahci
Option 2 would give the greatest compatibility but I can't pretend to understand what limitations it will imply.
On 2016-06-05 21:43, Aman Priyadarshi wrote:
Yeah msahci is ataport miniport driver. Then what would be the best idea? Leave it with the implementation I made there. "Allocated memory for all port extension within device extension?" ᐧ
Regards *Aman Priyadarshi* *www.atomixos.com http://www.atomixos.com*
On Mon, Jun 6, 2016 at 1:02 AM, Thomas Faber thomas.faber@reactos.org wrote:
On 2016-06-05 14:40, apriyadarshi@svn.reactos.org wrote:
Author: apriyadarshi Date: Sun Jun 5 12:40:49 2016 New Revision: 71530
URL: http://svn.reactos.org/svn/reactos?rev=71530&view=rev Log: Added INF File for driver installation with minimal configuration. Device Detection and Initialization working -- tested on VMware. StorPortAllocatePool not working, so asked Storport to allocate all
memory just after loading up the driver -- Bad idea (will change it later).
StorPortAllocatePool uses StorPortExtendedFunction, which indeed is not implemented in Win2003. As you can see in WDK samples, 2003's msahci is not a storport miniport driver. Maybe storport wasn't advanced enough for complex drivers back then?