Re: Proposal: Common IOCTL API for RF Modulation Technologies

2025-03-15 Thread Xiang Xiao
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 wrote: > Hi all, > > I like the fact that there has been a high le

Re: Proposal: Common IOCTL API for RF Modulation Technologies

2025-03-15 Thread Sebastien Lorquet
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

Re: Proposal: Common IOCTL API for RF Modulation Technologies

2025-03-14 Thread Kevin Witteveen
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 marki

Re: Proposal: Common IOCTL API for RF Modulation Technologies

2025-03-14 Thread Kevin Witteveen
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

Re: Proposal: Common IOCTL API for RF Modulation Technologies

2025-03-14 Thread Sebastien Lorquet
Hello, I suggest people have a look at the RF interface that was rejected when I suggested it. Just to see if that could contribute something to the proposal. There was ONE upper half driver with an unified ioctl interface for all radio devices. https://git.sr.ht/~f4grx/hn70ap/tree/main/i

Re: Proposal: Common IOCTL API for RF Modulation Technologies

2025-03-14 Thread raiden00pl
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

Re: Proposal: Common IOCTL API for RF Modulation Technologies

2025-03-13 Thread Nathan Hartman
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