DOCSLIB.ORG

What Are the Problems with Embedded Linux?

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

What Are the Problems with Embedded Linux? Every Operating System Has Benefits and Drawbacks Linux is ubiquitous. It runs most internet servers, is inside Android* smartphones, and is used on millions of embedded systems that, in the past, ran Real-Time Operating Systems (RTOSes). Linux can (and should) be used were possible for embedded projects, but while it gives you extreme choice, it also presents the risk of extreme complexity. What, then, are the trade-offs between embedded Linux and an RTOS? In this article, we cover some key considerations when evaluating Linux for a new development: ■ Design your system architecture first ■ What is Linux? ■ Linux vs. RTOSes ■ Free software is about liberty—not price ■ How much does Embedded Linux cost? ■ Why pay for Embedded Linux? ■ Should you buy Embedded Linux or roll-your-own (RYO)? ■ To fork or not to fork? ■ Software patching ■ Open source licensing ■ Making an informed decision The important thing is not whether Linux or an RTOS is “the best,” but whether either operating system—or both together—makes the most technical and financial sense for your project. We hope this article helps you make an informed decision. Design Your System Architecture First It is important to design your system architecture first—before choosing either Linux or an RTOS—because both choices can limit architectural freedom. You may discover that aspects of your design require neither Linux nor an RTOS, making your design a strong candidate for a heterogeneous approach that includes one or more bare-metal environments (with possibly a Linux and/or RTOS environment as well). You can learn more about heterogeneous design options and how to choose an RTOS by visiting our Learning Center. Questions to Ask When considering the software architecture for a new project, system architects need to ask themselves: ■ Am I willing to bring in resources to support the operating system layer of the software stack? ■ Are my areas of competitive differentiation, value add and core competency outside the operating sys- tem layer? ■ Are there open source applications available that can help accelerate my time to market? ■ Is it important to future proof this system (upgrade fielded systems)? ■ Do I have to pick Linux or an RTOS? Is the right path to use both? * Android is based on the Linux kernel, but does not use GNU components www.lynx.com | What Are the Problems with Embedded Linux? These questions are important when considering the total cost of ownership (TCO) of a Linux-based project vs. an RTOS-based one. There is no right choice based on the technology, only an optimal TCO choice given the required functionality and your team’s engineering expertise. If you answered yes to one or more of the questions above, then Linux could well be a great choice for you. This article discusses some of the key con- siderations to help you verify that path. Lynx Knows Linux Lynx Software Technologies loves Linux, as do many of our customers. In 2000, we created our own com- mercial embedded Linux distribution—BlueCat Linux—and at one point renamed ourselves LynuxWorks. Today, both Buildroot Linux and our RTOS—LynxOS-178®—are part of LYNX MOSA.ic™, our flagship product. LYNX MOSA.ic™ lets you build embedded systems by mixing embedded Linux, bare-metal, and real-time operating system (RTOS) environments (including competitive RTOSes) in order to balance open source software (OSS) functionality with real-time determinism. Lynx’s decades of experience building embedded Linux and our RTOS puts us in a great position to offer impartial advice about both. What is Linux? The Linux kernel is the largest open source software project in the history of computing, is immensely versa- tile and scalable, and has support for practically every device driver and protocol you can imagine. The term Linux is widely used incorrectly to mean a complete operating system, which should more correctly be called GNU/Linux. Linux is just the operating system kernel. While the kernel is an important component, it is only one component of hundreds needed to build a functional computer system—called a Linux distribu- tion. GNU stands for “GNU’s Not UNIX” and is a separate project started in 1985 by Richard Stallman under the Free Software Foundation with the aim of restoring the co-operative spirit that prevailed in the early days (1970s) of computing. GNU set out to build a complete UNIX-like operating system unencumbered by the restrictive licensing terms wrapped around most software of the day. By 1991, GNU had completed every component except their kernel, the year that, fortuitously Linus Torvalds publicly released his Linux kernel. Embedded Linux vs. Real-Time Operating Systems Linux and RTOSes are, in many senses, polar opposites. Comparisons can be divisive, focusing on technical or philosophical differences that “prove” one is better than the other. That is not our aim here. While there are big technical differences, Linux’s complexity, philosophy, and licensing properties are often overlooked and will have a profound impact on your embedded project, engineers and company. Planning and forethought are nec- essary to optimize your embedded project to utilize the strengths of both Linux and RTOSes and avoid nasty surprises. Generalizations About RTOSes Many RTOS vendors will discuss the size benefits of RTOSes compared with Linux, but while size is one consider- ation, smaller is not necessarily better. Every operating system is built to be as small as possible with the features necessary to satisfy its purpose. Instead of focusing on size, you should compare how much of your system’s complete functionality your RTOS or Linux can provide. While there will always be exceptions, in general, an RTOS will have: ■ A tiny memory footprint, down to 200 KB ■ Fast boot time, as fast as 100ms ■ Deterministic behavior (predictability you can bet your life on) ■ Modest range of middleware (about 50 items; USB, FS, SSL, SSH, IPv4, IPv6, SNMP, WiFi, web server, fire- wall, sound, graphics, CAN, etc). www.lynx.com | What Are the Problems with Embedded Linux? The crucial point is that your RTOS vendor coded the RTOS themselves, usually via their in-house engineer- ing department. This work may have been done over many years (probably decades ago), but the price pays for engineers coding the RTOS. This includes adding features, fixing bugs, and supporting new hardware. This is a coding paradigm; if you need to extend the RTOS, plan on writing code. Generalizations About Embedded Linux Dozens of embedded Linux distributions are available; semiconductor vendors routinely bundle Linux with their reference design boards, and commercial embedded Linux is available from Wind River, Montavista, Mentor, and others. Distribution builder tools are also available to help you build and customize your own embedded Linux distribution, with Buildroot and Yocto being the most popular. In general, embedded Linux will: ■ Have a modest memory footprint (down to 5MB) ■ Have a modest boot time (down to 2s) ■ Not be deterministic (responsive enough for music and voice, but not safety critical applications) ■ Include a generous range of middleware, 400-odd items The key point is that embedded Linux is assembled, not coded. Your distribution is built by integrating a few hundred community projects from a selection of 430,000†. This can be done “by hand” to create an RYO Linux distribution, by a commercial embedded Linux vendor, or by an open source framework like Buildroot or Yocto. When purchasing a commercial embedded Linux, the price pays to assemble, integrate, test, and maintain it. If you need to extend it, you will likely be integrating components rather than coding them. “Free” Software is About Liberty—Not Price Linux is freely available to download, but this is not why it is called “free”. The term free software is carefully and deliberately defined by the Free Software Foundation to mean software that respects user and com- munity rights. It means that the users have the freedom to run, copy, distribute, study, change and improve the software. You should think of “free” as in “free speech,” not as in “free beer”. The Four Essential Freedoms “A program is free software if the program’s users have the four essential freedoms: ■ The freedom to run the program as you wish, for any purpose (freedom 0). ■ The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this. ■ The freedom to redistribute copies so you can help others (freedom 2). ■ The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.” How Much Does Embedded Linux Cost? Both Linux and a handful of RTOSes are available at no cost, but that’s where the similarity ends. RTOSes have a reputation for being expensive—let’s say $100,000 per project—a cost that is well bounded and clear up front. Cost-wise, Linux can be deceptive. An embedded Linux system is more complex, more feature rich, and has more source lines of code (SLOC) than an RTOS-based system. Linux also has a vast community of projects of (generally but not always) high quality. Linux’s large codebase (both within your system, and available from the community) means that Linux’s complexity is almost unbounded. www.lynx.com | What Are the Problems with Embedded Linux? Without careful management, a Linux project can get out of control, for example hitting an unexpected problem that takes 6 months engineering time to resolve.
Recommended publications
  • An Event-Driven Embedded Operating System for Miniature Robots

    An Event-Driven Embedded Operating System for Miniature Robots

    This is a repository copy of OpenSwarm: an event-driven embedded operating system for miniature robots. White Rose Research Online URL for this paper: http://eprints.whiterose.ac.uk/110437/ Version: Accepted Version Proceedings Paper: Trenkwalder, S.M., Lopes, Y.K., Kolling, A. et al. (3 more authors) (2016) OpenSwarm: an event-driven embedded operating system for miniature robots. In: Proceedings of IROS 2016. 2016 IEEE/RSJ International Conference on Intelligent Robots and Systems, 09-14 Oct 2016, Daejeon, Korea. IEEE . ISBN 978-1-5090-3762-9 https://doi.org/10.1109/IROS.2016.7759660 © 2016 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other users, including reprinting/ republishing this material for advertising or promotional purposes, creating new collective works for resale or redistribution to servers or lists, or reuse of any copyrighted components of this work in other works. Reuse Items deposited in White Rose Research Online are protected by copyright, with all rights reserved unless indicated otherwise. They may be downloaded and/or printed for private study, or other acts as permitted by national copyright laws. The publisher or other rights holders may allow further reproduction and re-use of the full text version. This is indicated by the licence information on the White Rose Research Online record for the item. Takedown If you consider content in White Rose Research Online to be in breach of UK law, please notify us by emailing [email protected] including the URL of the record and the reason for the withdrawal request.
  • Co-Optimizing Performance and Memory Footprint Via Integrated CPU/GPU Memory Management, an Implementation on Autonomous Driving Platform

    Co-Optimizing Performance and Memory Footprint Via Integrated CPU/GPU Memory Management, an Implementation on Autonomous Driving Platform

    2020 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS) Co-Optimizing Performance and Memory Footprint Via Integrated CPU/GPU Memory Management, an Implementation on Autonomous Driving Platform Soroush Bateni*, Zhendong Wang*, Yuankun Zhu, Yang Hu, and Cong Liu The University of Texas at Dallas Abstract—Cutting-edge embedded system applications, such as launches the OpenVINO toolkit for the edge-based deep self-driving cars and unmanned drone software, are reliant on learning inference on its integrated HD GPUs [4]. integrated CPU/GPU platforms for their DNNs-driven workload, Despite the advantages in SWaP features presented by the such as perception and other highly parallel components. In this work, we set out to explore the hidden performance im- integrated CPU/GPU architecture, our community still lacks plication of GPU memory management methods of integrated an in-depth understanding of the architectural and system CPU/GPU architecture. Through a series of experiments on behaviors of integrated GPU when emerging autonomous and micro-benchmarks and real-world workloads, we find that the edge intelligence workloads are executed, particularly in multi- performance under different memory management methods may tasking fashion. Specifically, in this paper we set out to explore vary according to application characteristics. Based on this observation, we develop a performance model that can predict the performance implications exposed by various GPU memory system overhead for each memory management method based management (MM) methods of the integrated CPU/GPU on application characteristics. Guided by the performance model, architecture. The reason we focus on the performance impacts we further propose a runtime scheduler.
  • Performance Study of Real-Time Operating Systems for Internet Of

    Performance Study of Real-Time Operating Systems for Internet Of

    IET Software Research Article ISSN 1751-8806 Performance study of real-time operating Received on 11th April 2017 Revised 13th December 2017 systems for internet of things devices Accepted on 13th January 2018 E-First on 16th February 2018 doi: 10.1049/iet-sen.2017.0048 www.ietdl.org Rafael Raymundo Belleza1 , Edison Pignaton de Freitas1 1Institute of Informatics, Federal University of Rio Grande do Sul, Av. Bento Gonçalves, 9500, CP 15064, Porto Alegre CEP: 91501-970, Brazil E-mail: [email protected] Abstract: The development of constrained devices for the internet of things (IoT) presents lots of challenges to software developers who build applications on top of these devices. Many applications in this domain have severe non-functional requirements related to timing properties, which are important concerns that have to be handled. By using real-time operating systems (RTOSs), developers have greater productivity, as they provide native support for real-time properties handling. Some of the key points in the software development for IoT in these constrained devices, like task synchronisation and network communications, are already solved by this provided real-time support. However, different RTOSs offer different degrees of support to the different demanded real-time properties. Observing this aspect, this study presents a set of benchmark tests on the selected open source and proprietary RTOSs focused on the IoT. The benchmark results show that there is no clear winner, as each RTOS performs well at least on some criteria, but general conclusions can be drawn on the suitability of each of them according to their performance evaluation in the obtained results.
  • Our Tas Top 11 Technologies of the Decade Tinyos and Nesc Hardware Evolu On

    Our Tas Top 11 Technologies of the Decade Tinyos and Nesc Hardware Evolu On

    Our TAs Top 11 Technologies of the Decade Mo Sha Yong Fu 1.! Smartphones 7.! Drone Aircra • [email protected]" •! [email protected]" •! TinyOS tutorial." •! Grade critiques." 2.! Social Networking 8.! Planetary Rovers •! Help students with projects." •! Office Hour: by appointment." 3.! Voice over IP 9.! Flexible AC •! Manage motes." •! Bryan 502D Transmission •! Grade projects." 4.! LED Lighng •! Office Hour: Tue/Thu 5:30-6." 5.! Mul@core CPUs 10.!Digital Photography •! Bryan 502A 6.! Cloud Compung 11.!Class-D Audio Chenyang Lu 1 Chenyang Lu 2 TinyOS and nesC Hardware Evoluon ! TinyOS: OS for wireless sensor networks. ! Miniature devices manufactured economically ! nesC: programming language for TinyOS. ! Microprocessors ! Sensors/actuators ! Wireless chips 4.5’’X2.4’’ 1’’X1’’ 1 mm2 1 nm2 Chenyang Lu 4 Chenyang Lu 3 Mica2 Mote Hardware Constraints ! Processor ! Microcontroller: 7.4 MHz, 8 bit Severe constraints on power, size, and cost ! Memory: 4KB data, 128 KB program ! slow microprocessor ! Radio ! low-bandwidth radio ! Max 38.4 Kbps ! limited memory ! Sensors ! limited hardware parallelism CPU hit by many interrupts! ! Light, temperature, acceleraon, acous@c, magne@c… ! manage sleep modes in hardware components ! Power ! <1 week on two AA baeries in ac@ve mode ! >1 year baery life on sleep modes! Chenyang Lu 5 Chenyang Lu 6 Soware Challenges Tradional OS ! Small memory footprint ! Mul@-threaded ! Efficiency - power and processing ! Preemp@ve scheduling ! Concurrency-intensive operaons ! Threads: ! Diversity in applicaons & plaorm efficient modularity ! ready to run; ! Support reconfigurable hardware and soJware executing ! execu@ng on the CPU; ! wai@ng for data. gets CPU preempted needs data gets data ready waiting needs data Chenyang Lu 7 Chenyang Lu 8 Pros and Cons of Tradional OS Example: Preempve Priority Scheduling ! Each process has a fixed priority (1 highest); ! Mul@-threaded + preemp@ve scheduling ! P1: priority 1; P2: priority 2; P3: priority 3.
  • C-Style Strings

    C-Style Strings

    Introduction to printf and scanf A conceptual model of a C-string String handling functions in the C standard library String parsing functions Stuff to learn on your own C-Style Strings Mike Closson Dept of Computing Science University of Alberta Small modifications: Michael Buro Feb.2006 22nd February 2006 Mike Closson C-Style Strings Introduction to printf and scanf A conceptual model of a C-string String handling functions in the C standard library String parsing functions Stuff to learn on your own Introduction to printf, fprintf. Printing Strings: /* Print to standard output */ printf( "Hello, World!\n" ); /* Print to file associated with filepointer fp */ fprintf( fp, "Hello, World!\n" ); Mike Closson C-Style Strings Introduction to printf and scanf A conceptual model of a C-string String handling functions in the C standard library String parsing functions Stuff to learn on your own Flushing an I/O stream with fflush. For performance reasons, data written with the stream functions (fwrite, printf, fprintf) may not always appear on the terminal or file after the printf function returns. To force the data to be written, use the fflush function. printf("Enter your password: "); fflush( stdout ); Usually, fflush is not needed. Mike Closson C-Style Strings Introduction to printf and scanf A conceptual model of a C-string String handling functions in the C standard library String parsing functions Stuff to learn on your own Reading data with scanf. Data is written with printf, and data is read with scanf. char password[100]; printf( "Enter your password: " ); fflush( stdout ); if (scanf( "%99s", password ) != 1) // Error ..
  • Cheat Sheets of the C Standard Library

    Cheat Sheets of the C Standard Library

    Cheat Sheets of the C standard library Version 1.06 Last updated: 2012-11-28 About This document is a set of quick reference sheets (or ‘cheat sheets’) of the ANSI C standard library. It contains function and macro declarations in every header of the library, as well as notes about their usage. This document covers C++, but does not cover the C99 or C11 standard. A few non-ANSI-standard functions, if they are interesting enough, are also included. Style used in this document Function names, prototypes and their parameters are in monospace. Remarks of functions and parameters are marked italic and enclosed in ‘/*’ and ‘*/’ like C comments. Data types, whether they are built-in types or provided by the C standard library, are also marked in monospace. Types of parameters and return types are in bold. Type modifiers, like ‘const’ and ‘unsigned’, have smaller font sizes in order to save space. Macro constants are marked using proportional typeface, uppercase, and no italics, LIKE_THIS_ONE. One exception is L_tmpnum, which is the constant that uses lowercase letters. Example: int system ( const char * command ); /* system: The value returned depends on the running environment. Usually 0 when executing successfully. If command == NULL, system returns whether the command processor exists (0 if not). */ License Copyright © 2011 Kang-Che “Explorer” Sung (宋岡哲 <explorer09 @ gmail.com>) This work is licensed under the Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/ . When copying and distributing this document, I advise you to keep this notice and the references section below with your copies, as a way to acknowledging all the sources I referenced.
  • Building for I.MX Mature Boards

    Building for I.MX Mature Boards

    NXP Semiconductors Document Number: AN12024 Application Notes Rev. 0 , 07/2017 Building for i.MX Mature Boards 1. Introduction Contents The software for mature i.MX boards is upstreamed into 1. Introduction ........................................................................ 1 the Linux Kernel and U-Boot communities. These 2. Mature SoC Software Status .............................................. 2 boards can use the current Linux Kernel and U-Boot 3. Further Assistance .............................................................. 2 4. Boards Supported by the Yocto Project Community ......... 2 community solution. NXP no longer provides code and 4.1. Build environment setup ......................................... 3 images for these boards directly. This document 4.2. Examples ................................................................ 3 describes how to build the current Linux kernel and U- Boot software using the community solution for mature boards. The i.MX Board Support Packages (BSP) Releases are only supported for one year after the release date, so developing mature SoC projects using community solutions provides more current software and longer life for software than using the static BSPs provided by NXP. Community software includes upstreamed patches that the i.MX development team has provided to the community after the BSPs were released. Peripherals on i.MX mature boards such as the VPU and GPU, which depend on proprietary software, might be limited to an earlier version of the i.MX BSP. Supported i.MX reference boards should use the latest released i.MX BSPs on i.MX Software and Tools. Community solutions are not formally validated for i.MX. © 2017 NXP B.V. Boards Supported by the Yocto Project Community 2. Mature SoC Software Status The following i.MX mature SoC boards are from the i.MX 2X, 3X, and 5X families.
  • Confine: Automated System Call Policy Generation for Container

    Confine: Automated System Call Policy Generation for Container

    Confine: Automated System Call Policy Generation for Container Attack Surface Reduction Seyedhamed Ghavamnia Tapti Palit Azzedine Benameur Stony Brook University Stony Brook University Cloudhawk.io Michalis Polychronakis Stony Brook University Abstract The performance gains of containers, however, come to the Reducing the attack surface of the OS kernel is a promising expense of weaker isolation compared to VMs. Isolation be- defense-in-depth approach for mitigating the fragile isola- tween containers running on the same host is enforced purely in tion guarantees of container environments. In contrast to software by the underlying OS kernel. Therefore, adversaries hypervisor-based systems, malicious containers can exploit who have access to a container on a third-party host can exploit vulnerabilities in the underlying kernel to fully compromise kernel vulnerabilities to escalate their privileges and fully com- the host and all other containers running on it. Previous con- promise the host (and all the other containers running on it). tainer attack surface reduction efforts have relied on dynamic The trusted computing base in container environments analysis and training using realistic workloads to limit the essentially comprises the entire kernel, and thus all its set of system calls exposed to containers. These approaches, entry points become part of the attack surface exposed to however, do not capture exhaustively all the code that can potentially malicious containers. Despite the use of strict potentially be needed by future workloads or rare runtime software isolation mechanisms provided by the OS, such as conditions, and are thus not appropriate as a generic solution. capabilities [1] and namespaces [18], a malicious tenant can Aiming to provide a practical solution for the protection leverage kernel vulnerabilities to bypass them.
  • Openprinting Plenary

    Openprinting Plenary

    OpenPrinting Plenary Till Kamppeter, OpenPrinting IPP Everywhere under Linux – Driverless Printing · Support completely implemented: cups-filters: gstoraster/pdftoraster turns PDF into PWG Raster to send to IPP Everywhere printer, rastertopdf accepts PWG Raster as input for CUPS queue to emulate IPP Everywhere printer cups-browsed: If activated IPP Everywhere printers are discovered and a queue auto-generated, even with PPD file (PPD generator taken from CUPS 2.1.x, experimental) Ghostscript: PWG Raster format can be generated via “pwgraster” device or via “cups” device and MediaClass “PwgRaster” Printing stack of Level 2 is enough · Ubuntu Vivid (15.04) contains all this and therefore should fully support IPP Everywhere · Backport to Ubuntu Trusty (14.04 LTS) planned, but we need testing by manufacturers first · NEEDED: Testing all this by printer manufacturers, so please take Ubuntu 15.04 and test with your printers 2 Mobile Printing · Printing stack ready for mobile: cupsd and cups-browsed can be run on-demand, with systemd (most modern distros, incl. Ubuntu 15.04) or Upstart (Ubuntu Phone) Packaging of printing stack in three levels, level 2 for mobile, level 3 for desktop, server can be level 2 (appliance) or level 3 (computer) Printing stack is same software for mobile and desktop, so convergence (connect mobile phone to monitor to get desktop) is easy · MISSING: Mobile print dialog, but will be implemented soon for Ubuntu Mobile · Nice to have: Lightweight renderer like MuPDF 3 cups-filters · Most important changes: Create
  • Sysvinit / Upstart / Systemd

    Sysvinit / Upstart / Systemd

    SysVinit / Upstart / Systemd Zahemszky Gábor mérnök tanácsadó Zahemszky Gábor SysVinit / Upstart / Systemd init? ● Mire jó? ● Mire nem jó? ● Mi lenne, ha … (kávét főzne, kitakarítana, betakarítana, észlelné a bekapcsolt BT-fejhallgatót, a bedugot mobildiszket ...) Zahemszky Gábor SysVinit / Upstart / Systemd Ki mit használ jelenleg? Debian SysVinit Fedora Systemd OpenSUSE Systemd RHEL5 SysVinit RHEL6 Upstart SLES 10/11 SysVinit Ubuntu Upstart Többi? Kit érdekel? SysVinit Zahemszky Gábor SysVinit / Upstart / Systemd Előnyei ● Egyszerű maga az eszköz ● Egyszerűek az elindítot parancsfájlok ● Egyszerű a használt könyvtárstruktúra Zahemszky Gábor SysVinit / Upstart / Systemd Hátrányai ● Nem is annyira egyszerűek a parancsfájlok ● Mi van, ha az elindítot szerviz meghal? ● Miért fusson minden mindig, akkor is, ha csak ritkán akarjuk használni? Zahemszky Gábor SysVinit / Upstart / Systemd Mi a megoldás a problémákra? ● Bonyolítsuk el az egyszerű programot! ● Dobjuk ki az egyszerű scripteket! ● Strukturáljuk át az ismert, szabványosítot (LFS FHS) felépítésű fájlrendszert! Upstart Zahemszky Gábor SysVinit / Upstart / Systemd Upstart ● „Eseményvezérelt init-helyetesítő, amelynél a feladatok (task) és szolgáltatások (service) események (event) hatására indulnak el és állnak le” (*) ● Ellenben a feladatok és események elindítása / leállása más eseményeket generálhat ● Un. job segítségével mondhatjuk meg mi, merre, hány méter (mi, hogyan induljon/álljon le) ● Vezérlésre az initctl parancs szolgál (*) lásd upstart.ubuntu.com Zahemszky Gábor SysVinit
  • Nixos: a Purely Functional Linux Distribution

    Nixos: a Purely Functional Linux Distribution

    NixOS: A Purely Functional Linux Distribution Eelco Dolstra Andres Loh¨ Delft University of Technology, The Netherlands Utrecht University, The Netherlands [email protected] [email protected] Abstract change after they have been built; rather, the system is updated to Existing package and system configuration management tools suf- a new configuration by changing the specification and rebuilding fer from an imperative model, where system administration actions the system from it. This allows a system to be built determinis- such as upgrading packages or changes to system configuration tically, and therefore reproducibly. It allows the user to roll back files are stateful: they destructively update the state of the sys- the system to previous configurations, since previous configura- tem. This leads to many problems, such as the inability to roll back tions are not overwritten. Perhaps most importantly, statelessness changes easily, to run multiple versions of a package side-by-side, makes configuration actions predictable: they do not mysteriously to reproduce a configuration deterministically on another machine, fail because of some unknown aspect of the state of the system. or to reliably upgrade a system. In this paper we show that we can We have previously shown how package management — the overcome these problems by moving to a purely functional system installation and management of software packages — can be done configuration model. This means that all static parts of a system in a purely functional way, in contrast to the imperative models (such as software packages, configuration files and system startup of conventional tools such as RPM (Foster-Johnson 2003).
  • Timing Comparison of the Real-Time Operating Systems for Small Microcontrollers

    Timing Comparison of the Real-Time Operating Systems for Small Microcontrollers

    S S symmetry Article Timing Comparison of the Real-Time Operating Systems for Small Microcontrollers Ioan Ungurean 1,2 1 Faculty of Electrical Engineering and Computer Science; Stefan cel Mare University of Suceava, 720229 Suceava, Romania; [email protected] 2 MANSiD Integrated Center, Stefan cel Mare University, 720229 Suceava, Romania Received: 9 March 2020; Accepted: 1 April 2020; Published: 8 April 2020 Abstract: In automatic systems used in the control and monitoring of industrial processes, fieldbuses with specific real-time requirements are used. Often, the sensors are connected to these fieldbuses through embedded systems, which also have real-time features specific to the industrial environment in which it operates. The embedded operating systems are very important in the design and development of embedded systems. A distinct class of these operating systems is real-time operating systems (RTOSs) that can be used to develop embedded systems, which have hard and/or soft real-time requirements on small microcontrollers (MCUs). RTOSs offer the basic support for developing embedded systems with applicability in a wide range of fields such as data acquisition, internet of things, data compression, pattern recognition, diversity, similarity, symmetry, and so on. The RTOSs provide basic services for multitasking applications with deterministic behavior on MCUs. The services provided by the RTOSs are task management and inter-task synchronization and communication. The selection of the RTOS is very important in the development of the embedded system with real-time requirements and it must be based on the latency in the handling of the critical operations triggered by internal or external events, predictability/determinism in the execution of the RTOS primitives, license costs, and memory footprint.