Feature Description#

We had a features change request to make certain devctl operations on the process manager plus select filesystem devctls, which always worked across QNET, to work between nodes of different endian-ness.

The problem is that these devctls transmit binary structures containing mixes of character string and integer fields. The integer fields, and only the integer fields, would need their endian-ness converted to that of the requesting node on response to the devctl().

The specific devctls requested to work cross-endian were:

procnto:

• DCMD_PROC_INFO
• DCMD_PROC_CURTHREAD
• DCMD_PROC_GETGREG
• DCMD_PROC_PAGEDATA
• DCMD_PROC_MAPINFO
• DCMD_PROC_STATUS
• DCMD_PROC_TIDSTATUS
• DCMD_PROC_SYSINFO
• DCMD_PROC_IRQS
• DCMD_PROC_TIMERS
• DCMD_PROC_CHANNELS
• DCMD_PROC_MAPDEBUG_BASE
• DCMD_PROC_MAPDEBUG
• DCMD_PROC_THREADCTL
• DCMD_PROC_MAPDEBUG_BASE
• DCMD_PROC_MAPDEBUG
• DCMD_PROC_THREADCTL

filesystem:

• DCMD_BLK_PARTENTRY
• DCMD_FSYS_STATISTICS
• DCMD_FSYS_STATISTICS_CLR
• DCMD_FSYS_PREGROW_FILE
• DCMD_FSYS_FILE_FLAGS
• DCMD_FSYS_MAP_OFFSET
• DCMD_FSYS_STATVFS
• DCMD_CHR_ISCHARS

Note that filesystem cross-endian support work is performed in combination by libc and io-blk (i.e. generic QNX layers), therefore all filesystem personality modules (i.e. fs-dos, fs-qnx4, etc.) will operate cross-endian.

Cross-endian readdir() support shall be added for the Block I/O Filesystems.

All remaining devctls (i.e. without cross-endian support) associated with Resource Managers for which the RESMGR_FLAG_CROSS_ENDIAN flag is enabled shall be modified to return the "EENDIAN" error code when cross-endian usage is attempted.

Implementation#

The following changes were made to the Neutrino Kernel’s implemenation of the procfs resource manager (pathmgr/procfs):

The changes are:

1. detect if a devctl() request came from a cpu of opposite endian-ness, and if so
2. convert the request data structure into the local endian
3. use existing code to process the request and construct the reply a native data structure
4. convert reply data structure into the requester's endian-ness

Each data structure to be converted has it's own conversion function. Each conversion function knows which fields of the structure are integers and applied endian swap operations to those integer fields. The conversion functions are named to map simply to the data structures they are converting.

Safety considerations:#

Since most of these devctls() are requesting information from procnto, they pose a very low saftey risk. That is because most of the devctls create a new data structure, populate it with information, and return it to the user. So swapping the endian-ness is very safe since the conversion functions are operating on copies of the data rather than on live procnto data structures. Therefore a bug in the conversion functions for the read-only DCMDs cannot damage procnto.

There are two exceptions

1. DCMD_PROC_SYSINFO returns a copy of the system page. It is crucial to avoid endian-swapping the real system page, since that would crash the system. Instead, we copy the system page into a temporary buffer, convert that, and send it to the requester. To make sure the procfs_swap_sysinfo() function cannot be accidentally called on the real system page, it asserts that it is swapping a copy (by checking addresses).

2. DCMD_PROC_THREADCTL is not merely a data read devctl(). It changes thread states. So procfs_swap_threadctl() must be inspected to confirm it is converting endian properly. However, a bug in procfs_swap_threadctl() is most likely to fail safely since most likely procnto will detect the improperly swapped pid and tid to be invalid.

Design and Code Reviews#

Design-review discussion are held in this forum thread:

http://community.qnx.com/sf/discussion/do/listPosts/projects.core_os/discussion.osrev.topc10244

Code-reviews are held in this forum thread:

http://community.qnx.com/sf/discussion/do/listPosts/projects.core_os/discussion.osrev.topc10173

This feature has implications for the Safety Manual and these have been incoporated.