"Bill McKenzie" <bmckenzie@osr.com> wrote in message
news:%23Wr0uvEQDHA.2480@tk2msftngp13.phx.gbl...
Thank you for the reply.

Say, I wish to develop a driver before available 1394 hardware, thus I have
to create a virtual device. Why whould I need a physical controller since I
am not going to attach any physical devices to it? In other words, why would
I need a physical bus when a virtual one would be enough? I understand that
I can plug in a controller, but my goal is to get the above working without
it. Sorry, I cannot go into details any further.

Cheers,
Nick

Bill, thanks for such a lengthy comment. I really appreciate it.

I should have said that I'm interested in XP only. I don't worry about
Win2k.

You mentioned that I need two PCs and a cable in order to use a virtual
device. I believed it must be a bit simple. Let's consider the following.

Configuration A
-----------------

I have a real host controller in my PC plus some real device connected to
that controller. I create a virtual device by
IOCTL_IEEE1394_API_REQUEST/SET_LOCAL_HOST_PROPERTIES_MODIFY_CROM, and my
driver fully emulates this virtual device. As far as I understand, my driver
will be similar to the 1394vdev sample, right?

(1) The above virtual device emulates, say, a video camera. It responds to
iso read requests and sends, say, some static picture. I expect that Windows
will load 61883.sys and avc.sys for my virtual device, and the camcorder
will show up in the Scanners & Cameras applet, won't it?

(2) Same as (1). The real device connected to the host controller knows how
to talk with camcorders. It sees my virtual camcorder on the bus and talks
to it. Windows translates physical 1394 packets sent by the real device to
IRPs passed to my virtual device driver. Is this possible on XP?

(3) The virtual device emulates a host controller. Can my virtual host
controller control the real device connected to the real controller? Why
not? Wouldn't my virtual controller appear as a real one that is plugged
into a second PC and connected to the first real controller via a cable?

Configuration B
-----------------

I cannot plug in a real controller into my PC. Let's assume I managed to
load ohci1394.sys for a virtual PCI PDO. Let's assume that ohci1394.sys
thinks that it talks to a real host controller, but there are no devices
connected to the controller. 1394bus.sys is loaded automatically by
ohci1394.sys as usually.

I create a virtual device by
IOCTL_IEEE1394_API_REQUEST/SET_LOCAL_HOST_PROPERTIES_MODIFY_CROM, and my
driver fully emulates a camcorder. It responds to iso read requests and
sends, say, some static picture. I expect that Windows will load 61883.sys
and avc.sys for my virtual device, and the camcorder will show up in the
Scanners & Cameras applet, won't it?

Configuration B is my original question. Do you think the above won't work?
Please assume that I managed to load ohci1394.sys (whether this is possible
or not is a separate question).

Regards,
Nick

"Bill McKenzie" <bill.mckenzie@compuware.com> wrote in message
news:3f043b6c$1@10.10.0.241...

1. I have added virtual device as you suggested and can see v1394/***.
But what I never understood is "non existant hardware". What is
non-existant? You have 1394 link and 1394 phy chips in XP 1394 adapter
card. There is similar 1394 adapter card otherside say Windows 2000.
When there is "real 1394 link and PHY " hardware on both sides, what
XP is emulating? I understand adding a model and vendor unit
directories for recognition to load driver.

2. In Winddk sample, we have 1394diag.sys and 1394vdev.sys. Do we need
both?
Let me explain what I am looking for. I have WinXP PC and Win 2000 PC
and
2 other embedded 1394 devices(these devices we can iamgine as those
that have link, phy of 1394, 1394 embedded software driver and
receives and sends Isoch and asynch data). I know how to connect
Windows 2000 and two 1394 medical devices and all three are
communicating. Now to bring XP into this network, can I use same
Windows 2000 device driver with virtual device add and remove
functions ? Can one XP 1394 device driver work for both devices and
Win 2000.

Your real hardware.

You have a real 1394 connection, but your particular hardware configuration
has to be emulated, right? In other words, if your yet to be created real
1394 hardware device will implement a specific register behavior at address:
0xFFFFC0009C then the host controller isn't very likely going to know to
provide this same behavior when this address is accessed, right? So, your
hardware emulation driver will allocate an address range for this address
(and probably others), and will emulate the desired behavior. This is not
necessary if all you want to do is talk end to end on the wire. There is a
difference between a virtual device driver, and a hardware emulation driver.

Yes, but not without some modification. I have done exactly this with one
driver though. You have to keep in mind how 2000 and XP differ. That means
understanding the differences in asynchronous addressing modes for the two
types of devices you are dealing with here. If you haven't already, check
out my article in the latest issue of WD3 http://www.wd-3.com

--
Bill McKenzie
Compuware Corporation
Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
http://frontline.compuware.com/nashu...es/utility.htm

Glad it helped.

Well, you can, from your driver, get the topology map and then query every
node to see if it is a node of interest. I have done this implementing a
special ID register for my virtual (and 2000 diagnostic) devices. This
isn't ideal, as you have to read the memory space of every node on every bus
reset, but it works for lack of a better solution.

--
Bill McKenzie
Compuware Corporation
Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
http://frontline.compuware.com/nashu...es/utility.htm


"Raj" <r_konjeti@mailcity.com> wrote in message
news:8509fde8.0307220539.6c010875@posting.google.c om...

Hi Bill,

There is another important design change in Win2000 and XP driver -
when we are using Virtual device. Since one 1394 virtual device will
suffice per host controller, there is no 'device extension data per
device' that can be stored and each device storing its info was widely
encouraged in Win2000 driver design. Then all data for all devices is
either stored globally or stored in device extension of virtual device
which would again look like global.

Is there a way where I can simply go for 2000 style and not enumerate
virtual device at all in XP when talking to Win2000 and embedded
device. Your article (in wd-3 Figure-2)shows 1394/microsoft&1394_pc on
both sides of XP. I call them XP PCs because I see virtual device on
them. But you also said " The diagnostic device ID is no longer
available for general use on XP and later Windows platforms". Here I
was confused. Can you clear this?

Thanks a lot.

A unit directory for microsoft&1394_pc is always added for host controller
config ROMs, even on XP. The beauty is you can add your own unit
directories as well.

This is why you need to create your own unit directory and have your virtual
driver act as a hardware emulation driver as well. It is not terribly
surprising that your async transfer succeeded. You must have touched a
valid register on the host controller??

Not sure on this really. I don't know of a standard layout or convention
for addresses. There may be one I just don't know about it if there is. I
would see what my virtual/hardware emulation driver could allocate, and
stick the base address in the unit directory I created so drivers could just
read it out from there.

None of your business

I don't know everything it does, mainly because I just don't care. You
don't need this ID anymore because of virtual devices and hardware emulation
capabilities. Alas, I guess my explanation of all this wasn't as clear as I
had hoped for.

--
Bill McKenzie
Compuware Corporation
Watch your IRPs/IRBs/URBs/SRBs/NDIS pkts with our free WDMSniffer tool:
http://frontline.compuware.com/nashu...es/utility.htm



"Raj" <r_konjeti@mailcity.com> wrote in message
news:8509fde8.0307250658.5772e0ef@posting.google.c om...