It has a similar set of usage idioms to Hubris it looks like in terms of trying to setup as much as possible ahead of time to assemble what's kind of an application specific operating system where everything your use case needs is assembled at build-time as a bunch of communicating tasks running on seL4.
We recently added a concise little persistence interface that pulls in TicKV (https://docs.tockos.org/tickv/index.html) from the Tock project you referenced above, and some provisions are being added for some more dynamic task handling based on some asks from an automotive OEM.
Looks like a really cool idea to build on the formally verified C code and building everything else in Rust on top.
I defiantly think all the embedded Rust and even others will end up sharing lots of code.
I would like to spend some time working Datomic style on a more powerful immutable DB that could run on different KV interfaces. Lots of configuration should more immutable.
I'm not sure I understand the question exactly. I'm familiar with AUTOSAR (both "classic" and Adaptive) as well as with ISO 26262. Happy to answer, just not quite sure I fully understand the question.
I've seen this merger of AUTOSAR and MISRA C++ mentioned a bunch around the internet, but I haven't been able to find any details about the new standard anywhere.
Do you know where I could find more info? Have I just been looking in the wrong places?
Okay, just to clear up some potential confusion between us, and for any onlookers. You probably already know all this, but I'm just writing down the context through which I'm interpreting your question, so please bear with me for a moment...
MISRA and AUTOSAR are both consortiums in the automotive ecosystem. They're both industry standards bodies, not regulatory standards bodies (more like Khronos than ISO). The former worries mostly about defining best practices for convention and code style for primarily C and C++. The latter worries about defining a spec and interfaces for a middleware and application framework that's supposed to help automakers have a common portable (between MCUs) mechanism for developing, aggregating, and deploying ECU software. What's been merged from AUTOSAR to MISRA is basically AUTOSAR's codification of C++ subset and best practices into MISRA's version of C++ subset and best practices.
In the automotive world, the certification standard that ultimately matters is ISO 26262. It would be possible to write MISRA compliant code that still didn't qualify under ISO 26262 because of the process by which that code was developed. Likewise, it would be possible to have an AUTOSAR spec implementation that didn't qualify under ISO 26262 for similar reasons. It's also entirely possible to deploy software in cars that is neither MISRA compliant nor running on AUTOSAR. This is because ISO 26262 is 99% about process requirements and only about 1% technology prescription. Additionally, ISO 26262 is a self-certification regime almost everywhere in the world. It's a liability mitigation for when things eventually go wrong, not necessarily a direct regulatory hurdle that must be cleared. Lastly, ISO 26262 provides for the ability to offer evidence in support of deviations taken from the latest version of the standard's prescriptions and/or technology callouts.
Alright, now with all that out of the way...
With respect to seL4 and FerrOS. AUTOSAR Classic is for MCUs. seL4 and thus also FerrOS are not. They're for application processors. That said, it would be trivial to write FerrOS applications that could communicate over the protocols that are commonly defined for AUTOSAR Classic, so that you could have a FerrOS-built ECU interacting with the rest of your AUTOSAR-built ECUs. It would be likewise fairly trivial to create a basic HAL, carve out a slab of resources, and host an AUTOSAR Classic environment on one or more FerrOS tasks. It would just be kind of an odd thing to do given what kinds of things AUTOSAR Classic is used for and not entirely clear what the ultimate value would be. What I could imagine some day would be someone wanting to create an Adaptive AUTOSAR (a different AUTOSAR standard that's for higher-level applications and compute resources like ADAS and IVI) implementation atop something like seL4 via FerrOS (especially in the future when FerrOS supports bundling "applications" that aren't written in Rust).
As that relates to Rust in cars generally. That's a matter of risk tolerance and evidence investment. Rust has no ISO qualified toolchain, though Ferrous Systems has organized a project around a premise of getting Rust's development process, or some curated subset of it, to the point of producing the documentation and evidence of being so qualified. However, until that time it's incumbent on the user of the non-qualified toolchain to provide its certification evidence for the tools and technologies used. So, I expect for the companies who are dabbling in Rust, this is likely what they're planning on doing.
It has a similar set of usage idioms to Hubris it looks like in terms of trying to setup as much as possible ahead of time to assemble what's kind of an application specific operating system where everything your use case needs is assembled at build-time as a bunch of communicating tasks running on seL4.
We recently added a concise little persistence interface that pulls in TicKV (https://docs.tockos.org/tickv/index.html) from the Tock project you referenced above, and some provisions are being added for some more dynamic task handling based on some asks from an automotive OEM.
Also, sincerest h/t to the Tock folks.