Writing a 1394 interface driver
in [Device Drivers]
|
From: Freddie Witherden on 13 Sep 2010 19:29 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.
From: David Craig on 13 Sep 2010 20:40 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. "Freddie Witherden" <freddie(a)witherden.org> wrote in message news:c1289bac-42fa-420d-b758-0839ce0b331e(a)j2g2000vbo.googlegroups.com... > 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.
From: Maxim S. Shatskih on 14 Sep 2010 03:57 > 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. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Freddie Witherden on 14 Sep 2010 07:38 On Sep 14, 8:57 am, "Maxim S. Shatskih" <ma...(a)storagecraft.com.no.spam> wrote: > > 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?
|
Pages: 1 Prev: udelay (Linux) equivalent API in WDK driver? Next: ChkInf.bat /O option problem |