forked from Imagelibrary/rtems
7e1a9ac5b5
Implement a mechanism for making changes in the kernel<->driver PPS interface without breaking ABI or API compatibility with existing drivers. The existing data structures used to communicate between the kernel and driver portions of PPS processing contain no spare/padding fields and no flags field or other straightforward mechanism for communicating changes in the structures or behaviors of the code. This makes it difficult to MFC new features added to the PPS facility. ABI compatibility is important; out-of-tree drivers in module form are known to exist. (Note that the existing api_version field in the pps_params structure must contain the value mandated by RFC 2783 and any RFCs that come along after.) These changes introduce a pair of abi-version fields which are filled in by the driver and the kernel respectively to indicate the interface version. The driver sets its version field before calling the new pps_init_abi() function. That lets the kernel know how much of the pps_state structure is understood by the driver and it can avoid using newer fields at the end of the structure that it knows about if the driver is a lower version. The kernel fills in its version field during the init call, letting the driver know what features and data the kernel supports. To implement the new version information in a way that is backwards compatible with code from before these changes, the high bit of the lightly-used 'kcmode' field is repurposed as a flag bit that indicates the driver is aware of the abi versioning scheme. Basically if this bit is clear that indicates a "version 0" driver and if it is set the driver_abi field indicates the version. These changes also move the recently-added 'mtx' field of pps_state from the middle to the end of the structure, and make the kernel code that uses this field conditional on the driver being abi version 1 or higher. It changes the only driver currently supplying the mtx field, usb_serial, to use pps_init_abi(). Reviewed by: hselasky@
This is the Real-Time Executive for Multiprocessing Systems (RTEMS). The version number for this software is indicated in the VERSION file. See the documentation manuals in doc/ with daily builds available online at http://rtems.org/onlinedocs/doc-current/share/rtems/html/ and released builds at http://www.rtems.org/onlinedocs/releases/ for information on building, installing, and using RTEMS. The INSTALL file tells you to come back here. See the RTEMS Wiki at http://devel.rtems.org for community knowledge and tutorials. RTEMS Doxygen available at http://www.rtems.org/onlinedocs/doxygen/cpukit/html The RTEMS Project maintains mailing lists which are used for most discussions: * For general-purpose questions related to using RTEMS, use the rtems-users ml: https://lists.rtems.org/mailman/listinfo/users * For questions and discussion related to development of RTEMS, use the rtems-devel ml: https://lists.rtems.org/mailman/listinfo/devel See https://devel.rtems.org/ to view existing or file a new issue report ticket.