Peter
Fri Jun 25 12:18:39 CDT 2004
Yes, your driver can attach to the volume manager and to the volume device
objects. However you will need to send storage specific I/O controls to the
volume to detemine what partitions it is comprised of since there is no
parent-child relationship there.
Is there a class of USB device which you believe will function without
having device drivers installed on it?
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"shahar" <shahar@discussions.microsoft.com> wrote in message
news:A9EFFBAE-AB78-4642-AE9A-58EC4269FA0C@microsoft.com...
> my driver is useless without this information so i must accept this trade
> off, i guess this means a lot of testing for me...
run the driver verifier when you test - it will help point out when you've
handled a PNP operation incorrectly.
>
> i didn't understand your comment about volume device objects,
> when the disk receives a IRP_MN_QUERY_DEVICE_RELATIONS it fills in the
> volume's PDO, so if my device is a filter for the disk it can also be a
> filter for the volume.
> where does the volume manager comes into this picture ?
the disk driver enumerates PDOs for each partition. These are hidden from
PNP by the partmgr driver (removed from the enumeration list) and a message
is sent to the volume management device object, which is a root enumerated
device object. The volume management driver can then create volumes when it
decides that enough portions of the volume are avaialble.
> my driver needs to respond immediatley when a new device is plugged into a
> usb hub,
> this means i cannot wait for a user mode program to make the decision...
Of course a new device plugged into a USB hub isn't functional until PNP has
located a device driver to install on it. If you're trying to inject your
driver into every USB device's stack or you're trying to block certain USB
devices from being attached then you might see whether you can build a
co-installer that will run when any device is configured by PNP.
> just out of interest - what fuctions in the setup api orconfiguration
> manager routines can serve my purpose ?
well CM_Get_Parent comes to mind. They're documented in the DDK (in the
Device Installation section of the documentation)
>
> and another thing - can't i use the bus type and bus number returned by
> IoGetDeviceProperty to get a pointer to the parent device object ?
How would you use this information to open the parent device? Offhand i
can't think of any API that lets you turn those values into a device-object
name.
-p
>
> "Peter Wieland [MSFT]" wrote:
>
>> that would let you climb through the PNP tree although it's incredibly
>> easy
>> to do a bus-filter wrong so the chances of your driver crashing the
>> system
>> due to a bug are high. Is that an acceptable trade off for the
>> information?
>>
>> Note that this won't help you determine what a volume is attached to,
>> since
>> volume device objects are children of the volume manager and are not
>> attached to the disk stack. There are other situations in the system
>> where
>> devices talk to other devices that aren't their parents, and filtering
>> won't
>> help you at all there either.
>>
>> you could determine some of this information in user-mode too using setup
>> api or configuration manager routines. perhaps you could make whatever
>> decision this information is driving when your device is installed and
>> store
>> that in the registry rather than putting the code into the device driver.
>>
>> -p
>>
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> "shahar" <shahar@discussions.microsoft.com> wrote in message
>> news:DB4787DD-2CDC-43F0-A96F-1551E18AD7A6@microsoft.com...
>> > But I'm not sending an IRP_MJ_DEVICE_CONTROL request,
>> > I'm sending an IRP_MN_QUERY_INTERFACE request.
>> > according to the ducumentation in MSDN:
>> > "If the interface is not one the driver supports, the driver must pass
>> > the
>> > IRP to the next lower driver in the device stack without blocking"
>> > So I don't have a problem, right ?
>> > Can you suggest a better way to distinguish between the devices ?
>> >
>> > "Peter Wieland [MSFT]" wrote:
>> >
>> >> that will only work if the function driver sends unrecognized I/O
>> >> controls
>> >> to the lower devices, which is not guaranteed.
>> >>
>> >> -p
>> >>
>> >> --
>> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> rights.
>> >> "shahar" <shahar@discussions.microsoft.com> wrote in message
>> >> news:1D539EDF-5B28-49C7-801A-27B169B97376@microsoft.com...
>> >> > The only way I can think about detecting if a device is connected by
>> >> > USB
>> >> > is to build a bus filter that attaches to every new PDO it sees when
>> >> > IRP_MN_QUERY_DEVICE_RELATIONS returns.
>> >> > This way it will be able to see all the IRP's for all the device
>> >> > tree
>> >> > under the USB,
>> >> > and by querying a device stack for a device interface that is
>> >> > implemented
>> >> > by my driver I can detect if the device is connected to the USB.
>> >> > this is realy realy ugly, can you think of a better way ?
>> >> >
>> >> >
>> >> > "Doron Holan [MS]" wrote:
>> >> >
>> >> >> The more generic answer outside of storage, is that given a PDO,
>> >> >> there
>> >> >> is
>> >> >> no
>> >> >> way to find it's parent FDO in a standardized manner.
>> >> >>
>> >> >> d
>> >> >>
>> >> >> --
>> >> >> Please do not send e-mail directly to this alias. this alias is for
>> >> >> newsgroup purposes only.
>> >> >> This posting is provided "AS IS" with no warranties, and confers no
>> >> >> rights.
>> >> >>
>> >> >>
>> >> >> "Peter Wieland [MSFT]" <peterwie@online.microsoft.com> wrote in
>> >> >> message
>> >> >> news:%23pg0oNfWEHA.3972@TK2MSFTNGP12.phx.gbl...
>> >> >> > Have you tried using IOCTL_STORAGE_QUERY_PROPERTY to get the
>> >> >> > device
>> >> >> > descriptor for the disk you're talking to? It contains a field
>> >> >> > that
>> >> >> > could
>> >> >> > tell you the underlying bus type (assuming the drivers running
>> >> >> > the
>> >> >> > device
>> >> >> > set it)
>> >> >> >
>> >> >> > why only support USB? Why not smart-cards? Why not SD media?
>> >> >> >
>> >> >> > -p
>> >> >> >
>> >> >> > --
>> >> >> > This posting is provided "AS IS" with no warranties, and confers
>> >> >> > no
>> >> >> rights.
>> >> >> > "shahar" <shahar@discussions.microsoft.com> wrote in message
>> >> >> > news:E2AA1E9D-3F74-4CD6-A0CF-183A299AB329@microsoft.com...
>> >> >> > >I need to distinguish a USB disk from a IDE disk from a SCSI
>> >> >> > >disk.
>> >> >> > >
>> >> >> > > "Peter Wieland [MSFT]" wrote:
>> >> >> > >
>> >> >> > >> why does it matter how it's connected? Either you've
>> >> >> > >> identified
>> >> >> > >> your
>> >> >> > >> disk-on-key device by its inquiry data, or you have no idea
>> >> >> > >> what
>> >> >> > >> the
>> >> >> > >> device
>> >> >> > >> is. Were you going to add code that distingushed a USB
>> >> >> > >> hard-disk
>> >> >> > >> from
>> >> >> a
>> >> >> > >> smart-card from an SD card from a disk-on-key?
>> >> >> > >>
>> >> >> > >> If you're trying to just work with your device there are
>> >> >> > >> plenty
>> >> >> > >> of
>> >> >> > >> ways
>> >> >> > >> to
>> >> >> > >> do it that will work better than trying to walk through the
>> >> >> > >> chain
>> >> >> > >> of
>> >> >> > >> connected devices to see if one happens to be a USB hub.
>> >> >> > >>
>> >> >> > >> if you have a different goal you'll probably get better advice
>> >> >> > >> if
>> >> >> > >> you
>> >> >> > >> tell
>> >> >> > >> us what the goal is, rather than asking how you implement a
>> >> >> > >> single
>> >> >> > >> solution.
>> >> >> > >>
>> >> >> > >> -p
>> >> >> > >>
>> >> >> > >> --
>> >> >> > >> This posting is provided "AS IS" with no warranties, and
>> >> >> > >> confers
>> >> >> > >> no
>> >> >> > >> rights.
>> >> >> > >> "shahar" <shahar@discussions.microsoft.com> wrote in message
>> >> >> > >> news:12DB0C3E-7994-4F4C-BE4A-E025C0625588@microsoft.com...
>> >> >> > >> > But when for example I plug my disk-on-key to the USB hub,
>> >> >> > >> > three devices are created:
>> >> >> > >> > 1) A mass storage device with enumerator name USB
>> >> >> > >> > 2) A disk drive device with enumerator name USBSTOR
>> >> >> > >> > 3) A storage volume device with enumerator name STORAGE
>> >> >> > >> > let's say my driver has a pointer to the storage volume's
>> >> >> > >> > PDO,
>> >> >> > >> > how can I know that this storage volume device is connected
>> >> >> > >> > to
>> >> >> > >> > a
>> >> >> > >> > USB
>> >> >> > >> > hub
>> >> >> > >> > and not to the IDE for example ?
>> >> >> > >> > the enumerator name can't help me in this case.
>> >> >> > >> > knowing that the enumerator name is STORAGE says nothing
>> >> >> > >> > about
>> >> >> > >> > the
>> >> >> > >> > parent
>> >> >> > >> > of the device...
>> >> >> > >> > Is there a way to get a pointer to PDO of the creator of
>> >> >> > >> > some
>> >> >> > >> > other
>> >> >> PDO
>> >> >> > >> > ?
>> >> >> > >> >
>> >> >> > >> > "Doron Holan [MS]" wrote:
>> >> >> > >> >
>> >> >> > >> >> you should never *ever* *ever* (did i say ever? i mean
>> >> >> > >> >> it!)
>> >> >> > >> >> send
>> >> >> > >> >> a
>> >> >> > >> >> query
>> >> >> > >> >> device relations / BusRelations to the driver in question.
>> >> >> > >> >> this
>> >> >> > >> >> irp
>> >> >> > >> >> is
>> >> >> > >> >> strictly for the pnp subsystem to send.
>> >> >> > >> >>
>> >> >> > >> >> why?
>> >> >> > >> >>
>> >> >> > >> >> because if there is a state change based on the relations
>> >> >> > >> >> reported
>> >> >> (a
>> >> >> > >> >> new
>> >> >> > >> >> PDO or the removal of one), you cannot enact that change.
>> >> >> > >> >> You
>> >> >> > >> >> cannot
>> >> >> > >> >> create
>> >> >> > >> >> a new stack nor invoke a surprise removal on the removed
>> >> >> > >> >> PDO.
>> >> >> > >> >> State
>> >> >> > >> >> get's
>> >> >> > >> >> lost, the driver who reported the change in its relations
>> >> >> > >> >> gets
>> >> >> > >> >> put
>> >> >> > >> >> into a
>> >> >> > >> >> weird state and things go south really quickly.
>> >> >> > >> >>
>> >> >> > >> >> what you want is to ask the DO in question who its
>> >> >> > >> >> enumerator
>> >> >> > >> >> is,
>> >> >> > >> >> IoGetDeviceProperty(..., DevicePropertyEnumeratorName, ..)
>> >> >> > >> >> will
>> >> >> return
>> >> >> > >> >> a
>> >> >> > >> >> strig of the enumerator. So for a usb device it would be
>> >> >> > >> >> L"USB",
>> >> >> for
>> >> >> > >> >> a
>> >> >> > >> >> parallel device probably L"LPT".
>> >> >> > >> >>
>> >> >> > >> >> d
>> >> >> > >> >>
>> >> >> > >> >> --
>> >> >> > >> >> Please do not send e-mail directly to this alias. this
>> >> >> > >> >> alias
>> >> >> > >> >> is
>> >> >> > >> >> for
>> >> >> > >> >> newsgroup purposes only.
>> >> >> > >> >> This posting is provided "AS IS" with no warranties, and
>> >> >> > >> >> confers
>> >> >> > >> >> no
>> >> >> > >> >> rights.
>> >> >> > >> >>
>> >> >> > >> >>
>> >> >> > >> >> "shahar" <shahar@discussions.microsoft.com> wrote in
>> >> >> > >> >> message
>> >> >> > >> >> news:4B8B0986-1DA0-4CFB-9AFB-B9DF98046642@microsoft.com...
>> >> >> > >> >> > When I want to know who are the children of a device I
>> >> >> > >> >> > can
>> >> >> > >> >> > send
>> >> >> > >> >> > an
>> >> >> > >> >> IRP_MN_QUERY_DEVICE_RELATIONS request to it with "type =
>> >> >> > >> >> BusRelations",
>> >> >> > >> >> but
>> >> >> > >> >> how to I make the reversed operation ?
>> >> >> > >> >> > Let's say I have a printer DO, how can I know if it is
>> >> >> > >> >> > connected
>> >> >> to
>> >> >> > >> >> > a
>> >> >> > >> >> parallel port or to a USB hub ?
>> >> >> > >> >>
>> >> >> > >> >>
>> >> >> > >> >>
>> >> >> > >>
>> >> >> > >>
>> >> >> > >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>