Also worth knowing
There will be another IOCTL added to the list. I didn't include it in the
commit.
WLIOC_SETMOD [enum] this specifies which modulation technology you want to
use.
This is important as many RF radios can switch between them.
This unlocks the modulations WLIOC_(modulation)_(function).
It can return an error if it is not supported, ofcourse.


Op vr 14 mrt 2025 om 12:51 schreef Kevin Witteveen <kevinwit1...@gmail.com>:

> Hi all,
>
> Thank you for thinking along!
> I've noted all these down.
>
>
> *KConfig warning*Good idea but I agree that adding Kconfig that does
> little to nothing might not be the best idea. It feels awkward to me
> knowing the kconfig is indeed already quite complicated.
> Next to that, the experimental marking is everywhere, in comments, ioctl
> and docs.
>
>
> *Change but no breaking*I agree and this change can be purely *additive*
> instead of a *replacement*.
>
> I personally feel awkward about breaking the IOCTL command to change power
> in dBm to 1/100 steps. It makes practically no sense to have decibels in
> 1/100 steps. Even 1/10 is usually for precision equipment.
> 1/1 steps are fine enough for nearly all applications. Maybe for this
> instance, a driver specific precision dBm power set IOCTL might be a
> solution.
> This removes the "breaking change" from the equation. (However, see below)
>
> *Legacy config*
> That is totally a solution as well. Which might even solve the problem
> above
> *"dBm 1/100 vs dBm 1/1".*Also might be able to disable the old commands
> to save some memory.
> Though, I have felt resistance from some people about legacy and adding
> kconfig.
>
> I'm happy to hear more.
>
> Op vr 14 mrt 2025 om 11:53 schreef Sebastien Lorquet <sebast...@lorquet.fr
> >:
>
>> Hello
>>
>> For me the wrong is not to change, but to break the old working thing.
>>
>> The old IOCTLs can be maintained. Either by design, or as a config
>> option like CONFIG_WLIOC_ENABLE_LEGACY with default yes.
>>
>> That would work for me, I think, as it would allow running old code
>> without changing it (or just by adding a build option).
>>
>>
>> After all, linux has several syscalls doing the same thing with various
>> options. Documentation says it's totally deprecated, but it still works.
>>
>> Sebastien
>>
>>
>> On 14/03/2025 11:10, Xiang Xiao wrote:
>> > It's totally wrong to change interface definition or meaning by Kconfig.
>> > Interfaces mean some contract between kernel and userspace, how do
>> > applications follow the changing contract?
>> >
>> > On Fri, Mar 14, 2025 at 7:47 AM Nathan Hartman <
>> hartman.nat...@gmail.com>
>> > wrote:
>> >
>> >> 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)
>> >>>
>>
>

Reply via email to