NetBSD Ported To Run On NVIDIA's Jetson TK1

[SystemCrasher]

Aside countless RTOS, plan9 is one of those operating systems, that are Lightweight enough for embedded applications.

In modern world, complete computer system capable of running REAL, FULL Linux kernel (i.e. 32-bit CPU with MMU and somesuch), can be SD-card sized or so these days. Then one gets all goodies you usually expect from decent, developed OS. Say, if SoC got USB port, you'll enjoy ALL devices supported. Need some strange L2TP over wi-fi? Some 3G internet? USB sound card? Okay, here it goes. Then it would run one of common httpds with web interface, allowing to create, say, device with web interface which is relatively easy to configure for customer. What advantages plan9 can offer, on other hand? A ton of headache with under-developed OS, using uncommon conceptions?

So you see, these days I'm using Linux in embedded designs. Because it allows me to take a decent system meant for real world fast, get all features I'm used to, and then achieve my goals in relatively painless ways and sane time frame. No royalty crap, no need to be super-huge-corp to complete task, etc. Just great.

As of systemd: systemd is one of those things that make linux unsuitable for embedded,

Blatant bullshit. As system engineer I'm really happy to have systemd on my side. Do you know what the hell watchdog is? In embedded, autonomous operation and fault tolerance is of a paramount importance. Because there is nobody to hit reset button, etc. It supposed to start and work once power applied and operate indefinitely from this point, as long as underlying hardware haven't failed.

Yet, it turned out systemd can offer a lot of goodies here.
1) Adequate handling of failed services. One can select what to do if critical service fails, which makes recovery easier.
2) Systemd can easily set up all stuff I need, be it realtime priority, OOM score, resource limits, priveleges, or whatver one can imagine related to process management. Say, I have "critical" events handler process, which is lightweight but MUST respond fast, otherwise it can miss real-world events, which is unacceptable. Then I have "background" process which does "heavy lifting" and is not time critical at all. With systemd I can configure all this as matter of few lines of config. The only alternate option would be to code my very own process starter, capable of about 70% systemd can do. Which is pointless waste of time once there is systemd.
3) Systemd is aware what watchdog is.
4) Systemd goes even further - you can have "watchdog tree". Systemd serves main hardware watchdog to prove it alive. Then it monitors processes who could be set up to report they're alive to systemd. And this facility saves me heck a lot of coding and reinventing wheels. Sure, I can code system monitoring and "mission control" stuff myself. But it would take me a lot of time and it is a big question if I can do it better. And how much features I'll have to add on the way.
5) If something goes wrong, systemd can, say invoke my handler so I can try to deal with issue.
6) If this fails as well, systemd can, say, force-reboot system without human supervision when some absolutely critical part has failed. And you can also set up OOM scoring, priority, IO priority and so on - "must have" for sensitive tasks.
7) If systemd fails as well, hardware watchdog would give hardware reboot. So it's a "watchdog tree". Sure, one have to patch their program a bit to deal with systemd's watchdog facility. But it only takes few lines of code, much less than coding comparable facility yourself.

In fact I'm really not in mood to rewrite of half of systemd myself to create "mission control", etc. Systemd already got reasonable at that. Maybe its not perfect, but it can save a day on many occasions. After all, RedHat is inclined on enterprises and they have serious requirements about reliability, autonomous operations and somesuch. Servers are somewhat similar to embedded in this regard. Nobody want to pay attentio to servers - they supposed to run with little to no supervision. Like embedded systems do. And systmed is quite configurable. I.e. if you're short on resources, you can chop many systemd components you do not need in particular task out of the way.

because systemd is anything but lightweight.

These days, credit-card sized or even smaller board/module can have 1-4 CPU cores at 1+ GHz, 0,5-2Gb RAM, 2-8l Gb NAND or eMMC/SD. So systemd wouldn't be major resources consumer for sure. This is only issue in smallest of systems, similar to those OpenWRT targets. And it can fit into SD-card sized device, with 4Mb flash and 16M RAM as bare minimum (32Mb would do better though).

