[ros-dev] [ros-diffs] [apriyadarshi] 71530: Added INF File for driver installation with minimal configuration. Device Detection and Initialization working -- tested on VMware. StorPortAllocatePool not working, so asked ...

[Aman Priyadarshi]

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 <ionucu at 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 at 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 at reactos.org>
>> > wrote:
>> >
>> >> On 2016-06-05 14:40, apriyadarshi at 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 at reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.reactos.org/pipermail/ros-dev/attachments/20160606/a2b24eb1/attachment-0001.html>