Porting SVR5 DLPI drivers to MDI 2

In most cases, it is easier to modify an existing sample MDI driver to support your network adapter than to port a DLPI driver to MDI. The hardware-specific portions, such as the interrupt routine and transmit code, may be reused with some modifications.

If you want to port a SVR5 1 or 2 DLPI driver to SVR5 MDI, the following steps may help:

See the sample source code that is provided in the ndsample package for examples of how these coding changes are implemented.

• Replace the init(D2) and start(D2) entry point routines with a _load(D2mdi) entry point routine.

  Be sure that all hardware configuration is done using the appropriate DDI functions. Cards that run on an ISA bus will also require a _verify(D2mdi) entry point routine for DDI 7 or a CFG_VERIFY subfunction to the config(D2mdi) entry point routine. Additional hardware configuration information can be supplied by specifying parameters in the bcfg(DSP/4dsp) file.

• Modify the open(D2mdi) entry point routine in the following ways:

  • Enforce one open per adapter only.

  • For DDI 7 drivers, use the device's minor number to select board number instead of using multiple major numbers. For DDI 8 drivers, use the idata value, which specifies the board number.

  • Initialize the driver and hardware completely during the open( ) routine so that the driver can be closed and reopened to reset the hardware.

    DDI 8 MDI drivers can also do this initialization in the CFG_ADD and CFG_MODIFY subfunctions to the config(D2mdi) entry point routine, but they must also fully reinitialize the hardware across close( ) and open( ) operations. This allows the autorestart code (txmon) to reinitialize the hardware when a problem is detected by sending a MAC_HWFAIL_IND(D7mdi) message. The dlpid utility either starts a failover if there is a backup device configured or it closes and reopens the MDI driver.

  • For DDI 8 drivers, there is no CLONE flag; the minor number no longer denotes the number of opens.

• Remove all SAP demultiplexing code (DL_BIND_REQ message type). This is replaced with calls to MAC_BIND_REQ(D7mdi). MAC_BIND_REQ exists only to tell the driver when to start sending or receiving messages. Note that SAP is simply part of the data in MDI drivers.

• Call mdi_get_unit(D3mdi) in the _load(D2mdi) entry point routine.

• If in promiscuous mode, call mdi_do_loopback(D3mdi). See ``Promiscuous mode''.

• Replace DL_UNITDATA_IND and DL_UNITDATA_REQ primitive handling code with M_DATA(D7str) messages. The driver should not interpret or de-multiplex data on reception. Place the entire MAC frame in a STREAMS message and pass it up to the DLPI module.

• Replace calls to the DL_INFO_ACK primitive with calls to MAC_INFO_ACK(D7mdi). Note that the MAC version returns additional information.

• Delete all calls to the DL_UNBIND_REQ, DL_BIND_ACK, and DL_UDERROR_IND primitives.

• Replace DL_ERROR_ACK and DL_OK_ACK primitive handling with calls to the mdi_macerrorack(D3mdi) function. The MDI support routines send MAC_ERROR_ACK(D7mdi) and MAC_OK_ACK(D7mdi) primitives upstream.

• MDI uses a different set of ioctls, prefixed with MACIOC_*. See the Intro(MDI) manual page (on OpenServer 6), and the Intro(7mdi) manual page (on UnixWare 7.1.4) for more information about supported MACIOC_ ioctls.

• Look for occurances of DL_ and dl_ and modify the code to use MDI facilities.

• Remove the read and write srv(D2str) entry point routines. All MDI driver receive frame processing should be done at interrupt time, and the Service From Interrupt functionality (described in ``Increasing transmit performance'') provides the functionality of the write service routine.