
Linux Foundation to support Zephyr microkernel - Animats
https://www.zephyrproject.org
======
Animats
Press release from Linux Foundation.[1]

Zephyr is a no-protection microkernel, like VxWorks (but unlike QNX, Minix, or
L4, which run user processes in protected mode.) Everything is in one address
space. It's actually Rocket, from Wind River, which also sells VxWorks and has
open-sourced Rocket. Zephyr is for very small systems. Think smart light bulb,
not WiFi router. Supported hardware includes the Arduno Due (ARM) and Arduino
101 (x86). The QEMU emulator can be used for testing. The API is C-oriented
and very low level - fibers, threads, mailboxes, semaphores, etc.

[1] [http://www.linuxfoundation.org/news-
media/announcements/2016...](http://www.linuxfoundation.org/news-
media/announcements/2016/02/linux-foundation-announces-project-build-real-
time-operating-system)

~~~
MrTonyD
Are you saying that Zephyr is Rocket? I didn't see anything in the press
release saying that, and I didn't see anything on the web site saying that
(admittedly, I only spent a few minutes looking...).

If it is Rocket, is it a product that couldn't get traction so now they are
giving it away?

~~~
Animats
Here's the statement from Wind River:[1] "Wind River contributed the Rocket
kernel to Zephyr who brings together industry leaders in software and hardware
to build an RTOS for IoT." There will still be a proprietary version of
Rocket, which is the same kernel but also has components for connecting to
Wind River's "App Cloud", which seems to be a hosted IDE. The Zephyr project
offers only command line build tools under Linux.

[1] [http://blogs.windriver.com/wind_river_blog/2016/02/wind-
rive...](http://blogs.windriver.com/wind_river_blog/2016/02/wind-river-
welcomes-linux-foundations-zephyr-project.html)

------
cpeterso
Why is the Linux Foundation interested in supporting a non-Linux operating
system?

~~~
Animats
That's a good question. Anyone know the political background?

Zephyr is for systems far too small for Linux. You don't even have to have a
file system.

Several of the endorsers in the press release speak of Zephyr as "secure".
This OS has no memory protection, no user IDs, and no permission system. Any
code can do anything. Messages are passed around as raw pointers; they're not
copied. Nor is the size sent with the message. And it's all in C. What could
possibly go wrong?

There's nothing wrong with using an OS like this when your application program
is a few hundred lines. But if you add a networking stack and a mini web
server, there's going to be trouble.

