Hi all, I like the fact that there has been a high level analysis here and an effort to make things consistent across multiple types of communications.
Since the drivers mentioned are experimental, I agree that breaking changes aren't breaking stabilized interfaces. We should just be careful to mention this in the release notes because this could create a long debugging session for someone. Here's an idea: there could be a Kconfig that must be defined if using any of these drivers. Some kind of CONFIG_I_KNOW_ABOUT_THE_BREAKING_CHANGES_IN_THE_RF_DRIVERS. (That should *not* be its name; I'm only writing it to illustrate my idea.) If this Kconfig isn't present, #ifdef logic in the source code will deliberately break the build with #error directive, and adjacent documentation in the comments. This will ensure that nobody using the ioctl as it currently is will have any head scratching and long debugging session. Thoughts? Nathan On Thu, Mar 13, 2025 at 4:50 PM Kevin Witteveen <kevinwit1...@gmail.com> wrote: > Hi Nuttx, > > This is a follow-up to GitHub issue #15856 > <https://github.com/apache/nuttx/issues/15856> initiated by raiden00pl. > The > discussion there provides useful context for this proposal. > > *--- Summary ---* > Currently, the IOCTL API for character-driven RF devices lacks a common > interface across different modulation technologies, such as LoRa, FSK, and > OOK. As a result, driver-specific IOCTL commands are created even when they > could be shared across multiple radios. This fragmentation makes > application portability more difficult to maintain. > > *--- Impact ---* > This does require some changes to be made to 4 RF drivers. > > - My SX126x (New, experimental) > - Raiden SX127x, > - Linguini RN2xx3 (New, experimental) > - nRF > > The three of us—Raiden, Linguini, and I—support this idea and are already > involved in the development. Once implemented, this common API would make > it easier for IoT applications to run on NuttX with minimal driver-specific > modifications, reducing maintenance overhead and eliminating redundant > implementations. > > *--- Breaking ---* > This is considered a breaking change if the following IOCTL command may be > changed: > > WLIOC_SETTXPOWER takes an integer value for dB. This can be changed to > steps of 1/100 dB instead. Because the RN2xx3 and some radios can take > smaller values. (*Open for discussion)* > > However, the RN2xx3 and SX126x drivers are marked experimental, so any > modifications to these are *not* considered breaking. > > *--- Strategy ---* > > 1. Introduce new IOCTL commands without modifying legacy > implementations. > 2. Gradually migrate existing drivers to the new API while testing and > documenting. > 3. Remove legacy implementations > > To avoid breaking changes, we could retain the legacy APIs if desired and > only remove the *experimental* ones. > > *--- Proposal API header ---* > > https://github.com/keever50/nuttx/blob/common_wireless_character_driver_API/include/nuttx/wireless/ioctl.h > I collaborated with Raiden and Linguini on defining these IOCTL commands. > Feedback and suggestions from the community would be greatly appreciated. > > *--- Note about "Experimental" ---* > The SX126x and RN2xx3 drivers are marked as experimental, meaning users are > explicitly warned that changes may occur in the near future. They were > labeled as such before being merged. > > Looking forward to your thoughts! > > Best regards, > > Kevin (Keever50 on github) >
