Re: NDIS WDM driver installation for multi-port NIC

That model is certainly quite different from how we've treated resources on
the board in the past, where the interfaces are secondary, rather than
primary, resources (the ports are currently controlled by an API and are
independent of the Windows stack).

Can you elaborate more on structurally, how the device tree would look for
this board? I've been trying to describe how I think the picture should look
like for the device tree, but I'm having trouble because the "bus driver" is
in reality a monolithic bus and function driver. The whole board and each
interface are currently controlled via a single API and single FDO. I guess
in the end, it shouldn't matter whether multiple drivers are combined into
one physical .sys, as long as the functionality is separated out within the
driver clearly?

Would you have the board's (bus) PDO at the bottom, followed by the board's
(bus) FDO, followed by the port PDOs (possibly with an FDO on top of each
PDO)?

So in other words:

Miniport: Mini0 Mini1
| |
Bus/Func: PortPDO0 PortPDO1
\ /
Bus FDO (board)
|
Bus PDO (board)

"Don Burn" wrote:

The bus driver should instantiate a PDO for each physical port. If you
design the interface correctly, this will allow you to have a seperate NDIS
WDM instance, that then talks to its given port.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply



"DW" <DZ@xxxxxxxxxxxxx> wrote in message
news:A7B6D992-A1F9-483D-BCBE-AD4AEF344F4E@xxxxxxxxxxxxxxxx
I know how to install an NDIS WDM driver over a bus driver like the pcidrv
sample. However, I'm still trying to understand the different ways to
programmatically install multiple instances of an NDIS WDM driver over a
single instance of a bus driver. The reason there is an N-1
correspondence of
miniport devices to bus/functional devices is because the bus/functional
device accesses a single card, which has multiple physical ports. Would
it
make more sense to create the device tree differently so that there is a
1-1
correspondence between devices and to share the state information?

Can the devcon sample be used as a starting point? If I understand things
correctly, I should be able to use SetupDiCreateDeviceInfo to create
multiple
NDIS WDM devices/nodes on top of a given bus/functional device.



.

Relevant Pages

  • Re: [RFC/PATCH 0/22] W1: sysfs, lifetime and other fixes
    ... > and they must follow protocol, defined in family driver. ... presented with a unified interface. ... bus - it's all the same. ... You are over-engineering and making kernel code ...
    (Linux-Kernel)
  • Re: Several questions to develop driver with eVC
    ... "driver" in the traditional sense you can use a combination of LoadLibrary ... > information for the driver is placed in the registry and then something ... > the standard stream interface. ... > a PnP bus then you can just remove the device from the bus to get the bus ...
    (microsoft.public.windowsce.platbuilder)
  • Re: [PATCH 0/13] Time: Generic Timeofday Subsystem (v B10)
    ... bus type 'platform' registered ... Registering sysdev class '' ... device class 'pci_bus': registering ... usbcore: registered new driver usbfs ...
    (Linux-Kernel)
  • Re: Linux Firewall/LoadBalancer
    ... The bonding driver originally came from Donald Becker's beowulf patches for ... Build kernel with the bonding driver ... "Bonding driver support" in the "Network device support" section. ... so the bonding driver will automatically load when the bond0 interface is ...
    (Security-Basics)
  • Using -current on a Fujitsu Lifebook N5010 (no Atheros 802.11, no Ethernet, + hard freezes)
    ... faced in terms of missing kernel support for this laptop. ... Version of Atheron 802.11a/b/g driver is too old. ... acpi0: on motherboard ... <ACPI PCI bus> on pcib0 ...
    (freebsd-current)