Thanks for directing the discussion to the correct Zephyr mailing list. I did
not know there was a users list.
It would be great if Linaro could work on ARM boards and also other areas of
Berlin Open IoT summit.
The GitHub issues is now the correct and only way to indicate bugs and feature
items. We are in the process of adding more infrastructure around the project.
That is, CI, mailing lists and IRC. There are still few moving parts before we
can have that available. So for now, let’s use the GitHub issues.
On 10/13/16, 10:53 PM, "Paul Sokolovsky" <paul.sokolov...@linaro.org> wrote:
On Wed, 12 Oct 2016 08:39:14 +0000
"Poussa, Sakari" <sakari.pou...@intel.com> wrote:
> Hi Paul,
> Glad to hear your positive thoughts about the project. We really want
> to make this a community project and are totally open to external
> contributions and collaborations. I just merged our first external
> patch from you! I have already been talking with few people who would
> like to contribute features to the project. This is a nice start.
Thanks, and I would definitely be happy to contribute to the project,
and help with FRM-K64F, and ARM targets in general, maintenance. Except
that an original Linaro's plan was to work on IoT.js, so I appreciate
the detailed answer below regarding it, that will help to align our
planning/project management (I'm sure it will be useful for other
I find the arguments below compelling - indeed, IoT.js design didn't
seem like the simplest and the most lightweight. But then Zephyr.js
lacks many features comparing to IoT.js, so would be nice to discuss
future plans and prioritization of things to be added. I submitted
couple of RFC/discussion like tickets to
https://github.com/01org/zephyr.js/issues , but wonder if that's what
you'd recommend for such topics (vs something like a mailing list, and
which then? - as you can see, I cc:ed this thread to Zephyr users
mailing list, IMHO it's the most appropriate one so far, short of
creationg a dedicated one for Zephyr.js specifically).
Thanks, and looking forward to seeing today's ELCE slides/presentation
on Zephyr.js online (I didn't have a chance to visit).
> About the iot.js: We did evaluate and tried to use iot.js for our
> project when we started. Below are the reasons why we decided to
> create a new one instead of (re)using iot.js:
> - Iot.js is written with C++. C++ is not well supported on Zephyr,
> especially the new() method is not available.
> performance penalty to the runtime. We wanted to be as efficient as
> possible and used only C code.
> - Iot.js does not have modularity. You need to take all the features
> even if you only use one API. IN our project, we analyze the .js
> application and only build and link the APIs that app is using (both
> runtime and zephyr)
> - libtuv: the fork is not following the upstream and is/was missing
> some key features like UDP (IIRC)
> - We wanted to focus on one RTOS and make the project good there. We
> may revisit this goal at some point in the future.
> Based on the above, the decision was made to create one from scratch.
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
jerryscript-dev mailing list