Endian issues for drivers

``Endianness'' refers to the byte order in which data is stored in computer memory. Intel systems and most peripheral busses use the ``little endian'' model, where the least significant byte is at the lowest address in memory. Other CPUs, such as the Sun SPARC system, IBM's PowerPC, and Hewlett-Packard Precision Architecture systems, as well as SCSI devices and network protocols use a ``big endian'' model, where the most significant byte is at the lowest address in memory.

In other words, if b0 is the least significant byte, the byte order is:

Endian model	16-bit value	32-bit value
Little endian	b0 b1	b0 b1 b2 b3
Big endian	b1 b0	b3 b2 b1 b0

Drivers that run only on CPUs and busses that share the same endianness do not need to worry about endian issues. Drivers written for CPUs that have different endianness from the supported busses must swap bytes appropriately for I/O operations. Drivers that use common source for little-endian and big-endian CPUs or that handle run-time switchable models must be coded to handle both models appropriately.

Coding DDI or ODDI driver for endian safety

SVR5 DDI drivers and SCO OpenServer 5 ODDI drivers must do the following in drivers that may have endianness issues:

• Define a function that determines the endianness of the host system.

• Provide functions that swap each access per word when the endianness of the card and the bus do not match. These operations should be protected with spl( ) calls or spin locks to ensure that they execute atomically; see ``Critical code section''.

See ``Code fragments for handling byte order (``endianness'')'' for code that can be copied into your driver to provide this functionality.

The caveat is that, as the code evolves over time, you must be sure to modify and test the code for both little-endian and big-endian systems.

With C++, you can define data types that make this swapping completely invisible to the programmer, (such as little_endian_word instead of int) and then overload the operators that access it.

The interfaces for mass storage devices provide functions for swapping bytes. For the SVR5 SDI, use the sdi_swap16(D3sdi), sdi_swap24(D3sdi), and sdi_swap34(D3sdi) functions. For the SCO OpenServer 5 OSDI, use the scsi_swap4(D3osdi) function. These should only be used in mass storage drivers.

UDI and endian issues

UDI handles most endian issues transparently; the platform environment does any byte swapping that may be required. The only time a UDI driver must handle its own endian issues is for a DMA device. If the I/O operation transfers a block of non-character data of one endianness into host memory of another endianness, the driver must handle the byte-swapping of the data. The UDI environment notifies the driver that the data must be swapped and provides the udi_endian_swap( ) function to do the swapping.