Yeah, I investigate storport.h we can get extended function table by calling
PSTORPORT_EXTENDED_FUNCTIONS pExtFuncTable = NULL; StorPortNotification(GetExtendedFunctionTable, DeviceExtension, &pExtFuncTable); we can thereafter check if pExtFuncTable->AllocatePool is NULL or not? if It is NULL, we can apply our own implementation of StorPortAllocatePool? Sounds good? ᐧ Regards *Aman Priyadarshi* *www.atomixos.com <http://www.atomixos.com>* On Mon, Jun 6, 2016 at 3:49 AM, Alex Ionescu <ion...@videotron.ca> wrote: > Hi, > > Implementing MSAHCI would be "more correct" for the system, however MSAHCI > also doesn't use STORPORT, it uses ATAPORT, which requires changing our > PCIIDEX model to support that. Which I think would put Aman's work out of > scope. > > Now, MSAHCI would be ported to use STORPORT instead, but then we'd > essentially be implementing a legacy component on top of a legacy port > driver. > > At least, by implementing STORAHCI on top of STORPORT, we can implement a > 'modern' component on top of the legacy port driver. > > And for this, I would either recommend doing things like implementing > StorPortExtendedFunction > if Aman can do it -- or if someone can help him, or, avoiding its use with > temporary work/arounds, etc. _as long as those workarounds still work in > Windows_. > > Best regards, > Alex Ionescu > > On Sun, Jun 5, 2016 at 9:10 PM, Thomas Faber <thomas.fa...@reactos.org> > wrote: > >> 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.fa...@reactos.org> >> > wrote: >> > >> >> On 2016-06-05 14:40, apriyadar...@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? >> >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > > > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
