Re: [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 ...

[Alex Ionescu]

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(a)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 &lt;thomas.faber(a)reactos.org&gt;
> >  wrote:
> >
> > > On 2016-06-05 14:40, apriyadarshi(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[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 &lt;ionucu(a)videotron.ca&gt; 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 &lt;thomas.faber(a)reactos.org&gt;
>  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 &lt;thomas.faber(a)reactos.org&gt;
> > >  wrote:
> > >
> > > > On 2016-06-05 14:40, apriyadarshi(a)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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>