Hardware ids and device ids...

I’m a little confused about how to properly setup HardwareIDs for
devices enumerated by my bus driver.

During enumeration, I receive two pieces of information per device. An
ANSI string and an integer that uniquely represent the device(s) on the
other side of the bridge. Since these are virtual devices, I can
manipulate the string in any fashion.

After reading through
http://msdn.microsoft.com/en-us/library/dd567990.aspx and the associated
pages, I’m still confused on how to format the string for Windows.

Should I add a SUBSYS_ field to the bus driver’s HardwareId? Or should
I use the “root<string>” of the ‘generic’ id format? Or something else
entirely?

At the moment, the bus driver installs properly however device manager
does tell me that a child hardware id is incorrectly formatted. Note
that I just passed the string as is.

(and yes, I do convert the ANSI string into its UNICODE counterpart
prior to passing it into the various api’s…)

Thank you,
-PWM

Peter W. Morreale wrote:

I’m a little confused about how to properly setup HardwareIDs for
devices enumerated by my bus driver.

During enumeration, I receive two pieces of information per device. An
ANSI string and an integer that uniquely represent the device(s) on the
other side of the bridge. Since these are virtual devices, I can
manipulate the string in any fashion.

After reading through
http://msdn.microsoft.com/en-us/library/dd567990.aspx and the associated
pages, I’m still confused on how to format the string for Windows.

Should I add a SUBSYS_ field to the bus driver’s HardwareId? Or should
I use the “root<string>” of the ‘generic’ id format? Or something else
> entirely?
>

If you are going to be supplying your own drivers for these devices, you
can make the strings be whatever you want. It is completely arbitrary.
You might invent your own bus (“PETER”), and make the devices
PETER\TYPE_1, PETER\TYPE_2, or PETER\NETWORK_1, or
PETER\000111222_PORT6. Whatever makes sense for you. The SOLE purpose
for those IDs is to give the PnP system something to search for in INF
files. That’s it. (OK, it’s also used to make registry keys.)

If you expect to use standard system drivers, then your IDs must follow
the standard for whatever bus you hope to emulate.

> At the moment, the bus driver installs properly however device manager
> does tell me that a child hardware id is incorrectly formatted. Note
> that I just passed the string as is.
>

What strings, exactly, did you pass?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

What is the current string you are passing? SUBSYS makes sense for pci ids, since this is a custom bus, it does not make sense, basically the ids you report are domain specific. Since they are domain specific, the id format is up to you (but you must follow the generic rule where the id is formatted as (enumerator)(id) )

d

-----Original Message-----
From: Peter W. Morreale
Sent: Thursday, December 03, 2009 5:15 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Hardware ids and device ids…

I’m a little confused about how to properly setup HardwareIDs for
devices enumerated by my bus driver.

During enumeration, I receive two pieces of information per device. An
ANSI string and an integer that uniquely represent the device(s) on the
other side of the bridge. Since these are virtual devices, I can
manipulate the string in any fashion.

After reading through
http://msdn.microsoft.com/en-us/library/dd567990.aspx and the associated
pages, I’m still confused on how to format the string for Windows.

Should I add a SUBSYS_ field to the bus driver’s HardwareId? Or should
I use the “root<string>” of the ‘generic’ id format? Or something else
entirely?

At the moment, the bus driver installs properly however device manager
does tell me that a child hardware id is incorrectly formatted. Note
that I just passed the string as is.

(and yes, I do convert the ANSI string into its UNICODE counterpart
prior to passing it into the various api’s…)

Thank you,
-PWM


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

On Fri, 2009-12-04 at 01:30 +0000, Doron Holan wrote:

What is the current string you are passing? SUBSYS makes sense for pci ids, since this is a custom bus, it does not make sense, basically the ids you report are domain specific. Since they are domain specific, the id format is up to you (but you must follow the generic rule where the id is formatted as (enumerator)(id) )

Well, for testing I was just enumerating several non-sensical names
like:

test_foo_10
test_foo_11

etc.

The key point I was missing was specifying the portion of
the id. I didn’t realize I could create that part of the domain.

Thanks
-PWM

> d
>
>
>
> -----Original Message-----
> From: Peter W. Morreale
> Sent: Thursday, December 03, 2009 5:15 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Hardware ids and device ids…
>
>
> I’m a little confused about how to properly setup HardwareIDs for
> devices enumerated by my bus driver.
>
> During enumeration, I receive two pieces of information per device. An
> ANSI string and an integer that uniquely represent the device(s) on the
> other side of the bridge. Since these are virtual devices, I can
> manipulate the string in any fashion.
>
> After reading through
> http://msdn.microsoft.com/en-us/library/dd567990.aspx and the associated
> pages, I’m still confused on how to format the string for Windows.
>
> Should I add a SUBSYS_ field to the bus driver’s HardwareId? Or should
> I use the “root<string>” of the ‘generic’ id format? Or something else
> entirely?
>
>
> At the moment, the bus driver installs properly however device manager
> does tell me that a child hardware id is incorrectly formatted. Note
> that I just passed the string as is.
>
> (and yes, I do convert the ANSI string into its UNICODE counterpart
> prior to passing it into the various api’s…)
>
> Thank you,
> -PWM
>
>
> —
> 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
>
>
> —
> 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

On Thu, 2009-12-03 at 17:22 -0800, Tim Roberts wrote:

Peter W. Morreale wrote:
> I’m a little confused about how to properly setup HardwareIDs for
> devices enumerated by my bus driver.
>
> During enumeration, I receive two pieces of information per device. An
> ANSI string and an integer that uniquely represent the device(s) on the
> other side of the bridge. Since these are virtual devices, I can
> manipulate the string in any fashion.
>
> After reading through
> http://msdn.microsoft.com/en-us/library/dd567990.aspx and the associated
> pages, I’m still confused on how to format the string for Windows.
>
> Should I add a SUBSYS_ field to the bus driver’s HardwareId? Or should
> I use the “root<string>” of the ‘generic’ id format? Or something else
> > entirely?
> >
>
> If you are going to be supplying your own drivers for these devices, you
> can make the strings be whatever you want. It is completely arbitrary.
> You might invent your own bus (“PETER”), and make the devices
> PETER\TYPE_1, PETER\TYPE_2, or PETER\NETWORK_1, or
> PETER\000111222_PORT6. Whatever makes sense for you. The SOLE purpose
> for those IDs is to give the PnP system something to search for in INF
> files. That’s it. (OK, it’s also used to make registry keys.)
>

Perfect. Understood.

> If you expect to use standard system drivers, then your IDs must follow
> the standard for whatever bus you hope to emulate.
>
> > At the moment, the bus driver installs properly however device manager
> > does tell me that a child hardware id is incorrectly formatted. Note
> > that I just passed the string as is.
> >
>
> What strings, exactly, did you pass?
>

Just some testing trash, the key thing I was missing was the enumerator
portion of the string. (See response to Doron’s post)

Thanks,

-PWM