LWN: Comments on "Open source Zephyr Project aims to deliver an RTOS"

further export restrictions

micka — Thu, 25 Feb 2016 18:09:36 +0000

I'd argue I'm not subject to US export laws but to my own country (or actually, my own location) export laws, which may be very similar to US ones but may differ in some details (probably too subtle for me to spot).

further export restrictions

zmower — Thu, 25 Feb 2016 15:38:18 +0000

Yes, it still applies in other countries. See https://en.wikipedia.org/wiki/Export_Administration_Regul...

Open source Zephyr Project aims to deliver an RTOS

josh — Thu, 25 Feb 2016 06:53:58 +0000

FreeRTOS, however, doesn't actually have an Open Source license; it's a modified version of the GPL, and the modifications are non-free.

Open source Zephyr Project aims to deliver an RTOS

pabs — Thu, 25 Feb 2016 04:54:50 +0000

I guess you missed these LWN threads:

https://lwn.net/Articles/670676/
https://lwn.net/Articles/666369/
https://lwn.net/Articles/665739/
https://lwn.net/Articles/662313/

Open source Zephyr Project aims to deliver an RTOS

pjhacnau — Thu, 25 Feb 2016 03:26:45 +0000

Only the actual microkernel is GPL2; all of the libraries on top (which is what you actually build your system against) are 2-clause BSD.

Open source Zephyr Project aims to deliver an RTOS

rossburton — Thu, 25 Feb 2016 00:52:47 +0000

As has been pointed out in other threads here, when your deployment model is "link to the kernel directly to produce a single binary" the GPL is quite an extreme license and wouldn't let you write anything but GPL applications.

Open source Zephyr Project aims to deliver an RTOS

BlueLightning — Tue, 23 Feb 2016 17:23:56 +0000

> Yocto is what it is, but compared to simple embedded tools like OpenWRT, it is nowhere.

What does that mean exactly?

Open source Zephyr Project aims to deliver an RTOS

zoobab — Tue, 23 Feb 2016 10:36:24 +0000

Yocto is what it is, but compared to simple embedded tools like OpenWRT, it is nowhere.

Open source Zephyr Project aims to deliver an RTOS

david.brown@hesbynett.no — Tue, 23 Feb 2016 05:47:47 +0000

Yes, that's another way to do it. And there are a variety of other usable licenses, such as the MPL. But pure GPL is simply won't work for such a project.

Open source Zephyr Project aims to deliver an RTOS

BlueLightning — Tue, 23 Feb 2016 05:16:07 +0000

When you boil it down, the Yocto Project's primary activity is to develop the core of OpenEmbedded (and BitBake, which interprets and executes the OpenEmbedded metadata), providing a release structure around it, documentation, etc. When people talk about using Yocto Project tools they really mean using OpenEmbedded, even if they're unaware of it.

Open source Zephyr Project aims to deliver an RTOS

landley — Mon, 22 Feb 2016 20:59:48 +0000

I've never understood where Yocto fits between OpenEmbedded and Tizen, but you're right: that's lack of domain expertise on my part.

Open source Zephyr Project aims to deliver an RTOS

pizza — Mon, 22 Feb 2016 16:45:06 +0000

> If the RTOS is under the GPL, you must release the source code for your whole application.

Unless said RTOS provides an exception to the GPL to allow it:

(from http://www.freertos.org/license.txt)

"As a special exception, the copyright holders of FreeRTOS give you permission to
link FreeRTOS with independent modules to produce a statically linked
executable..."

Open source Zephyr Project aims to deliver an RTOS

david.brown@hesbynett.no — Mon, 22 Feb 2016 16:13:54 +0000

To my mind, this is a fairly pointless project - except as an advert for Wind River. There are already a range of embedded RTOS's under a variety of licenses and with a variety of features. This is just a "me too" RTOS - there is nothing outstanding about it. About the only thing that is impressive is how someone can come out with "new" RTOS that still seems to live in the world of C90. Once someone produces an RTOS that is at least built on C11's multi-threading and atomic features, but preferably built on C++14 with memory management handled by smart pointers and safe templates instead of outdated "void*" pointers everywhere, then we will have something /new/ to look at. Many people might not like it (because C++ is "scary" or "inefficient"), but no one can deny that it would be an interesting and new design.

Open source Zephyr Project aims to deliver an RTOS

david.brown@hesbynett.no — Mon, 22 Feb 2016 15:58:28 +0000

Look, it's quite simple. With an RTOS like Zephyr, you generate a single statically linked image combining your application code and the OS code. If the RTOS is under the GPL, you must release the source code for your whole application. (With the LGPL, you can get away with releasing linkable object code, but it is still a massive pain.) No one producing IoT devices is going to publicly release their source code, even when they are (in some cases) quite happy to release any changes to the OS code. So if Zephyr were under the GPL, it would be restricted to academics and hobby users - it would be a useless waste of time, and languish along with many other GPL'ed RTOS's that people have made.

Open source Zephyr Project aims to deliver an RTOS

SEJeff — Mon, 22 Feb 2016 13:36:55 +0000

http://m.youtube.com/watch?v=PaKIZ7gJlRU - Linus on gplv3

https://lkml.org/lkml/2006/9/25/161 - Linus again on the gplv3

I guess the LF hasn't made an official stance, but I'm curious as to which VMware instance you're talking about.

Open source Zephyr Project aims to deliver an RTOS

pabs — Mon, 22 Feb 2016 13:22:28 +0000

Their initial reaction to the VMware lawsuit suggests otherwise.

Open source Zephyr Project aims to deliver an RTOS

pabs — Mon, 22 Feb 2016 13:20:56 +0000

LF said nothing in public about funding SFC but LF stopped funding SFC after the GPL enforcement action against VMware (an LF member) in Germany was announced. LF recently started funding SFC again though. LF claim their membership changes were not aimed at blocking Karen (who works for SFC) from joining the LF board, but they did have that effect.

further export restrictions

micka — Mon, 22 Feb 2016 10:13:15 +0000

Does it apply once it's downloaded to any country other than USA ?
I'm in France. If I download this code, am I still subject to US export law ?

Open source Zephyr Project aims to deliver an RTOS

liam — Mon, 22 Feb 2016 00:20:12 +0000

Fair enough.
I was basing my answer on this paper (https://ssrg.nicta.com.au/publications/nictaabstracts/585...), but they didn't specify which kernel version, only that it was looking at sel4 after it had been verified.
What was striking to me was that they claimed that it would be nearly impossible to produce a complete analysis on most any fully preemptible rtos. My understanding was that such microkernels were designed with a guaranteed wcet, but you can only produce such a value of you can follow all possible execution paths... and, again, according to the paper, the fully preemptible rtos kernels are still hideously complex and full of bugs. Neither of those things lends itself well to analysis.

further export restrictions

JanC_ — Sun, 21 Feb 2016 21:11:58 +0000

Can somebody check if they block downloads from those countries? (Otherwise that statement is totally pointless as US export laws & copyright don't apply to downloaded code once it's in Iran, N-Korea, etc.)

BTW: if this is part of the licensing terms, it means this is not Open Source, right?

Open source Zephyr Project aims to deliver an RTOS

alonz — Sun, 21 Feb 2016 17:48:09 +0000

There are apparently some versions of seL4 that have bounded WCET (at least per the FAQ).
However, per the CAVEATS-generic.txt file in the open-source distribution, the GPL version is not a real-time kernel.

Open source Zephyr Project aims to deliver an RTOS

liam — Sun, 21 Feb 2016 10:37:31 +0000

It requires a MMU... which means it wouldn't fulfill the role needed by the Zephyr Project.
It is a real-time OS, however, even though it's not fully preemptible, because it has a bounded worst case path.

Open source Zephyr Project aims to deliver an RTOS

alonz — Sun, 21 Feb 2016 10:17:35 +0000

In addition to the earlier-mentioned concerns (/ snarks?), seL4 is not an RTOS.

Open source Zephyr Project aims to deliver an RTOS

k8to — Sat, 20 Feb 2016 16:49:28 +0000

RTOS must have bounded latency yes. A good RTOS aims to offer good numbers for all cases (best, expected, worst).

People playing in that specific space do things like single memory space and no MMU because doing so offers significant latency improvments in many primitive scenarios.

I do not really see the point of using an RTOS for most embedded devices though. 99.9% of embedded devices have no real RT requirement or component.

Open source Zephyr Project aims to deliver an RTOS

BlueLightning — Sat, 20 Feb 2016 01:30:19 +0000

The Yocto Project has never tried to be Android; however, numbers of companies who are not LF members have built their products using the tools it supports; it also has a healthy level of contribution from people from both LF member and non-LF member organisations. If you're suggesting that it hasn't succeeded or delivered any value then that would be flying in the face of the facts.

Open source Zephyr Project aims to deliver an RTOS

landley — Fri, 19 Feb 2016 22:21:34 +0000

Remember when somebody ported busybox to newlib+libgloss to run on "bare metal" and nobody really followed up? http://lists.busybox.net/pipermail/busybox/2005-March/047...

Remember when Red Hat bought an embedded company with its own OS, but nobody cared? http://ecos.sourceware.org/

Remember when symbian got open sourced, and nobody cared? https://gigaom.com/2010/10/28/symbian-a-lesson-on-the-wro...

Remember open source clones of DOS (http://www.freedos.org), windows (https://www.reactos.org), beos (https://www.haiku-os.org/)? Heck, I remember http://jos.sourceforge.net/ . Here's somebody who wrote their own lisp OS running on Raspberry Pi: http://interim.mntmn.com/ and here's Plan 9 running on Pi https://www.raspberrypi.org/forums/viewtopic.php?f=80&... and here's an entire COURSE on writing your own bare metal OS on raspberry pi: https://www.raspberrypi.org/blog/building-a-simple-raspbe...

Seriously, kolibri, tinyos, contiki, there is NO SHORTAGE of open source niche operating systems nobody actually uses. A schizophrenic wrote his own OS that spits out bible quotes at people because, and I quote, "God told him to": http://motherboard.vice.com/read/gods-lonely-programmer . There were already people writing articles asking people to stop writing new ones over a decade ago: http://www.osnews.com/story/8162/Why_you_Shouldn_t_Write_... (and there are still plenty of tutorials on how to do it, ala http://wiki.osdev.org/Tutorials and it's a FAQ on OS development sites ala http://stackoverflow.com/questions/3260095/writing-a-posi... .)

Seriously, the Linux Foundation saying there ISN'T an OS to fit a given niche is most likely a sign that the Linux Foundation does not know what it's talking about, or else an EPIC "not-invented-here" thing.

As for it succeeding _because_ the linux The Linux Foundation endorsed it, meego-maemo-moblin-yocto-tizen weren't android (or even firefoxos or ubuntuos, although sailfish picked up a fork of one _after_ the linux foundation's sponsor Nokia abandoned it because Microsoft bought them). The linux foundation endorsing a technology is probably a _negative_ signal about that technology, they're a large clueless bureaucracy following the money from their donor base.

Open source Zephyr Project aims to deliver an RTOS

jhhaller — Fri, 19 Feb 2016 22:16:31 +0000

While Wind River may have imported some VxWorks code over time, the base for this was actually from Virtuoso, a RTOS for DSP acquired with Eonic in 2001, and subsequently renamed VSPWorks. If one can believe Wikipedia, Virtuoso originated as part of the Transputer work. A more complete history can be found here.

further export restrictions

zoobab — Fri, 19 Feb 2016 21:24:47 +0000

"unmanned air vehicle systems" => so you can't use it inside drones.

further export restrictions

zoobab — Fri, 19 Feb 2016 21:23:35 +0000

What about the export restrictions to Iran for example, why can't contributors from Iran participate?:

https://www.zephyrproject.org/about/export-compliance

"EXPORT COMPLIANCE/CUSTOMS INFORMATION

By downloading the Zephyr Project, upstream source used to generate features or components, or any binaries generated by the Zephyr Project, you acknowledge that you understand all of the following:

The Zephyr Project, its component parts and technical information may be subject to the U.S. Export Administration Regulations (the “EAR”) and other U.S. and foreign laws and may not be exported, re-exported or transferred

(a) to any country listed in Country Group E:1 in Supplement No. 1 to part 740 of the EAR (currently, Iran, North Korea, Sudan & Syria);

(b) to any prohibited destination or to any end user who has been prohibited from participating in U.S. export transactions by any federal agency of the U.S. government; or

(c) for use in connection with the design, development or production of nuclear, chemical or biological weapons, or rocket systems, space launch vehicles, or sounding rockets, or unmanned air vehicle systems.

You may not download the Zephyr Project, its component parts and technical information if you are located in one of these countries or otherwise subject to these restrictions. You may not provide the Zephyr Project, its component parts and technical information to individuals or entities located in one of these countries or otherwise subject to these restrictions. You are also responsible for compliance with foreign law requirements applicable to the import, export and use of The Zephyr Project, its component parts and technical information.

The Zephyr Project is covered under a TSU exception. Its ECCN is 5D002TSU.
"

Open source Zephyr Project aims to deliver an RTOS

wsa — Fri, 19 Feb 2016 20:52:31 +0000

Let me help you: If you prefer a copyleft license, then the best non-copyleft license isn't going to make you happy.

Open source Zephyr Project aims to deliver an RTOS

SEJeff — Fri, 19 Feb 2016 20:01:26 +0000

The LF (and Linus from what I recall) don't like the GPLv3. The v2 is fine. I don't think Linus has any issues with the "tivo-ization" like things that the GPLv3 expressly prevents.

Open source Zephyr Project aims to deliver an RTOS

aaron — Fri, 19 Feb 2016 17:44:09 +0000

Good catch! Looks like Zephyr/Rocket is a "grandchild" of VXWorks.
Per http://linuxgizmos.com/wind-river-launches-helix-cloud-iot-platform-with-rocket-rtos-and-pulsar-linux/ :

Rocket appears to be based on, or is perhaps the new name for, the small-footprint, open source Viper RTOS derived from Wind River’s proprietary VxWorks RTOS.

If Broadcom and Atmel contribute their existing VXWorks NIC drivers, this could be mighty interesting for the open WiFi router community.

Vendor support and engineering familiarity is what makes Zephyr more than an "also-ran" to other open RTOSes.

Open source Zephyr Project aims to deliver an RTOS

xxiao — Fri, 19 Feb 2016 16:00:57 +0000

why not freertos, or contiki, or any thing that is open source and has a wide user space already? LF works for its members or who has the deep pocket these days, solely, under the name of open-source.

Open source Zephyr Project aims to deliver an RTOS

jeff@uclinux.org — Fri, 19 Feb 2016 15:59:24 +0000

Anyone looking for such a project, but wanting something ready for prime time and mature should look here: http://www.contiki-os.org

Or, as most of us do when we need a bootloader that has grown legs, aka tasking / threading framework, aka tiny RTOS kernel, just write a little scheduler and use one of Adam Dunkels IP stacks

https://en.m.wikipedia.org/wiki/UIP_(micro_IP)
https://en.m.wikipedia.org/wiki/LwIP

Open source Zephyr Project aims to deliver an RTOS

farnz — Fri, 19 Feb 2016 13:43:39 +0000

Exactly the same applies with any other RTOS, though (VxWorks, Nucleus, eCos, QNX). However, an RTOS guarantees that its primitives will give you bounds on latency; Linux does not. As a simplistic example, if an interrupt handler on Linux holds a lock over each packet it processes, Linux does not guarantee to let anyone else obtain the same lock, even though the interrupt handler unlocks after every packet, then locks again. An RTOS (inc RT Linux) bounds that behaviour, by guaranteeing that it is possible for another fiber to take that lock every time it's released - the interrupt handler only gets the lock again if nothing else of same or higher priority was waiting on it.

Open source Zephyr Project aims to deliver an RTOS

jpfrancois — Fri, 19 Feb 2016 13:09:31 +0000

Thank you for your clarification and definition.

In my experience, once you start writing your app, you will need locking at some point.
So the OS is not preventing you from writing locking code that works correctly with respect to your app, but it also leaves you all the work.

Your example of the linux device driver can be transposed to Zephyr : if you write a device driver using an interrupt + a fiber, and some locking to cooperate with other task needing the driver, then your latency might be unbounded, since you need cooperation from the fiber in order to get anything else scheduled.

Sure it's all your fault if your driver sucks. But then if you use Zephyr OS + some BSP code or some driver code because you can't reimplement everything, then you don't have any guarantee, until you carefully examine that code. Not very different from a "non real time os"

Open source Zephyr aims to deliver yet another embedded OS, with all the usual primitive...

Open source Zephyr Project aims to deliver an RTOS

farnz — Fri, 19 Feb 2016 10:52:42 +0000

Definitions matter when discussing this sort of thing; my baseline set (from my degree) are:

Batch: A batch system is one where the wall clock is irrelevant to the correctness of the system's operation, and where no human is required to supervise its operation. An example would be the kernel build system - you set it building, and you move onto something else.
Interactive: An interactive program is one where the wall clock is irrelevant to the correctness of the system's operation, but a human is expected to supervise its operation. It differs from a batch system in that long delays can cause operator upset; an example would be the kernel's configuration system.
Soft real time: A soft real time system is one where a failure to meet a wall clock deadline results in a transient failure of the system - however, it is possible for the system to exit the failure state by itself. An example is a conference recording system; miss deadlines, and you have to drop audio and/or video, but you can exit the failure state by meeting deadlines in future, resulting in an unrecoverable gap in the recording (the failure that moves this into real time, not interactive), but not a permanent fault after a deadline miss.
Hard real time: A hard real time system is one where a failure to meet a wall clock deadline results in the system entering a permanent failure state that it cannot exit. For example, a robot arm controller is hard real time - if it fails to stop the motors in time, the arm can crash into something else in the workspace and get stuck.

Note that there's overlap between hard and soft real time - an aircraft autopilot is soft real time when it's just maintaining cruising speed (the effect of delayed control is to run at the wrong speed for a period of time), but hard real time when it's reacting to a radar event in order to avoid crashing the plane.

With these definitions in place, an RTOS is an OS that guarantees that if you write your application to respect wall clock deadlines, no OS facility will prevent you from meeting them. Linux is not, by default, an RTOS, because internal locking means that a device interrupt can prevent your application from running for an arbitrary amount of time (the RT patchset aims to change this). At first glance, it looks like Zephyr meets this - all OS facilities that can take unbounded time are tasks themselves, and you can set task priorities to meet an arbitrary deadline.

And yes, any OS that provides guaranteed bounded latencies is an RTOS - if you have guaranteed bounds on OS latency, you can implement a hard real time system, as you can add delays if an OS latency is too low.

Open source Zephyr Project aims to deliver an RTOS

ortalo — Fri, 19 Feb 2016 09:29:14 +0000

I imagine a few things could be done to improve the situation over the current state of the "art" (especially for transparency and Ken Thomson inspired trust, but also around a few potential mitigation techniques).
However, I fully agree that this won't bring much more to the table in the end if IoT devices follow the current trend of "there's always too much security anyway".

Open source Zephyr Project aims to deliver an RTOS

ortalo — Fri, 19 Feb 2016 09:23:49 +0000

I have the same interrogations as you and I hope our editors will give some more coverage of the issue.
May I even suggest an interview? (After all, we have a lot of poisonous questions to ask.... :-)

Open source Zephyr Project aims to deliver an RTOS

jpfrancois — Fri, 19 Feb 2016 09:23:21 +0000

So any OS that is not general purpose gets to be called RTOS ? What exactly is an RTOS ? I fail to see the RT part in the overview.

You have Interrupt routines, Fiber, and Task.
Task are preemptible, with a priority based scheduling.
Fiber are not preemptible, priority based, but with a cooperative scheduling, ie your fiber will run until it schedules
Interrupt are interrupts.

So you get real time provided you design your application correctly. Any OS with bounded latency deserves to be called an RTOS then ?That's great, I have done real time apps without knowing it ...