Systemd may be suited for desktop PCs or Laptops, where i have a reset button i can press, if systemd hangs up the system.

If systemd itself would hang, hardware watchdog would reboot whole system unconditionally (as long as one who builds system image has configured this feature). Critical services could use systemd's watchdog facility - basically it's like a "shared watchdog". Idea is similar to hardware one - you have to ping watchdog facility every (configured amount of time). If this fails, service is restarted (and optionally, one can either invoke something to deal with it or just reboot system to deal with issue in radcal way, etc). It requires to write a bit of code for "sd notify", but it is really small compared to own monitoring and watchdog sharing code.

Absolutely wrong, aside bare-metal applications (those without kernel or OS), there are many real-time operating systems and microkernels around. The most secure Handy uses an L4 microkernel. There are also Microcontrollers, Linux cant run on, 8- and 16 bit for example.

The most fancy part is that these days even uCs are 32-bit. ARMs have seriously reshaped this with M-series. Cortex M0 and low end M3 is dirt cheap, yet beats 8 and 16 bit stuff any day. What is more fancy, Linux can support largest of Cortex M microcontrollers these days. Sure, they lack real MMU and so, system runs in somewhat limited mode. But its funny to see STM32 peripherals hitting mainline Linux tree - really not something one can readily expect. But Linux is THAT flexible - it can run even on microcontroller these days.

Yet, Linux is "relatively large" for microcntrollers and not really meant for "hard realtime". So it haves its limits. Yet, below these limits people usually use either no OS at all (bare metal, single task) or some small RTOS things like FreeRTOS. And these plan9 and L4 are mostly theoretic. They're theoretically sound... but good luck to ACTUALLY USE them. Come on. Show some actual devices runing them.

[nasyt]

And these plan9 and L4 are mostly theoretic. They're theoretically sound... but good luck to ACTUALLY USE them. Come on. Show some actual devices runing them.

As of for L4 i know an example:

http://security.t-systems.com/solutions/mobile-simko

With a swipe of the screen, users can switch between secure and open operating modes, e.g., when switching from reading a confidential message to viewing train or flight information. The L4 kernel makes sure that the open partition of the smartphone does not become a data security risk by hermetically sealing it off from the secure partition.
Users can use the open partition of their phone to download apps, use social media services and surf online freely. Programs for the device?s secure partition can be downloaded either from Deutsche Telekom?s secure app store or from customer servers.

[SystemCrasher]

As of for L4 i know an example:

TBH it mostly looks like marketing bullshit. In first place I do not like idea to protect device from user. If user can't access own data or someone external can dictate how to use data, it's DRM. And it only puts legitimate users at disadvantage and insecurity while it not really prevents malicious things (e.g. user can do photo of screen, taking sensitive data away regardless of anything). I consider DRM-like stuff evil and treacherous since it does not really solves any problems but creates many new troubles on other hand and requires to put multiple backdoors/anti-user "features" to system, being essentially opposite of security, actually. Then, I'm very well aware of fact that if attacker got physical access to device, there is no real way to prevent attacker doing arbitrary things in system, so if system can access data, you can count on attacker will eventually be able to do the same as well, subject to some time, efforts and money. There is only one thing which could work: encrypting all data AND keeping key OUTSIDE of device (e.g. strong passphrase inside of user's brain). In this case it could be possible to actually deny access to attacker if device lost, etc. However, it requires to ask passphrase on every access to protected data. Any key caching is a chance attacker would recover key as well and then collect rest of data. Basically, high-security things are very special area and at the end of day, reasonable security comes at serious price and inconvenience. This makes system design much costly and usability could drop considerably. Many use cases are simply not feasible. So all this mumbling about L4 is cool but from practical viewpoint it puts extra costs and complexities on development and maintenance while providing little to none advantages in most use cases. So it maybe will be used in some few uncommon applications. I do not really see where can I use L4 in my tasks. At the end of day, costs and development time matters and most of stuff I'm dealing with simply lacks strong security requirements. And when it comes to treachery like DRM I have no wish to deal with this filth at all.