Writing a 1394 interface driver

[Freddie Witherden]

Hello,

I am in the process of porting my FireWire library to Windows. It
currently runs on OS X and Linux -- so I have some experience with
FireWire devices and APIs.

As Windows does not provide a user-space API my plan is to use the
KMDF to expose the functionality I require from the stack via device
ioctls. I have looked over the KMDF portion of the 'vdev_hybrid'
sample in the WDK. The kernel interface seems fine.

However, if I understand it correctly: the associated application asks
the stack to create a 'virtual device'. Windows does not know how to
handle this, so asks for a device driver, the user supplies the
associated sys. Windows loads the driver and we all eat cake (which,
like the virtual device, is a lie :-).

My library needs access to *all* 1394 devices attached to the system.
That is to say that it is not associated with any one CSR unit
directory -- if it is a 1394 device I'm interested. I am therefore
guessing that my driver will need to sit 'above' the 1394 stack (so
that it can query the list of devices, maintain handles to them, etc,
etc).

Looking through <1394.h> I see quite a few local operations (such as
adding CSR unit directories). What should be used as a device handle
in these cases? For example, in Linux the OHCI is itself a device (/
dev/fw0), while IOKit has a special device node for the system.

So I guess my question is: how from my kernel code get I get and
maintain a list of attached 1394 devices without tripping up on PnP
etc?

Polemically yours, Freddie.

P.S. For those that are interested the primary purpose of my library
is to aid in performing memory forensics. This is why any and all
devices are of interest.

[David Craig]

Why would you want to do this for some (all?) 1304a/1394b adapters?
Microsoft already has one. It has been updated on 'recent' versions at with
the release of several of several updates via service packs and hot fixes.
When the target system is in debug mode using 1394a kernel debugging the
hardware disappears and is not accessible, which means you need to use USB
or serial to debug your 1394 driver. With USB 3.0 coming to life 1394 may
follow serial and the floppy drive into a dead technology museum.

There is truth to idea that using the RDMA features of 1394 ports will have
advantages in your stated purpose, but maybe some more study of how windbg
uses 1394 adapters. A good 1394 bus analyzer should help. Investigate,
research, and work on a good design before getting anywhere near writing a
driver.

Post by Freddie Witherden
Hello,
I am in the process of porting my FireWire library to Windows. It
currently runs on OS X and Linux -- so I have some experience with
FireWire devices and APIs.
As Windows does not provide a user-space API my plan is to use the
KMDF to expose the functionality I require from the stack via device
ioctls. I have looked over the KMDF portion of the 'vdev_hybrid'
sample in the WDK. The kernel interface seems fine.
However, if I understand it correctly: the associated application asks
the stack to create a 'virtual device'. Windows does not know how to
handle this, so asks for a device driver, the user supplies the
associated sys. Windows loads the driver and we all eat cake (which,
like the virtual device, is a lie :-).
My library needs access to *all* 1394 devices attached to the system.
That is to say that it is not associated with any one CSR unit
directory -- if it is a 1394 device I'm interested. I am therefore
guessing that my driver will need to sit 'above' the 1394 stack (so
that it can query the list of devices, maintain handles to them, etc,
etc).
Looking through <1394.h> I see quite a few local operations (such as
adding CSR unit directories). What should be used as a device handle
in these cases? For example, in Linux the OHCI is itself a device (/
dev/fw0), while IOKit has a special device node for the system.
So I guess my question is: how from my kernel code get I get and
maintain a list of attached 1394 devices without tripping up on PnP
etc?
Polemically yours, Freddie.
P.S. For those that are interested the primary purpose of my library
is to aid in performing memory forensics. This is why any and all
devices are of interest.

[Maxim S. Shatskih]

Post by Freddie Witherden
So I guess my question is: how from my kernel code get I get and
maintain a list of attached 1394 devices without tripping up on PnP
etc?

Without using PnP - no ways.

I think that 1394diag driver was once in the samples. It is buggy, but provides you with the idea of what is PnP.

[Freddie Witherden]

On Sep 14, 8:57 am, "Maxim S. Shatskih"

Post by Maxim S. Shatskih

Post by Freddie Witherden
So I guess my question is: how from my kernel code get I get and
maintain a list of attached 1394 devices without tripping up on PnP
etc?

Without using PnP - no ways.
I think that 1394diag driver was once in the samples. It is buggy, but provides you with the idea of what is PnP.

I'll take a look around for it. Thinking about the issue some more
maybe the virtual-device type approach is best. However, in the vdev
sample, it is necessary for the user to manually specify a driver for
the virtual device. Previously, all of the simple drivers I have
encountered have been of the form whereby the application loads a
driver programmatically, uses the ioctls it exposes, and then unloads
it. However, none of these had to interact with actual devices

Is there a way of doing a similar thing with the 1394 virtual device?
Ideally I would like my library (and hence the driver it must load) to
require no explicit intervention to load the required driver and to
unload/unregister itself when done. Are there any samples in the DDK
which cover this kind of scenario?