Re: Getting from device path to driver letter for firewire media changer

I'm not sure how that answers the questions I had though. I need a
persistent reference to a changer that can be converted to a driver letter.
Without such a thing, there's no way that any software can be assigned to a
particular changer in a persistent way, but then also be able to derive from
that persistent identifier the dynamically assigned drive letter required to
open the changer and interact with it via IOCTL.

--------------------
Dean Roddey
Chairman/CTO, Charmed Quark Systems, Ltd
www.charmedquark.com
"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
news:umsVx37tHHA.4972@xxxxxxxxxxxxxxxxxxxxxxx
If you receive WM_DEVICECHANGE device message you can check letters with
QueryDosDevice()
Arkady

"Dean Roddey" <droddey@xxxxxxxxxxxxxxxx> wrote in message
news:u3d4WZhtHHA.4952@xxxxxxxxxxxxxxxxxxxxxxx
Oh product is an automation system (Windows based of course), and among
the various things it does is media management. We are trying to add a
driver (our level driver, not a system level driver) for the new Firewire
based changes, to supplement our existing serially controlled changer
drivers.

What I'm a little confused about is how to come up with a persistent
reference to the changer. Being an automation system, the user loads one
of our drivers for each device and then forgets about it. We talk to the
device and expose control over it via a generic interface. But that means
we have to be able to get back to that device reliably. Usualy it's a
serial port or IP address or something of that nature.

We need a driver letter, since that's what we have to open up in order to
do the IOCTL calls required to control the changer, but these driver
letters are mapped dynamically by the system and could easily change
during system hardware changes (turn it off, unplug some external
drives,turn it back on, plug them in a different order or a new fixed
drive was installed, etc...) This wouldn't be good.

We can obviously enumerate the devices via the SetupDi methods, but that
doesn't help really. For one thing, we can't map it back to a drive
letter so it doesn't do us any good even if it is a persistent id to the
changer. And secondly, the user wouldn't know the SetupDi-provided device
paths from a hole in the ground, so they would have no way to reliably
point a driver at a particular one.

There seem to be some tricks for mapping the device path to a drive
letter, but I can't get them to work. They involve the use of the
IOCTL_STORAGE_GET_DEVICE_NUMBER to get the device number, and then an
iteration of the drives to get the same and looking for a match. But I
can't get the firewire changer opened using the SetupDi returned device
path. I always get ERROR_BUSY. I've tried all possible combinations of
minimal access rights, so I don't think that's the problem. I can open it
easily enough using the \\.\X: type path, but if course that doesn't help
me at all for the reasons above. There's nothing using the drive at all.

What I'd like to do is figure out all the device paths and their
corresponding drive paths. Present the drive paths to the user to select
from, but store the device path along with the drive path in our driver
config, so that it can be used to actually get to the drive again later,
which could change without bothering us.

So anyway, if anyone has any thoughts on this, I'd really appreciate a
second opinion. I'm just about ready to chuck the whole thing honestly,
since it's taking up time that could be spent on things that are actually
well documented and less obscure, and equally desirable. But I'd like to
get this working if possible.

---------------------
Dean Roddey
Chairman/CTO, Charmed Quark Systems, Ltd
www.charmedquark.com





.

Relevant Pages

  • [patch] add scsi changer driver
    ... This patch adds a device driver for scsi media changer devices (tape ... +static int timeout_move = 300; ...
    (Linux-Kernel)
  • Getting from device path to driver letter for firewire media changer
    ... We are trying to add a driver ... to supplement our existing serially controlled changer drivers. ... There seem to be some tricks for mapping the device path to a drive letter, ... iteration of the drives to get the same and looking for a match. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Getting from device path to driver letter for firewire media changer
    ... driver for the new Firewire ... reference to the changer. ... iteration of the drives to get the same and looking for a match. ... can't get the firewire changer opened using the SetupDi returned device ...
    (microsoft.public.win32.programmer.kernel)
  • Re: library / changer driver
    ... >> Sorry, just curious, how could you develop a driver ... > user mode components such as RSM, much less applications layered above ... > RSM such as ntbackup. ... > will get wide code coverage and stress testing of changer drivers. ...
    (microsoft.public.development.device.drivers)
  • [2.6 patch] remove the documentation for the legacy CDROM drivers
    ... This patch removes the documentation for the removed legacy CDROM drivers. ... SC1200 WDT DRIVER ... LaTeX document on standardizing the CD-ROM programming interface. ... THIS DRIVER WILL WORK WITH THE CD-ROM DRIVES LISTED, ...
    (Linux-Kernel)