Prev: RE" Assembly code in driver source with x64 build not working
Next: Setting/Changing the device name in Device Manager
From: Tim Roberts on 20 Apr 2010 02:41
Mark McDougall <markm(a)vl.com.au> wrote:
>
>> 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.

Your response indicates that you do not know what device interfaces are.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Jonathan de Boyne Pollard on 20 Apr 2010 07:12
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote cite="mid:%230GT%23683KHA.1624(a)TK2MSFTNGP06.phx.gbl"
type="cite">
<p wrap="">Or is there a better way?<br>
</p>
</blockquote>
<p>Yes.&nbsp; Device interfaces.&nbsp; You register the interface for each
device, and there's <em>already</em> a library of <code>SetupDiXXX()</code>
functions that allow application-mode code to enumerate all devices
exporting that interface.&nbsp; All that your application-mode code needs to
know is the GUID used by your kernel-mode code to register the
interface for each device.&nbsp; Device interface names are stable across
reboots (as long as the hardware doesn't physically move around, of
course); don't require bodges in your driver such as incrementing
global counters to generate names and handling name collisions; don't
require special knowledge in application-mode code of idiosyncratic
naming schemes used by kernel-mode code; and incorporate bus addresses
in <a
href="http://msdn.microsoft.com/en-us/library/ff547656%28VS.85%29.aspx">instance
IDs</a>, retrievable in application-mode code via <code><a
href="http://msdn.microsoft.com/en-us/library/ff551106%28VS.85%29.aspx">SetupDiGetDeviceInstanceID()</a></code>.&nbsp;
Don't reinvent this wheel.</p>
</body>
</html>
From: Jonathan de Boyne Pollard on 20 Apr 2010 07:17
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<blockquote
cite="mid:FBD08674-6453-40F3-80EC-204918E9D0B8(a)microsoft.com"
type="cite">
<blockquote type="cite">
<p>But it is much better to use device interfaces instead.
</p>
</blockquote>
<p>Maybe, combination of both: Device interface to detect all the
devices, then query some property
(stored in the registry, or call the driver) to get the numbers
assigned to devices.
</p>
</blockquote>
<p>There's no need for the global counter for the latter.&nbsp; M.
MacDougall wants to be able to find the specific bus address of the
device.&nbsp; <a
href="http://msdn.microsoft.com/en-us/library/ff547656%28VS.85%29.aspx">Instance
IDs</a> already incorporate that, and they are retrievable by
application-mode code via <code><a
href="http://msdn.microsoft.com/en-us/library/ff551106%28VS.85%29.aspx">SetupDiGetDeviceInstanceID()</a></code>.&nbsp;
Since it's xyr own bus driver, xe has full control over the instance
IDs in the first place, too.<br>
</p>
</body>
</html>
From: Maxim S. Shatskih on 20 Apr 2010 20:04
> In this case, IIUC there's no guaranteed correlation between the first PDO
> enumerated

Enumeration order of the PDOs is not defined at all.

> 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.

Correct.

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

From: alberto on 21 Apr 2010 14:06

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

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