I have doubts whether adding more kconfig options that basically do nothing makes any sense. NuttX configuration is already very complicated and making it even more complicated seems like a bad idea. We should describe the change well in the ReleaseNotes and that should be enough. It should be the responsibility of the developers to describe the breaking change well in the release notes, and it should be the responsibility of users migrating to another version to read the release notes.
pt., 14 mar 2025 o 00:47 Nathan Hartman <hartman.nat...@gmail.com> napisał(a): > 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) > > >