[1]
[https://www.zephyrproject.org/doc/api/api.html](https://www.zephyrproject.org/doc/api/api.html)

~~~
cpeterso
It seems like small, custom systems like these without memory protection
should at least use a safe language like Rust.

~~~
SeanDav
C can be very safe or very unsafe, it just depends on how you use it. As a
counter point: critical code for missions to Mars are written in C.

[http://www.verticalsysadmin.com/making_robust_software/](http://www.verticalsysadmin.com/making_robust_software/)

~~~
obelisk_
Just because expert C programmers were _able_ to make it work doesn't mean
that C is the best way to write secure code. I say this as someone who writes
quite a bit of C (though I don't view myself an expert in it yet).

~~~
SeanDav
I highly doubt they just drew C out of a hat and decided to make it work for
their multi million dollar, "absolutely-cannot-fail-software". They would have
considered other languages out there. C was the winner.

~~~
nickpsecurity
Speaking from high-assurance niche, C absolutely sucked for that in more ways
than you can imagine. Like the recent NASA post, the reason they use C is
tooling and available talent. Ridiculous amounts of manpower went into
developing static analysis, testing, compilers, etc for C. The best talent in
high assurance pretty much all know C, too, whether or not it's their default
language. Almost all the hardware supports it, too.

So, a combo of top talent w/ a C history and tons of tooling made most of them
go with C. Many others went with Ada/SPARK. A few small fish even use typed or
structured assembler. C is only chosen due to tooling and "better the devil
you know" philosophy. Work on superior languages got more results with less
effort in both human and mechanical reviews, though. So, the inferior language
is only used due to an accident of history.

Details on that here:

[http://pastebin.com/UAQaWuWG](http://pastebin.com/UAQaWuWG)

~~~
pekk
Are you recommending that people switch to Ada, or Pascal, or what? Your
pastebin seems to strongly favor Algol-likes. It would be nice to see some
more substantive reasons why people should be using an Algol-like language in
2016. Just saying that C was originally hacked together to be expedient
doesn't quite make that case.

~~~
nickpsecurity
There's a number of HLL's to choose from today with less safety issues. Start
with an efficient one. If developing languages or compilers, then put effort
into one that has a nice foundation instead of C. Similarly, there's prior
work on C-like languages that had enhanced safety (Cyclone, Ivory) and tools
like Softbound+CETS that automatically make code safe w/ a penalty. Use or
invest effort in such tools. And finally, if nothing else is available, use a
subset of C with sensible coding style and throw every bug-finding tool you
can at it.

Those are the recommendations in that order. What you use depends on your
domain, constraints, skills, and so on. Modula-2, Active Oberon, Modula-3,
Free Pascal, and Component Pascal were probably closest to C's domain in terms
of safe, efficient, easy-to-compile languages. Ada is systematic in all the
errors it handles but with steep, learning curve. SPARK straight up proves
your code. One can also use DSL's/4GL's that generate proper C w/ automated
checks like iMatix and Galois do (and I once did). I've also seen Ocaml and
LISP used for real-time, even embedded, systems with custom runtime. Ocaml was
also used for tooling w/ source to object code verification.

So, there's a number of options. Each are behind C currently in tooling due to
limited uptake and investment. More uptake and investment can fix that. Even
so, average results of those tools have far lower defects than C code with
shorter time to train people (ignoring Ada). That most teams aren't composed
of geniuses in safe coding means that's important too.

~~~
snaky
Add to the list ATS, combining features suited for low-level programming (and
C-level performance) and dependent types to make it safe.

~~~
nickpsecurity
ATS is interesting. I've seen it used in device drivers and one 8-bit system
IIRC. The reason I left it off is that I'm not sure most people can learn how
to use it. Whereas, we've taught ALGOL languages, Scheme, and Ocaml to all
kinds of people where they're effective enough with types & assertions.

These more mathematical languages have to prove themselves out with real-world
examples, algorithms and compiled code, before I recommend them. I'd like to
see CompSci keep hammering away at them to find easier and easier ways of
learning and using them. Not to mention improve tooling.

------
antirez
"Single address-space OS". Is this in order to support less advanced
processors without good memory protection support?

~~~
MrTonyD
I don't know their reasons...but virtual memory is generally non-
deterministic. In practice, when I did real time programming with C, we had to
empirically test for best case and worst case latencies, and then model our
code performance in order to make sure that it wouldn't kill people. Perhaps
if this is running on a processor with well defined instruction execution
timing (that doesn't describe most modern processors), they can get full
determinism.

~~~
Animats
Anything with caches is non-deterministic, although there is worst case
timing. Just because you have an MMU doesn't mean you have to have paging to
disk. Paging to disk is on the way out; few mobile devices do it. RAM is too
cheap.

~~~
nickpsecurity
There are caches that can be locked to aid determinism in certain operations.
Idk their limits but they're used in some real-time systems.

~~~
drewm1980
Yep. Are you referring to mlock? That's one way of keeping your data from
getting swapped out to disk when you know something the memory manager
doesn't.

~~~
vardump
No, he's referring to something that is not commonly available or used in
desktop systems. (I think some Intel CPUs might have it built in, but it's a
totally inaccessible feature).

"mlock" is about virtual memory manager "locking" physical pages, so they
can't be swapped out to disk.

Here were talking about systems that might not have a disk or even an MMU to
implement virtual memory. They might still have dedicated memory protection
units, but those aren't necessarily able to support memory virtualization, but
just simply to protect memory ranges in safety critical systems.

This is about ability to lock CPU caches (or parts of them, cache line
locking) to get something akin to scratchpad memory to ensure deterministic
memory access latencies.

For some applications there's a difference whether memory access takes 10 or
100 nanoseconds.

------
pc2g4d
Mission creep by the _Linux_ Foundation?

~~~
justincormack
They have lots of non Linux projects eg Xen
[http://collabprojects.linuxfoundation.org/#collaborative-
pro...](http://collabprojects.linuxfoundation.org/#collaborative-projects)

------
crudbug
Zephyr (Intel / NXP) / FreeRTOS / Brillo (Google) / mbed OS (ARM) / \- Lot of
noise in the IoT space.

~~~
joezydeco
I wouldn't lump FreeRTOS in with those others. I've shipped devices with it
and it's a real, tangible thing. mbed would be my next choice.

~~~
crudbug
Agreed I am using FreeRTOS Marvell 88MC200 [1].

[1]
[http://www.marvell.com/microcontrollers/88MC200/](http://www.marvell.com/microcontrollers/88MC200/)

------
tkinom
With today's multi-core soc, one can easily partition out one core for Zephyr.
Anything real time related can move to this RTOS on its own core.

This is great approach especially with Linux Foundation behind it.

I am curious on what kind of License will it be released under, GPL?

~~~
Sanddancer
Apache 2.0

~~~
tkinom
Nice and ....

Pro: Companies probably can hide IP in it.

Con: Companies likely to hide IP inside Binary BLOB inside it.

~~~
carussell
Con: there can be zero cross-pollination between Linux and Zephyr without
relicensing, because Apache 2.0 and GPLv2 are incompatible.

------
bluejekyll
It doesn't look like any libc is included. Which means it will probably be a
pain to port any other languages a libraries. Right?

------
ck2
I'm questioning the need towards 2020 for anything that is limited to 8kb of
memory? 8MB maybe, but 8KB ?

I am holding in my hand a device the size of a postage stamp (or full sized SD
card) that has 64MB of ram and 16MB of flash rom and supports eight
simultaneous wifi devices (the zsun usb adapter). It uses two chips to
accomplish this (Qualcomm MIPS cpu) and a third to support an external microsd
card.

[http://i.imgur.com/F8P40Uo.jpg](http://i.imgur.com/F8P40Uo.jpg)

The usb connector is almost larger than the board that holds the two chips.

~~~
rhinoceraptor
The less memory, the less chance of a memory error.

Less memory means less code, which means fewer bugs.

~~~
ck2
I'm all for efficiency, speed, and fewer bugs but isn't there a point where
you are trading actually useful features for size reduction?

