On 2025-01-31 16:20:51, Tomek CEDRO wrote: > On Fri, Jan 31, 2025 at 3:35 PM <michal.lyszc...@bofc.pl> wrote: > > On 2025-01-31 13:48:32, Tomek CEDRO wrote: > > > On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet <sebast...@lorquet.fr> > > > wrote: > > > > Of course I also tried with the commit before that one, and it didnt > > > > work either. > > > > > > Sebastien, did you try the release packages? Does the problem occur in > > > the release packages? > > > > > > Upstream master is for development purposes, things may get broken for > > > a while, I would never put my product on a master branch. > > This is offloading responsibility to end user. Sebastian is right here. > > Either apps are separated properly so that even 1 year old apps repo will > > work > > with current HEAD of rtos, or nuttx should have sync mechanism like > > submodules > > (don't go there) or tool like Zephyr's west to sync it (or it can also be > > done with make/cmake). > > > > Did you ever try to bisect problem in nuttx? Constant failures in apps and > > you > > have to manually guess which commit is going to at least compile - and then > > you > > still cannot be 100% sure soft does/doesn't work as indended. > > Hmm, I get it. I saw that too. I thought it should be always in sync. > > I saw changes in either nuttx or nuttx-apps that depends on each > other. Not sure if that would allow apps to build / work on one year > old rtos code. > > So what are your solution propositions? There are 2 long term solution I see.
1) lower effort one - keep commit hash of apps in some file. Either check hash before doing `make all` or add new makefile command like `make appsync`. Either way, file .app-hash should always contain working app commit hash. app hash can also be hold as a Kconfig field. This will probably be enough - especially for bisecting. 2) Rewrite build system for apps. Use only absolute minimum and very stable API in rtos/apps. Really, apps should not have the need to know much about RTOS, few header files should be enough. When you build app for Linux you don't ingegrate with kernel source in any way - just use some header files provided by os/libc. Maybe there is 3) option I didn't thing about. > Usually OS has something called API and apps must adhere to that API. > If breaking change is introduced API number is bumped and so apps > needs an update. API/ABI to OS should not break apps, like ever. You can look up what Torvalds thinks about that. Internal API change is fine. But try to introduce ABI change for Apps, and be a part of immortalized in the internet as person Linus killed with words ;) > We should discuss and vote this kind of design decision and put inside > CONTRIBUTING and documentation f anything changes. > > Also I welcome everyone to help in PR review if changes are impacting > you, catch them first before merge :-) I'd love to, but can't get any company to choose Nuttx over Zephyr ^^ And privately I am currently doing projects that don't really involve RTOS at all. So I am kinda out of the loop these days. -- .-----------------.-------------------.----------------------.-----------------. | Michal Lyszczek | Embedded C, Linux | Company Address | .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `----.--------------: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `----------------------^--------------^----------------------^-----------------'
signature.asc
Description: PGP signature
