no1wudi commented on PR #13245: URL: https://github.com/apache/nuttx/pull/13245#issuecomment-2323164094
@lupyuen @acassis OK, indeed, a significant amount of work is still required before it stabilizes. I would like to clarify that the issue regarding the compatibility of struct definitions will take a longer period to address. Firstly, if NuttX introduces any breaking changes, these changes will first be integrated into libc. Then, we will wait for the libc crate to release a new version, followed by upgrading the Rust libstd's dependency on libc to the latest version. The entire cycle could potentially take several months. Currently, I would like to draw everyone's attention to the fact that, in order to reduce the likelihood of such occurrences, my current approach is to reserve space equivalent to two pointer sizes for each structure definition on the Rust side to accommodate updates on the NuttX side: 1. Once this PR is merged, it means that any modifications to these structures will be restricted, especially when adding new structure members. 2. Is the reservation of space equivalent to two pointer sizes appropriate? Regarding question 1, I personally believe that the structures currently under review are all included in the POSIX definition. POSIX defines the minimum set of members within these structures and allows OS implementations to extend them. Therefore, if modifications to these definitions are necessary, especially when adding internal data required by NuttX's implementation, special handling for them should be acceptable. For example, with `struct tm`: https://github.com/apache/nuttx/blob/32801d3047174ef30cea759d0ec0dcd31a077bca/include/time.h#L139 `tm_gmtoff` is not in POSIX: https://pubs.opengroup.org/onlinepubs/9699919799.orig/basedefs/time.h.html If in the future we need to add other similar non-standard members that cause the reserved space to be insufficient, then we can wrap these members into an internal NuttX structure and point to this internal structure from struct tm using a pointer. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
