Open cfriedt opened 7 months ago
We could of course not do this
Gets my vote
We could of course not do this
Gets my vote
@nordicjm - FWIW, I did this back in 2018 or something for a previous employer as a research project and it was surprisingly easy.
Not that I'm saying I want to do it again by any means 😅
If people want to move their code over to zephyr, they should do it properly. I don't see the point in a threadx/freertos/etc. porting layer that people in zephyr have to implement and then support. If something breaks, we then have to fix it. It sounds like a lot of work for no real gain.
@cfriedt How about the migration guide? I know it will become outdated sooner or later, but at least the Zephyr Project won't need to maintain that piece of code.
@cfriedt How about the migration guide? I know it will become outdated sooner or later, but at least the Zephyr Project won't need to maintain that piece of code.
That's a good idea!
Technically, we could also offer a FreeRTOS migration guide.
A migration guide for both sounds like a great idea
Is your feature request related to a problem? Please describe.
The ThreadX API is pretty lightweight and was just released under the MIT license [1]. We should implement a migration guide in Zephyr for companies who are thinking about making the leap.
Describe the solution you'd like An mapping or table relating ThreadX API calls to similar Zephyr API calls.
Potentially a mapping of NetX API calls as well (although NetX had some limited BSD Sockets API support).
Describe alternatives you've considered
Additional context Microsoft opens sources ThreadX under MIT license • The Register
https://www.theregister.com/2023/11/28/microsoft_opens_sources_threadx/