I agree, here is an example change I had to do:
int itf_bring_up(int sd, struct ifreq *pifr)
{
int ret;
- pifr->ifr_flags = IFF_UP;
+ IFF_SET_UP(pifr->ifr_flags);
ret = ioctl(sd, SIOCSIFFLAGS, (unsigned long)pifr);
if (ret < 0)
{
@@ -263,7 +263,7 @@int itf_bring_up(int sd, struct ifreq *pifr)
int itf_bring_down(int sd, struct ifreq *pifr)
{
int ret;
- pifr->ifr_flags = IFF_DOWN;
+ IFF_CLR_UP(pifr->ifr_flags);
ret = ioctl(sd, SIOCSIFFLAGS, (unsigned long)pifr);
if (ret < 0)
{
It's cool to add these macros, but you removed IFF_DOWN and that was
annoying useless breakage.
The new solution with macros is better, but breaking all user code that
uses IFF_DOWN was probably unnecessary.
Sebastien
On 31/01/2025 17:54, michal.lyszc...@bofc.pl wrote:
On 2025-01-31 17:34:48, raiden00pl wrote:
How do you want to maintain compatibility between nuttx-apps and
nuttx while both are active development projects, and what's more
one of them is optional? It's not possible.
Same way as app/kernel compatibility is maintained in othes Unices like Linux or
BSD.
It would be possible if we assumed that the API in NuttX is perfect
and will not require changes, which is not true. There are many custom
solutions in NuttX that require improvements and these improvements
will break compatibility. There are many custom interfaces that need
improvement, such as PWM or sensors, and these changes will
definitely break apps.
No, just be super careful designing API to "userspace" and once commited it
stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as well.
That's why we still have "creat" instead of "create". Or we have 3 poll APIs in
Linux (select/poll/epoll). You really want to change API, you build another one,
and mark old one as deprecated, but you don't delete it. That would be ok if
Nuttx was <1.0.0, version, but it's >=1.0.0 so it should care about API/ABI.
Especially that it does not have to come up with API and just use what Posix
been using for decades now.
On the other hand, any standardized interface like POSIX must be stable,
which is obvious. But POSIX doesn't define everything, especially when
it comes to embedded systems.
So you carefully define it, keep it as EXPERIMENTAL for some time, which
allows for breaking changes, but once API is marked as stable - it is set in
stone. Period.
