1. 9

  2. 5

    It’s a nice write-up with lots of examples. The author seems to oversell the vendor lock-in part given lots of them have POSIX runtimes. Just write most of the code platform-neutral with platform stuff done in POSIX style. Lots of safety-critical uses ARM or PPC (i.e. Freescale) for simplicity of the CPU over x86’s baggage. Separate boards with RTOS’s and partitioning kernels are strongest solution since they make it easy to avoid problems by coupling or delays. If it’s security relevant, I always say go for full separation so unknown, hardware vectors don’t become a problem down the road. Throwing extra MCU’s or low-end CPU’s at the problem is much cheaper than the brains necessary to implement a separation paradigm on a machine designed for sharing. One can also use FPGA’s for safety-critical since they have isolation packages or recommendations available with determining timing an inherent part of hardware design.

    1. 1

      Not politically correct on lwn to mention rtlinux.

      1. 1

        I was waiting for them to start dropping names of various vendors the whole time I was reading it. The author didn’t drop names of any companies, though. That includes the real-time Linuxes, separation kernels, and so on. The rationale is stated in the categories where author believes they’re a problem for various reasons. Then, moves on to speculative, especially-FOSS solutions to solve those perceived problems.

        So, maybe author is being impractically idealistic instead of politically correct. In real world, we just use something that’s worked before which fits our needs. Those products are usually in the categories author is ignoring.

        1. 2

          It’s kind of amazing to see mention of RTLinux derivatives that don’t offer on modern systems as good a response time as what we got on 100MHz Pentiums in the 1990s.