3 ms·
> instead of having an operating system that knows how to dynamically create tasks at run-time (itself a hallmark of multiprogrammed, general purpose systems),
by throwaway894345 5y ago
> instead of having an operating system that knows how to dynamically create tasks at run-time (itself a hallmark of multiprogrammed, general purpose systems), Cliff had designed Hubris to fully specify the tasks for a particular application at build time, with the build system then combining the kernel with the selected tasks to yield a single (attestable!) image.
I worked briefly at John Deere, and their home-grown operating system (called "JDOS", written in C) also baked every application into the system at compile time. This was my only embedded experience, but I assumed this was somewhat common for embedded operating systems?
- stusmall 5y agoIt's been a long time since I've worked in that world but in the micro-controller world it is common.
- elcritch 5y agoYah it seems like they're conflating high level OS'es with low level RTOS'es. Perhaps comparing their OS to a general purpose OS while doing embedded / RTOS things. Take: > Precedence for the Hubris approach can be found in other systems like library operating systems, but there is an essential difference: Hubris is a memory-protected system, with tasks, the kernel, and drivers all in disjoint protection domains. It's great that the drivers run in a different memory domains. Still I'm not convinced this isn't that different from many RTOS'es. Zephyr RTOS which can do memory protected tasks and defines each task's stack statically.
- Matthias247 5y agoYeah, its common for RTOS. All the things in automotive (OSEK, Autosar) worked the same. And OS like Greenhills Integrity can also do full isolation between modules.