Prev: RE" Assembly code in driver source with x64 build not working
Next: Setting/Changing the device name in Device Manager
From: Doron Holan [MSFT] on 21 Apr 2010 17:27
> I do not like device interfaces - correct me if I'm wrong - because
> they require a nonstandard API in the user side.

what is non standard about using SetupAPI to enumerate the device interface?

--

This posting is provided "AS IS" with no warranties, and confers no rights.


"alberto" <amoreira(a)ieee.org> wrote in message
news:01938386-bc6e-4d7a-ba45-6c8112d1f817(a)x38g2000vbx.googlegroups.com...
>
> I don't know if I quite understand your need, but maybe you can
> preallocate your own array of device structure areas in the nonpaged
> pool, have an atomic counter that increments for every device you
> create, and store a pointer to its Device Object in the corresponding
> slot. When the Open request comes your driver gets control anyway, and
> from there you can quickly figure out which device you're talking
> about.
>
> In other words, devices are primarily identified by your own
> structure, not by the Device Object - you just use the Device Object
> to keep Windows quiet. Instead of embedding your device-unique storage
> in the Device Object as a device extension, you just maintain your
> own array of device structures, and do not include a device extension
> in your device object.
>
> I use a variation of this technique in my driver, and I have
> successfully run production volume through up to 6-board
> configurations.
>
> I do not like device interfaces - correct me if I'm wrong - because
> they require a nonstandard API in the user side.
>
>
> Hope this helps,
>
>
> Alberto.
>
>
>
>
> On Apr 19, 8:35 pm, Mark McDougall <ma...(a)vl.com.au> wrote:
>> Maxim S. Shatskih wrote:
>> > Use the global counter and ++ it on each creation.
>>
>> I have subsequently discovered that this is how the serial driver does
>> it.
>> In this case, IIUC there's no guaranteed correlation between the first
>> PDO
>> enumerated and the first AddDevice() call - ie. a PDO enumerated as
>> MyPdo2
>> could conceivably get its AddDevice() called first, and the
>> Assigned/Symbolic name could be "MyDev0" - right?
>>
>> FTR I think I can live with this anyway, since I can store the port
>> number
>> (global counter) in the FDO device extension in AddDevice() and then
>> assign the physical resources in EvtPrepareHw() based on this port
>> number.
>>
>> > But it is much better to use device interfaces instead.
>>
>> Ugghh!! No thanks. These are actually custom communications ports and
>> they
>> will never need to do detection. It's a closed system and each port has a
>> predetermined connection to the outside world.
>>
>> Regards,
>>
>> --
>> Mark McDougall, Engineer
>> Virtual Logic Pty Ltd, <http://www.vl.com.au>
>> 21-25 King St, Rockdale, 2216
>> Ph: +612-9599-3255 Fax: +612-9599-3266
>
From: Pavel A. on 21 Apr 2010 17:54
"Doron Holan [MSFT]" <doron.holan(a)online.microsoft.com> wrote in message
news:ufuG7lZ4KHA.5880(a)TK2MSFTNGP04.phx.gbl...
>> I do not like device interfaces - correct me if I'm wrong - because
>> they require a nonstandard API in the user side.
>
> what is non standard about using SetupAPI to enumerate the device
> interface?

No such thing in posix :-)

-- pa

> "alberto" <amoreira(a)ieee.org> wrote in message
> news:01938386-bc6e-4d7a-ba45-6c8112d1f817(a)x38g2000vbx.googlegroups.com...
>>
>> I don't know if I quite understand your need, but maybe you can
>> preallocate your own array of device structure areas in the nonpaged
>> pool, have an atomic counter that increments for every device you
>> create, and store a pointer to its Device Object in the corresponding
>> slot. When the Open request comes your driver gets control anyway, and
>> from there you can quickly figure out which device you're talking
>> about.
>>
>> In other words, devices are primarily identified by your own
>> structure, not by the Device Object - you just use the Device Object
>> to keep Windows quiet. Instead of embedding your device-unique storage
>> in the Device Object as a device extension, you just maintain your
>> own array of device structures, and do not include a device extension
>> in your device object.
>>
>> I use a variation of this technique in my driver, and I have
>> successfully run production volume through up to 6-board
>> configurations.
>>
>> I do not like device interfaces - correct me if I'm wrong - because
>> they require a nonstandard API in the user side.
>>
>>
>> Hope this helps,
>>
>>
>> Alberto.
>>
>>
>>
>>
>> On Apr 19, 8:35 pm, Mark McDougall <ma...(a)vl.com.au> wrote:
>>> Maxim S. Shatskih wrote:
>>> > Use the global counter and ++ it on each creation.
>>>
>>> I have subsequently discovered that this is how the serial driver does
>>> it.
>>> In this case, IIUC there's no guaranteed correlation between the first
>>> PDO
>>> enumerated and the first AddDevice() call - ie. a PDO enumerated as
>>> MyPdo2
>>> could conceivably get its AddDevice() called first, and the
>>> Assigned/Symbolic name could be "MyDev0" - right?
>>>
>>> FTR I think I can live with this anyway, since I can store the port
>>> number
>>> (global counter) in the FDO device extension in AddDevice() and then
>>> assign the physical resources in EvtPrepareHw() based on this port
>>> number.
>>>
>>> > But it is much better to use device interfaces instead.
>>>
>>> Ugghh!! No thanks. These are actually custom communications ports and
>>> they
>>> will never need to do detection. It's a closed system and each port has
>>> a
>>> predetermined connection to the outside world.
>>>
>>> Regards,
>>>
>>> --
>>> Mark McDougall, Engineer
>>> Virtual Logic Pty Ltd, <http://www.vl.com.au>
>>> 21-25 King St, Rockdale, 2216
>>> Ph: +612-9599-3255 Fax: +612-9599-3266
>>
From: Maxim S. Shatskih on 22 Apr 2010 08:42
> No such thing in posix :-)

POSIX is non-standard, it violates the Microsoft's tradition :-)

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

From: alberto on 22 Apr 2010 12:49

The problem is, the SetupAPI is Windows-unique. Doesn't exist in
Linux, Solaris, or MacOS. Forces me to write the application or test
program more than once, meaning, I have to spend additional time and
money to satisfy the vagaries of the OS.

And, believe me, I like ifstream/ofstream way better!


Alberto.



On Apr 21, 5:27 pm, "Doron Holan [MSFT]"
<doron.ho...(a)online.microsoft.com> wrote:
> > I do not like device interfaces - correct me if I'm wrong - because
> > they require a nonstandard API in the user side.
>
> what is non standard about using SetupAPI to enumerate the device interface?
>
> --
>
> This posting is provided "AS IS" with no warranties, and confers no rights
>
From: Maxim S. Shatskih on 22 Apr 2010 15:37
>And, believe me, I like ifstream/ofstream way better!

For me, the use of << or >> for file reads and writes is schizoid, but well, this is a matter of taste.

I never use these libraries, only printf and fprintf and StringCb/CchPrintf

POSIX API is OK, so is Win32.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: RE" Assembly code in driver source with x64 build not working
Next: Setting/Changing the device name in Device Manager