Hi all,
Storport physical miniport seem not to support any WDM libraries and porting WDM to Stoport physical miniport is really frustating.
Actually i wanted to upgrade firmware during device start (HwFindAdapter) by reading the bits present in some external file into the device. ZwXXXFile apis is NOT supported. How do i do this ?. Also device characteristic are set by reading the registry entries and i see no way since Registry read/modify/write API’s arent present.
Any workaround for this ?
Thanks
Storport does have registry read and write routines see
StorPortRegistryRead and StorPortRegistryWrite. There is no file I/O
supported, would your firmware fit in a REG_BINARY value?
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> Hi all,
>
>
> Storport physical miniport seem not to support any WDM libraries and porting WDM to Stoport physical miniport is really frustating.
>
> Actually i wanted to upgrade firmware during device start (HwFindAdapter) by reading the bits present in some external file into the device. ZwXXXFile apis is NOT supported. How do i do this ?. Also device characteristic are set by reading the registry entries and i see no way since Registry read/modify/write API’s arent present.
>
> Any workaround for this ?
>
>
>
> Thanks
Hi Burn,
yup StorPortRegistryRead does exist ! thanks !
The bit file is around 3.5 MB. Will it be OK to keep such huge file there.
I have never done this before. but the idea sounds cool 
I will surely try this.
Thanks for ur reply !
On 10/13/2010 9:26 AM, xxxxx@gmail.com wrote:
Hi Burn,
yup StorPortRegistryRead does exist ! thanks !
The bit file is around 3.5 MB. Will it be OK to keep such huge file there.
I have never done this before. but the idea sounds cool
I will surely try this.
Thanks for ur reply !
You’ll probably need to break it into multiple chunks, as there are (or
were, it’s been 10 years since I did something similar) size limitations
on a single value, and possibly keys, but sequentially reading them and
combining them in memory worked for me.
Phil
/Philip D. Barila (303) 776-1264
http:</http:>/
You cannot fit that large a binary in the registry. You are going to
have to figure a different way to get the firmware into the driver,
could you do it with a set of WMI commands (take a look at
HwStorWmiExecuteMethod).
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> Hi Burn,
>
> yup StorPortRegistryRead does exist ! thanks !
>
> The bit file is around 3.5 MB. Will it be OK to keep such huge file there.
> I have never done this before. but the idea sounds cool
>
> I will surely try this.
>
> Thanks for ur reply !
On Wed, Oct 13, 2010 at 11:05 AM, wrote:
> porting WDM to Stoport physical miniport is really frustating.
>
>
Unlike NDIS storport continues to allow miniports to link outside the
box of apis they think you should use. The trick is to put all your
WDM stuff into a separate compilation unit (its own .c or .cpp file)
and include the usual WDM headers in that file only. Then provide
wrapper functions for the stuff you need.
Of course in your specific case you just needed to read the manual
Mark Roddy
> Storport physical miniport seem not to support any WDM libraries and porting WDM to Stoport
physical miniport is really frustating.
Write virtual miniport and do your own locking.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>Unlike NDIS storport continues to allow miniports to link outside the box of apis they think you >should use. The trick is to put all your WDM stuff into a separate compilation unit (its own .c or >.cpp file) and include the usual WDM headers in that file only. Then provide wrapper functions for >the stuff you need.
Could this solution pass Windows Logo test?
Igor Sharovar
xxxxx@hotmail.com wrote:
> Unlike NDIS storport continues to allow miniports to link outside the box of apis they think you should use. The trick is to put all your WDM stuff into a separate compilation unit (its own .c or .cpp file) and include the usual WDM headers in that file only. Then provide wrapper functions for the stuff you need.
Could this solution pass Windows Logo test?
WHQL never sees your source code. They don’t care how it’s built. If
they don’t check the imports (and that’s what this says), then there’s
no issue.
That trick was commonly used in display driver miniports as well.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The current tests don’t care.
Obviously that could change, as it did for NDIS.
Mark Roddy
On Thu, Oct 14, 2010 at 3:20 PM, wrote:
>>Unlike NDIS storport continues to allow miniports to link outside the box of apis they think you >should use. The trick is to put all your WDM stuff into a separate compilation unit (its own .c or >.cpp file) and include the usual WDM headers in that file only. Then provide wrapper functions for >the stuff you need.
>
> Could this solution pass Windows Logo test?
>
> Igor Sharovar
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
>> Unlike NDIS storport continues to allow miniports to link outside the box of apis they think you should use. The trick is to put all your WDM stuff into a separate compilation unit (its own .c or .cpp file) and include the usual WDM headers in that file only. Then provide wrapper functions for the stuff you need.
wrapper trick worked
so far so good !
There is a storage Logo test called “Storage Imports Test”. This validates that a miniport is using the correct port model for its architecture. It also has the capability to check for unknown/illegal imports - using the /strict option.
This test was a “preview” until Dec 2009 when it expired. My question is, does WLK run the storimports.exe test using the “/strict” option? Also can someone verify that this is indeed a required test for Logo?
If the answer to both is yes, then using a separate link library to gain access to kernel functions is not an option.
We performed some experiments with WLK 1.5 and found the answers we were looking for. The Storage Logo test suite uses a program called storimports.exe to perform the “Storage Imports Test”. We found that when WLK 1.5 runs this test it does not specify the “/strict” option, therefore imports outside of the storport wrapper are flagged only as warnings, not errors.