Embedded Linux System Development Training
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Study of File System Evolution
Study of File System Evolution Swaminathan Sundararaman, Sriram Subramanian Department of Computer Science University of Wisconsin {swami, srirams} @cs.wisc.edu Abstract File systems have traditionally been a major area of file systems are typically developed and maintained by research and development. This is evident from the several programmer across the globe. At any point in existence of over 50 file systems of varying popularity time, for a file system, there are three to six active in the current version of the Linux kernel. They developers, ten to fifteen patch contributors but a single represent a complex subsystem of the kernel, with each maintainer. These people communicate through file system employing different strategies for tackling individual file system mailing lists [14, 16, 18] various issues. Although there are many file systems in submitting proposals for new features, enhancements, Linux, there has been no prior work (to the best of our reporting bugs, submitting and reviewing patches for knowledge) on understanding how file systems evolve. known bugs. The problems with the open source We believe that such information would be useful to the development approach is that all communication is file system community allowing developers to learn buried in the mailing list archives and aren’t easily from previous experiences. accessible to others. As a result when new file systems are developed they do not leverage past experience and This paper looks at six file systems (Ext2, Ext3, Ext4, could end up re-inventing the wheel. To make things JFS, ReiserFS, and XFS) from a historical perspective worse, people could typically end up doing the same (between kernel versions 1.0 to 2.6) to get an insight on mistakes as done in other file systems. -
CNTR: Lightweight OS Containers
CNTR: Lightweight OS Containers Jorg¨ Thalheim, Pramod Bhatotia Pedro Fonseca Baris Kasikci University of Edinburgh University of Washington University of Michigan Abstract fundamental to achieve high efficiency in virtualized datacenters and enables important use-cases, namely Container-based virtualization has become the de-facto just-in-time deployment of applications. Moreover, standard for deploying applications in data centers. containers significantly reduce operational costs through However, deployed containers frequently include a higher consolidation density and power minimization, wide-range of tools (e.g., debuggers) that are not required especially in multi-tenant environments. Because of all for applications in the common use-case, but they these advantages, it is no surprise that containers have seen are included for rare occasions such as in-production wide-spread adoption by industry, in many cases replacing debugging. As a consequence, containers are significantly altogether traditional virtualization solutions [17]. larger than necessary for the common case, thus increasing the build and deployment time. Despite being lightweight, deployed containers often include a wide-range of tools such as shells, editors, CNTR1 provides the performance benefits of lightweight coreutils, and package managers. These additional tools containers and the functionality of large containers by are usually not required for the application’s core function splitting the traditional container image into two parts: the — the common operational use-case — but they are “fat” image — containing the tools, and the “slim” image included for management, manual inspection, profiling, — containing the main application. At run-time, CNTR and debugging purposes [64]. In practice, this significantly allows the user to efficiently deploy the “slim” image and increases container size and, in turn, translates into then expand it with additional tools, when and if necessary, slower container deployment and inefficient datacenter by dynamically attaching the “fat” image. -
Linux on the Road
Linux on the Road Linux with Laptops, Notebooks, PDAs, Mobile Phones and Other Portable Devices Werner Heuser <wehe[AT]tuxmobil.org> Linux Mobile Edition Edition Version 3.22 TuxMobil Berlin Copyright © 2000-2011 Werner Heuser 2011-12-12 Revision History Revision 3.22 2011-12-12 Revised by: wh The address of the opensuse-mobile mailing list has been added, a section power management for graphics cards has been added, a short description of Intel's LinuxPowerTop project has been added, all references to Suspend2 have been changed to TuxOnIce, links to OpenSync and Funambol syncronization packages have been added, some notes about SSDs have been added, many URLs have been checked and some minor improvements have been made. Revision 3.21 2005-11-14 Revised by: wh Some more typos have been fixed. Revision 3.20 2005-11-14 Revised by: wh Some typos have been fixed. Revision 3.19 2005-11-14 Revised by: wh A link to keytouch has been added, minor changes have been made. Revision 3.18 2005-10-10 Revised by: wh Some URLs have been updated, spelling has been corrected, minor changes have been made. Revision 3.17.1 2005-09-28 Revised by: sh A technical and a language review have been performed by Sebastian Henschel. Numerous bugs have been fixed and many URLs have been updated. Revision 3.17 2005-08-28 Revised by: wh Some more tools added to external monitor/projector section, link to Zaurus Development with Damn Small Linux added to cross-compile section, some additions about acoustic management for hard disks added, references to X.org added to X11 sections, link to laptop-mode-tools added, some URLs updated, spelling cleaned, minor changes. -
Microkernel Mechanisms for Improving the Trustworthiness of Commodity Hardware
Microkernel Mechanisms for Improving the Trustworthiness of Commodity Hardware Yanyan Shen Submitted in fulfilment of the requirements for the degree of Doctor of Philosophy School of Computer Science and Engineering Faculty of Engineering March 2019 Thesis/Dissertation Sheet Surname/Family Name : Shen Given Name/s : Yanyan Abbreviation for degree as give in the University calendar : PhD Faculty : Faculty of Engineering School : School of Computer Science and Engineering Microkernel Mechanisms for Improving the Trustworthiness of Commodity Thesis Title : Hardware Abstract 350 words maximum: (PLEASE TYPE) The thesis presents microkernel-based software-implemented mechanisms for improving the trustworthiness of computer systems based on commercial off-the-shelf (COTS) hardware that can malfunction when the hardware is impacted by transient hardware faults. The hardware anomalies, if undetected, can cause data corruptions, system crashes, and security vulnerabilities, significantly undermining system dependability. Specifically, we adopt the single event upset (SEU) fault model and address transient CPU or memory faults. We take advantage of the functional correctness and isolation guarantee provided by the formally verified seL4 microkernel and hardware redundancy provided by multicore processors, design the redundant co-execution (RCoE) architecture that replicates a whole software system (including the microkernel) onto different CPU cores, and implement two variants, loosely-coupled redundant co-execution (LC-RCoE) and closely-coupled redundant co-execution (CC-RCoE), for the ARM and x86 architectures. RCoE treats each replica of the software system as a state machine and ensures that the replicas start from the same initial state, observe consistent inputs, perform equivalent state transitions, and thus produce consistent outputs during error-free executions. -
ECE 598 – Advanced Operating Systems Lecture 19
ECE 598 { Advanced Operating Systems Lecture 19 Vince Weaver http://web.eece.maine.edu/~vweaver [email protected] 7 April 2016 Announcements • Homework #7 was due • Homework #8 will be posted 1 Why use FAT over ext2? • FAT simpler, easy to code • FAT supported on all major OSes • ext2 faster, more robust filename and permissions 2 btrfs • B-tree fs (similar to a binary tree, but with pages full of leaves) • overwrite filesystem (overwite on modify) vs CoW • Copy on write. When write to a file, old data not overwritten. Since old data not over-written, crash recovery better Eventually old data garbage collected • Data in extents 3 • Copy-on-write • Forest of trees: { sub-volumes { extent-allocation { checksum tree { chunk device { reloc • On-line defragmentation • On-line volume growth 4 • Built-in RAID • Transparent compression • Snapshots • Checksums on data and meta-data • De-duplication • Cloning { can make an exact snapshot of file, copy-on- write different than link, different inodles but same blocks 5 Embedded • Designed to be small, simple, read-only? • romfs { 32 byte header (magic, size, checksum,name) { Repeating files (pointer to next [0 if none]), info, size, checksum, file name, file data • cramfs 6 ZFS Advanced OS from Sun/Oracle. Similar in idea to btrfs indirect still, not extent based? 7 ReFS Resilient FS, Microsoft's answer to brtfs and zfs 8 Networked File Systems • Allow a centralized file server to export a filesystem to multiple clients. • Provide file level access, not just raw blocks (NBD) • Clustered filesystems also exist, where multiple servers work in conjunction. -
Timesys Linux Install HOWTO
TimeSys Linux Install HOWTO Trevor Harmon <[email protected]> 2005−04−05 Revision History Revision 1.0 2005−04−05 Revised by: TH first official release This document is a quick−start guide for installing TimeSys Linux on a typical desktop workstation. TimeSys Linux Install HOWTO Table of Contents 1. Introduction.....................................................................................................................................................1 1.1. Background.......................................................................................................................................1 1.2. Copyright and License......................................................................................................................1 1.3. Disclaimer.........................................................................................................................................2 1.4. Feedback...........................................................................................................................................2 2. Requirements...................................................................................................................................................3 3. Install the packages.........................................................................................................................................4 4. Prepare the source directories.......................................................................................................................5 5. Configure -
Atomicity and Visibility in Tiny Embedded Systems
Atomicity and Visibility in Tiny Embedded Systems John Regehr Nathan Cooprider David Gay University of Utah, School of Computing Intel Research Berkeley {regehr, coop}@cs.utah.edu [email protected] Abstract bool flag = false; // interrupt handler Visibility is a property of a programming language’s void __vector_5 (void) memory model that determines when values stored by { one concurrent computation become visible to other atomic flag = true; computations. Our work exploits the insight that in } nesC, a C-like language with explicit atomicity, the traditional way of ensuring timely visibility—volatile void wait_for_interrupt(void) variables—can be entirely avoided. This is advan- { tageous because the volatile qualifier is a notorious bool done = false; do { source of programming errors and misunderstandings. atomic if (!flag) done = true; Furthermore, the volatile qualifier hurts performance } while (!done); by inhibiting many more optimizations than are neces- } sary to ensure visibility. In this paper we extend the semantics of nesC’s atomic statements to include a visi- bility guarantee, we show two ways that these semantics Figure 1. nesC code containing a visibility er- can be implemented, and we also show that our better ror implementation has no drawbacks in terms of resource usage. Until now, nesC has left it to programmers to en- 1. Introduction sure visibility by judicious use of C’s volatile qual- ifier. In this paper we investigate the idea of strength- ening nesC’s memory model such that the semantics of The nesC [5] language is a C dialect designed for pro- atomic are augmented with a visibility guarantee. This gramming embedded wireless sensor network nodes. -
Operating Systems and Applications for Embedded Systems >>> Toolchains
>>> Operating Systems And Applications For Embedded Systems >>> Toolchains Name: Mariusz Naumowicz Date: 31 sierpnia 2018 [~]$ _ [1/19] >>> Plan 1. Toolchain Toolchain Main component of GNU toolchain C library Finding a toolchain 2. crosstool-NG crosstool-NG Installing Anatomy of a toolchain Information about cross-compiler Configruation Most interesting features Sysroot Other tools POSIX functions AP [~]$ _ [2/19] >>> Toolchain A toolchain is the set of tools that compiles source code into executables that can run on your target device, and includes a compiler, a linker, and run-time libraries. [1. Toolchain]$ _ [3/19] >>> Main component of GNU toolchain * Binutils: A set of binary utilities including the assembler, and the linker, ld. It is available at http://www.gnu.org/software/binutils/. * GNU Compiler Collection (GCC): These are the compilers for C and other languages which, depending on the version of GCC, include C++, Objective-C, Objective-C++, Java, Fortran, Ada, and Go. They all use a common back-end which produces assembler code which is fed to the GNU assembler. It is available at http://gcc.gnu.org/. * C library: A standardized API based on the POSIX specification which is the principle interface to the operating system kernel from applications. There are several C libraries to consider, see the following section. [1. Toolchain]$ _ [4/19] >>> C library * glibc: Available at http://www.gnu.org/software/libc. It is the standard GNU C library. It is big and, until recently, not very configurable, but it is the most complete implementation of the POSIX API. * eglibc: Available at http://www.eglibc.org/home. -
OM-Cube Project
OM-Cube project V. Hiribarren, N. Marchand, N. Talfer [email protected] - [email protected] - [email protected] Abstract. The OM-Cube project is composed of several components like a minimal operating system, a multi- media player, a LCD display and an infra-red controller. They should be chosen to fit the hardware of an em- bedded system. Several other similar projects can provide information on the software that can be chosen. This paper aims to examine the different available tools to build the OM-Multimedia machine. The main purpose is to explore different ways to build an embedded system that fits the hardware and fulfills the project. 1 A Minimal Operating System The operating system is the core of the embedded system, and therefore should be chosen with care. Because of its popu- larity, a Linux based system seems the best choice, but other open systems exist and should be considered. After having elected a system, all unnecessary components may be removed to get a minimal operating system. 1.1 A Linux Operating System Using a Linux kernel has several advantages. As it’s a popular kernel, many drivers and documentation are available. Linux is an open source kernel; therefore it enables anyone to modify its sources and to recompile it. Using Linux in an embedded system requires adapting the kernel to the hardware and to the system needs. A simple method for building a Linux embed- ded system is to create a partition on a development host and to mount it on a temporary mount point. This partition is filled as one goes along and then, the final distribution is put on the target host [Fich02] [LFS]. -
Advanced Operating Systems #1
<Slides download> https://www.pf.is.s.u-tokyo.ac.jp/classes Advanced Operating Systems #2 Hiroyuki Chishiro Project Lecturer Department of Computer Science Graduate School of Information Science and Technology The University of Tokyo Room 007 Introduction of Myself • Name: Hiroyuki Chishiro • Project Lecturer at Kato Laboratory in December 2017 - Present. • Short Bibliography • Ph.D. at Keio University on March 2012 (Yamasaki Laboratory: Same as Prof. Kato). • JSPS Research Fellow (PD) in April 2012 – March 2014. • Research Associate at Keio University in April 2014 – March 2016. • Assistant Professor at Advanced Institute of Industrial Technology in April 2016 – November 2017. • Research Interests • Real-Time Systems • Operating Systems • Middleware • Trading Systems Course Plan • Multi-core Resource Management • Many-core Resource Management • GPU Resource Management • Virtual Machines • Distributed File Systems • High-performance Networking • Memory Management • Network on a Chip • Embedded Real-time OS • Device Drivers • Linux Kernel Schedule 1. 2018.9.28 Introduction + Linux Kernel (Kato) 2. 2018.10.5 Linux Kernel (Chishiro) 3. 2018.10.12 Linux Kernel (Kato) 4. 2018.10.19 Linux Kernel (Kato) 5. 2018.10.26 Linux Kernel (Kato) 6. 2018.11.2 Advanced Research (Chishiro) 7. 2018.11.9 Advanced Research (Chishiro) 8. 2018.11.16 (No Class) 9. 2018.11.23 (Holiday) 10. 2018.11.30 Advanced Research (Kato) 11. 2018.12.7 Advanced Research (Kato) 12. 2018.12.14 Advanced Research (Chishiro) 13. 2018.12.21 Linux Kernel 14. 2019.1.11 Linux Kernel 15. 2019.1.18 (No Class) 16. 2019.1.25 (No Class) Linux Kernel Introducing Synchronization /* The cases for Linux */ Acknowledgement: Prof. -
Securing Embedded Systems: Analyses of Modern Automotive Systems and Enabling Near-Real Time Dynamic Analysis
Securing Embedded Systems: Analyses of Modern Automotive Systems and Enabling Near-Real Time Dynamic Analysis Karl Koscher A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy University of Washington 2014 Reading Committee: Tadayoshi Kohno, Chair Gaetano Borriello Shwetak Patel Program Authorized to Offer Degree: Computer Science and Engineering © Copyright 2014 Karl Koscher University of Washington Abstract Securing Embedded Systems: From Analyses of Modern Automotive Systems to Enabling Dynamic Analysis Karl Koscher Chair of the Supervisory Committee: Associate Professor Tadayoshi Kohno Department of Computer Science and Engineering Today, our life is pervaded by computer systems embedded inside everyday products. These embedded systems are found in everything from cars to microwave ovens. These systems are becoming increasingly sophisticated and interconnected, both to each other and to the Internet. Unfortunately, it appears that the security implications of this complexity and connectivity have mostly been overlooked, even though ignoring security could have disastrous consequences; since embedded systems control much of our environment, compromised systems could be used to inflict physical harm. This work presents an analysis of security issues in embedded systems, including a comprehensive security analysis of modern automotive systems. We hypothesize that dynamic analysis tools would quickly discover many of the vulnerabilities we found. However, as we will discuss, there -
The Linux Device File-System
The Linux Device File-System Richard Gooch EMC Corporation [email protected] Abstract 1 Introduction All Unix systems provide access to hardware via de- vice drivers. These drivers need to provide entry points for user-space applications and system tools to access the hardware. Following the \everything is a file” philosophy of Unix, these entry points are ex- posed in the file name-space, and are called \device The Device File-System (devfs) provides a power- special files” or \device nodes". ful new device management mechanism for Linux. Unlike other existing and proposed device manage- This paper discusses how these device nodes are cre- ment schemes, it is powerful, flexible, scalable and ated and managed in conventional Unix systems and efficient. the limitations this scheme imposes. An alternative mechanism is then presented. It is an alternative to conventional disc-based char- acter and block special devices. Kernel device drivers can register devices by name rather than de- vice numbers, and these device entries will appear in the file-system automatically. 1.1 Device numbers Devfs provides an immediate benefit to system ad- ministrators, as it implements a device naming scheme which is more convenient for large systems Conventional Unix systems have the concept of a (providing a topology-based name-space) and small \device number". Each instance of a driver and systems (via a device-class based name-space) alike. hardware component is assigned a unique device number. Within the kernel, this device number is Device driver authors can benefit from devfs by used to refer to the hardware and driver instance.