Hi,
I think where breaking out things has made sense has been when we can
get other people involved and grow the community of users of Mynewt
firmware. I’ll give a few examples:
- mcuboot: By breaking out the Mynewt boot loader, we’ve been able to
get Zephyr and RIOT to adopt it, leading to usage among large providers
like Flextronics, Fitbit (with their own OS), TrackR, etc.
- NimBLE: Synopsys now offers NimBLE with their IP layer because of
FreeRTOS support, and many other chip companies are starting to adopt as
an open solution that supports not just Mynewt but also FreeRTOS.
NimBLE is the BT stack in RIOT.
- mcumgr: Being adopted by Nordic for SW upgrade with MCUboot, ported
over and used as the default upgrade protocol for Zephyr in BT.
- nffs: supported and used on both Zephyr & Mynewt.
In my view, having a build & package management tool makes it easy to
compose these projects together, while also allowing them to release
independently, and build a community around specific problems (bluetooth
stack, secure boot.)
In my mind, the additional things that make sense to break out of core
(over time):
- other networking stacks: wifi_mgmt, LWIP, LoRA
- sensor interface
The logic being that these stacks can live independently, and support
other OSes as well. It would be nice if we could all share sensor
drivers across FreeRTOS, RIOT, Zephyr and Mynewt — and it will cause
us very little extra work to make that happen, and likely build a larger
community.
Also, one difference I would point out from the Linux kernel is that we
have (a) much more limited code space and (b) the kernel is not built
separately from the application. Therefore, it is nice to have a clean,
small core that provides base functionality, and then choose the
packages you want to include with that.
That doesn’t mean we have to segment the communities. In my view,
having separate repositories and releases for *-core, *-nimble, etc. can
all still happen on the same dev list and within the construct of
Mynewt. Maybe, over time, when they are much bigger communities we can
look at segmenting them into sub-PMCs. But I think providing the
logical separation in code makes a lot of sense, as it allows us to
share efforts with other RTOSes, and makes it easier for people to
integrate the components they need/want into their existing code bases.
Sterling
On 16 Jul 2018, at 23:51, Amr Bekhit wrote:
Having some experience with working with the Linux kernel (compiling +
configuring for custom hardware, debugging, patches), I kind of like
the monolithic approach for the following reasons:
- All the code is one place.
- Rather than having multiple drivers/libraries for the same thing,
there is one solution and all coding/debugging effort is poured into
that, reducing effort duplication.
- At the same time, it is still possible to add third party modules if
the mainline solution is not deemed sufficient.
- I think it helps maintain a certain level of code quality and
security - commits to the mainline code base are more likely to be
seen by many more eyes than commits to a small 3rd party module
maintained by a few people.
I quite like the modular structure of mynewt and the syscfg system - I
think it makes it very easy to just add in the bits you need to your
code. The repo system also makes it easy to add third party libraries
if required. I think it's a good thing that you download just one
code-base containing all the libraries you'll need and just include
the ones you want.
My own vote on the matter would be to stick with the monolithic
system.
On Mon, 16 Jul 2018 at 20:45, Greg Stein <[email protected]> wrote:
On Mon, Jul 16, 2018 at 12:43 PM Greg Stein <[email protected]> wrote:
On Mon, Jul 16, 2018 at 3:14 AM Pierre Kircher
<[email protected]>
wrote:
such community-managed resources must be provided
as apache.org websites
only if they take apache resources right ?
No... If *APACHE* Mynewt is managing this ecosystem, then it goes
under
apache.org.
Use p.mynewt.apache.org if you like. It can be short or long. I
never
type "http://us.archive.ubuntu.com/ubuntu"; as it just sits in
sources.list. The length doesn't bother me at all.
A closer analogy would be Maven Central. ... that is
repo.maven.apache.org,
even though it is operated by Sonatype under a trademark license from
us.
Cheers,
-g
