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


On Mon, Jun 6, 2016 at 3:49 AM, Alex Ionescu <ionucu@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.faber@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.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?


_______________________________________________
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