Network Drivers#

Core Networking supports three variety of drivers. These are:

• Native drivers: Drivers which have been developed from scratch for use with the io-pkt stack
• io-net drivers: Drivers which were written for the legacy networking stack io-net
• NetBSD Ported drivers: Driver source which was taken from the NetBSD source tree and ported to work with the io-pkt stack

The native and NetBSD drivers all hook directly into the stack in a similiar manner. io-net drivers interface through a "shim" layer which converts the io-net binary interface into the compatible io-pkt interface. We have a special driver (devnp-shim.so) which is automatically loaded up when you want to start an io-net driver.

Differences between ported NetBSD drivers and native drivers#

There's a fine line between what a "native" and ported driver is. If you do more than the initial "make it run" port, the feature set of a ported driver and a native driver won't really be any difference. From a source point of view, a ported driver has a very different layout than a "started from scratch" native Core Networking driver. The native driver source (under sys/dev_qnx) looks quite similar in terms of content and files to what an io-net driver looks like and have all of the source for a particular driver under one directory. The NetBSD driver source (under sys/dev) is quiet different in layout with source for a particular driver spread out under a specific driver directory, ic, pci, usb and other directories depending on the driver type and bus that it's on.

• NetBSD ported drivers don't allow the stack to run in multi-threaded mode. NetBSD drivers don't have to worry about rx / tx threads running simultaneously when run inside of the NetBSD operating system so there isn't a need to have close attention paid to appropriate locking issues between rx and tx. For this reason, a configuration flag is, by default, set to indicate that the driver doesn't support multi-threaded access. This will result in the entire stack running in a single threaded mode of operation (if one driver isn't multi-threaded capable, no drivers will run with multiple threads). This flag can be changed once the driver has been carefully examined to ensure that there are no locking issues.
• NetBSD drivers don't include support for Neutrino specific utilities such as "nicinfo".
• Unless otherwise indicated, we will provide source and allow you to build NetBSD drivers that we've ported, but, unless we have full documentation from the silicon vendors, we won't be able to classify the device as supported.

Differences between io-net drivers and other drivers#

• io-net drivers export a name space entry (/dev/enx). Native drivers do not.
• You can unmount an io-net driver (umount /dev/enx). With a native driver, you have to destroy it (ifconfig tsec0 destroy).
• io-net drivers are all prefixed with "en". Native drivers have different prefixes for different hardware (e.g. "tsec" for Freescales TSEC devices).
• io-net drivers support the io-net devctl commands. Native drivers do not.
• io-net drivers will be slower than native drivers since they use the same threading model as that used in io-net.
• io-net driver DLLs are prefixed by "devn-". Core Networking drivers are prefixed by "devnp".

How do I load / unload a driver?#

Drivers can be loaded into the stack from the command line just as in io-net.

• io-pkt-v4-hc -di82544

This command line invocation will work regardless of whether or not the driver is a Core Networking driver or an io-net style driver. The stack automatically detects the driver type and will load the devnp-shim.so binary in the event that the driver is an io-net driver. You need to make sure that all drivers are located in a directory that can be resolved by the LD_LIBRARY_PATH environment variable if you don't want to have to specify the fully qualified name of the device in the command line.

You can also "mount" a driver in the standard way:

• mount -Tio-net /lib/dll/devnp-i82544.so

The standard way to remove a driver from the stack is ifconfig <iface> destroy

• ifconfig wm0 destroy

How can I trouble shoot a driver?#

For native drivers and io-net drivers, the nicinfo utility is usually the first debug tool that's used (aside from ifconfig) when problems with networking occur. This will let you know whether or not the driver has properly negotiated at the link layer and whether or not it is sending and receiving packets.

For NetBSD ported drivers that don't include nicinfo capabilities,

How do I port a NetBSD Driver#

A rough and ready guide to how a driver was ported from NetBSD to Core Networking is available in the source tree under /trunk/sys/dev/doc. The NetBSD drivers make heavy use of libnbdrvr.so, the NetBSD porting library. This library abstracts out the NetBSD OS calls and replaces them with the appropriate Neutrino OS calls. While mostly complete, we're expecting that this library will need updates and tuning as time goes on, especially when we start porting more USB devices over (at this stage, USB support in the porting library is best characterized as "experimental". It works, but we haven't exercised it to a large degree).

How do I write a new Core Networking Driver?#

A tech note covering how to write a native Core Networking driver is available in the source tree under /trunk/sys/dev_qnx/doc. Sample driver code is also available under trunk/sys/dev_qnx/sample directory.

Wired Drivers_#

Ported NetBSD Drivers#

devnp-bge.so

devnp-msk.so

devnp-fxp.so

Native Drivers#

devnp-i82544.so

devnp-speedo.so

devnp-mpc85xx.so

devnp-bcm1250.so

Wireless Drivers#

Ported NetBSD Drivers#

devnp-ral.so

devnp-ural.so

devnp-ath.so

Native Drivers#

Due to licensing restrictions, we will not be able to provide either source code or binaries on Foundry27. These will be included as part of the official GA release though (the difference being that you have to specifically agree to an EULA as part of the GA installation process). Customers requiring access to these drivers before the GA release should contact their sales reps for more information.

The initial release of Core Networking will include official support for the following Wi-Fi chip sets

• Atheros 5006x
• Broadcom 43xx
• Marvel 8686