DOCSLIB.ORG

OS Perspective on Android

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
OS Perspective on Android OS Perspective on Android David E. Culler CS162 – Operating Systems and Systems Programming http://cs162.eecs.berkeley.edu/ Lecture 27 December 5, 2019 cs162 Recall: What is an operating system? • Special layer oF soFtware that provides application soFtware access to hardware resources – Convenient abstraction of complex hardware devices – Protected access to Shared resources – Security and Authentication – Communication amongst logical entities appln appln appln OS Hardware 12/5/19 UCB CS162 Fa19 L27 2 In OS news this term … 12/5/19 UCB CS162 Fa19 L27 3 State oF things • Pixel 4 shipped in Oct 2019 with Linux kernel 4.14, an LTS release from November 2017 and will be stuck there – “Thanks to kernel updates never happening, this means every new release of Android usually has to support the last three years of LTS (Long Term Support) kernel releases (the minimum for Android 10 is 4.9, a 2016 release). – it is still supporting kernel 3.18, which is five years old now. • Linux Kernel 5.4 mainline 11/25/2019 12/5/19 UCB CS162 Fa19 L27 4 But, what do you think ? • What direction will the Future of Linux take? • We have seen so many of the enhancements driven by the needs of the cloud – Proportional share scheduling – Cgroups / Containers – KVM – paravirtualization For virtual machines – Concurrency support – Journaling file system • Versus single-user small form factor android experience • Will software engineering aspects of THE most common platForm dictate? 12/5/19 UCB CS162 Fa19 L27 5 The System “stack” you now know Application runtime User libc subsystems process ctrl syscall handlers scheduler mem mgmt syscall tbl intrpt handlers Kernel file sys intr tbl networking Page Tables user / grp Drivers regs Processor Memory Devices Hardware • /dev 12/5/19 UCB CS162 Fa19 L27 6 What’s in Android ? • Tiers of the Android system architecture • Linux kernel is the part at the bottom – How is Linux used? – How is it extended for this setting? – What matters in the OS? • What OS Functionality is outside the kernel? • How do the demands on it difFer? https://source.android.com/devices/architecture 12/5/19 UCB CS162 Fa19 L27 7 A somewhat diFFerent picture • Kernel provides process &mem mgmt., File system, & Drivers – Does not run Linux binaries – No libc – Syscalls ? • Single “user” => UID per App – In security sandbox + VM • DiFFerent user navigation experience – Threaded thru Apps • “Binder” IPC is the key 12/5/19 UCB CS162 Fa19 L27 8 THE User (you) vs UID • Underlying Linux is multi-user • Each Android App is assigned a distinct Linux UID – Permissions per App – By default, only the App can access its files (User permissions) • Each App runs as its own Linux process* – Android starts the process whenever any of the App’s components need to be executed – Not just main() or when you click on its icon, but … • Each process has its own VM – Like JVM, not “OS virtual machine”. Bytecode interpreter. – Dalvik VM => Android Run Time (ART) * Can arrange for multiple Apps to share UID, but they also run as one process, share the same VM. Must be signed with same certificate 12/5/19 UCB CS162 Fa19 L27 9 The Android Mantra • “The mobile-app experience diFFers From its desktop counterpart in that a user's interaction with the app doesn't always begin in the same place. Instead, the user journey often begins non-deterministically.” • The user experience threads through various apps, each potentially in direct interaction along the way – taking over the entire small screen • Apps build on the Functionality in others • A more cooperative ecosystem … hmm 12/5/19 UCB CS162 Fa19 L27 10 Components oF Android App User Interactions Activities APP Services Broadcast Receivers Providers Content System • Not just exec main() and syscall … • Lots of entry points (call backs) • Process started “whenever needed” 12/5/19 UCB CS162 Fa19 L27 11 App Components / Entry Points • Activities – Entry point for interacting with the User. – Represents a single screen with a user interface • Services – Run in the background. No user interface • Content Providers – Entry point for publishing named data items, identified by URI scheme – Manages shared App data that can be stored in file system, SQLite, on the Web, or on any accessible persistent storage • Broadcast Receivers – Entry point for system events. Outside regular App flow 12/5/19 UCB CS162 Fa19 L27 12 “The Operating System ?” • The Syscalls Recall: A Kind of Narrow Waist • The processor/mem Word ProcessinG Compilers Web Browsers resources delivered to Email Web Servers processes and threads via Databases Application / Service Portable OS Library OS scheduling User System Call Interface System • The hardware resources Portable OS Kernel supporting high level Software Platform support, Device Drivers Hardware x86 PowerPC ARM abstractions via drivers, PCI file systems, etc. Ethernet (10/100/1000) 802.11 a/b/G/n SCSI IDE Graphics • The system libraries (libc) 9/12/19 cs162 fa19 L5 23 • The system utility apps – bash, ps, top, … • The convention For utilizing file structure – /etc, /proc, /bin, … 12/5/19 UCB CS162 Fa19 L27 13 Extending the OS w/o new syscalls ? Application runtime open /dev/subsys read, write, ioctl on fd User libc subsystems process ctrl syscall handlers scheduler mem mgmt syscall tbl intrpt handlers Kernel file sys intr tbl networking Page Tables user / grp Drivers regs Processor Memory Devices Hardware • Drivers - add modules to kernel that communicate with user process thru file descriptor ops 12/5/19 UCB CS162 Fa19 L27 14 Closed Hardware • Primarily ARM, ARM64 • x86 & x86_64 – but only the microprocessor, not the x86 peripherals that intrinsic to PCs, Laptops, and Servers • Audio, Camera, Graphics, WiFi, GPS, Flash, Power management • No paging, no HDDs, no external busses, … 12/5/19 UCB CS162 Fa19 L27 15 The Linux Kernel – Major Changes • Binder – Android SpeciFic IPC / RPC mechanism – THE key to the entire application Framework • ashmem - Anonymous (or Android) Shared Memory – driver-based augment mmap (replace shmat) for small memory & extensive process sharing • PMEM – process memory allocator – Large physically contiguous memory blocks mapped into user space • logger – system logging Facility • wakelocks – User-controlled means of controlling whether system enters low-power states and what wakes it up • Out-of-memory handling – Kill processes under low memory conditions • Paranoid networking – restrict I/O to certain proc’s • Alarm timers, Timed gpio from user space • yafFs2 Flash File system, … https://elinux.org/Android_Kernel_Features Android Systems Programming 12/5/19 UCB CS162 Fa19 L27 16 ashmem (“/dev/ashmem”, O_RDWR) Application open ioctl on fd to set name and size runtime mmap on fd to establish region User ??? subsystems process ctrl syscall handlers scheduler mem mgmt syscall tbl intrpt handlers Kernel file sys intr tbl networking Page Tables user / grp Drivers regs Processor Memory Devices Hardware • Named regions known independent oF Fork/exec • ReFerence counted, clean up, low mem reclaim 12/5/19 UCB CS162 Fa19 L27 17 Bionic – the glibc replacement • Design philosophy – KEEP IT REALLY SIMPLE – Lightweight wrapper around kernel facilities • BSD libc + Linux-speciFic bits (w/o GPL) – Threads, process, signals, and bit more • pthread bundled in, not separate – Based on futexes – very short code paths in common case – Only implements simple, most useful parts » No process-shared mutex or CV, read/write locks,, pthread_cancel, … » Limited thread-local storage – pthread_mutex_t and pthread_cond_t are only 4 bytes • No multicore support • No sysV IPC, semaphores, shared memory segments, message queues, … 12/5/19 UCB CS162 Fa19 L27 18 Aside: Linux FUTEX • Kernel does not provide lock/unlock syscall • Locks are implemented as eFFicient (eg. test-and- test-and-set) spin-locks at user level using atomic hardware primitives – Common case: grab an uncontended lock – make it fast – Restructure app if it is not common (e.g., ticket locks) • But don’t spin long holding the CPU when other thread is holding the lock – Syscall traps to the kernel until a certain condition becomes true, i.e. a change occurs that might free the lock • FUTEX is not exposed in libc, it is used within pthread implementation • Three states for lock implementation – Free, busy-no-waiters, busy-waiters (why ?) 12/5/19 UCB CS162 Fa19 L27 19 FUTEX cont #include <linux/futex.h> #include <sys/time.h> int futex(int *uaddr, int futex_op, int val, const struct timespec *timeout ); • uaddr points to a 32-bit value in user space – placed in region of shared memory, w/I process or created using mmap(2) or shmat(2) across processes • futex_op – FUTEX_WAIT – if val == *uadder sleep till FUTEX_WAIT » Atomic check that condition still holds – FUTEX_WAKE – wake up at most val waiting threads – FUTEX_FD, FUTEX_WAKE_OP, FUTEX_CMP_REQUEUE • timeout – ptr to a timespec structure that specifies a timeout for the op 12/5/19 UCB CS162 Fa19 L27 20 Adjusting the OS/User contract Application runtime User libc Lock Object subsystems process ctrl syscall handlers scheduler mem mgmt syscall tbl intrpt handlers Kernel file sys intr tbl networking Page Tables user / grp Drivers regs Processor Memory Devices Hardware • User level deals with locks & synch • OS mantains thread waiters list & schedules 12/5/19 UCB CS162 Fa19 L27 21 Android-SpeciFic Features in its Linux • System Properties: Key/Value store shared by all processes – Like windows “registry” – Alternate to /proc, /etc . • User/Group management – No /etc/passwd or /etc/groups – groups used
Load more

Recommended publications
  • Efficient Inter-Core Communications on Manycore Machines
    ZIMP: Efficient Inter-core Communications on Manycore Machines Pierre-Louis Aublin Sonia Ben Mokhtar Gilles Muller Vivien Quema´ Grenoble University CNRS - LIRIS INRIA CNRS - LIG Abstract—Modern computers have an increasing num- nication mechanisms enabling both one-to-one and one- ber of cores and, as exemplified by the recent Barrelfish to-many communications. Current operating systems operating system, the software they execute increasingly provide various inter-core communication mechanisms. resembles distributed, message-passing systems. To sup- port this evolution, there is a need for very efficient However it is not clear yet how these mechanisms be- inter-core communication mechanisms. Current operat- have on manycore processors, especially when messages ing systems provide various inter-core communication are intended to many recipient cores. mechanisms, but it is not clear yet how they behave In this report, we study seven communication mech- on manycore processors. In this report, we study seven anisms, which are considered state-of-the-art. More mechanisms, that are considered state-of-the-art. We show that these mechanisms have two main drawbacks that precisely, we study TCP, UDP and Unix domain sock- limit their efficiency: they perform costly memory copy ets, pipes, IPC and POSIX message queues. These operations and they do not provide efficient support mechanisms are supported by traditional operating sys- for one-to-many communications. We do thus propose tems such as Linux. We also study Barrelfish message ZIMP, a new inter-core communication mechanism that passing, the inter-process communication mechanism of implements zero-copy inter-core message communications and that efficiently handles one-to-many communications.
    [Show full text]
  • D-Bus, the Message Bus System Training Material
    Maemo Diablo D-Bus, The Message Bus System Training Material February 9, 2009 Contents 1 D-Bus, The Message Bus System 2 1.1 Introduction to D-Bus ......................... 2 1.2 D-Bus architecture and terminology ................ 3 1.3 Addressing and names in D-Bus .................. 4 1.4 Role of D-Bus in maemo ....................... 6 1.5 Programming directly with libdbus ................. 9 1 Chapter 1 D-Bus, The Message Bus System 1.1 Introduction to D-Bus D-Bus (the D originally stood for "Desktop") is a relatively new inter process communication (IPC) mechanism designed to be used as a unified middleware layer in free desktop environments. Some example projects where D-Bus is used are GNOME and Hildon. Compared to other middleware layers for IPC, D-Bus lacks many of the more refined (and complicated) features and for that reason, is faster and simpler. D-Bus does not directly compete with low level IPC mechanisms like sock- ets, shared memory or message queues. Each of these mechanisms have their uses, which normally do not overlap the ones in D-Bus. Instead, D-Bus aims to provide higher level functionality, like: Structured name spaces • Architecture independent data formatting • Support for the most common data elements in messages • A generic remote call interface with support for exceptions (errors) • A generic signalling interface to support "broadcast" type communication • Clear separation of per-user and system-wide scopes, which is important • when dealing with multi-user systems Not bound to any specific programming language (while providing a • design that readily maps to most higher level languages, via language specific bindings) The design of D-Bus benefits from the long experience of using other mid- dleware IPC solutions in the desktop arena and this has allowed the design to be optimised.
    [Show full text]
  • Retrofitting Privacy Controls to Stock Android
    Saarland University Faculty of Mathematics and Computer Science Department of Computer Science Retrofitting Privacy Controls to Stock Android Dissertation zur Erlangung des Grades des Doktors der Ingenieurwissenschaften der Fakultät für Mathematik und Informatik der Universität des Saarlandes von Philipp von Styp-Rekowsky Saarbrücken, Dezember 2019 Tag des Kolloquiums: 18. Januar 2021 Dekan: Prof. Dr. Thomas Schuster Prüfungsausschuss: Vorsitzender: Prof. Dr. Thorsten Herfet Berichterstattende: Prof. Dr. Michael Backes Prof. Dr. Andreas Zeller Akademischer Mitarbeiter: Dr. Michael Schilling Zusammenfassung Android ist nicht nur das beliebteste Betriebssystem für mobile Endgeräte, sondern auch ein ein attraktives Ziel für Angreifer. Um diesen zu begegnen, nutzt Androids Sicher- heitskonzept App-Isolation und Zugangskontrolle zu kritischen Systemressourcen. Nutzer haben dabei aber nur wenige Optionen, App-Berechtigungen gemäß ihrer Bedürfnisse einzuschränken, sondern die Entwickler entscheiden über zu gewährende Berechtigungen. Androids Sicherheitsmodell kann zudem nicht durch Dritte angepasst werden, so dass Nutzer zum Schutz ihrer Privatsphäre auf die Gerätehersteller angewiesen sind. Diese Dissertation präsentiert einen Ansatz, Android mit umfassenden Privatsphäreeinstellun- gen nachzurüsten. Dabei geht es konkret um Techniken, die ohne Modifikationen des Betriebssystems oder Zugriff auf Root-Rechte auf regulären Android-Geräten eingesetzt werden können. Der erste Teil dieser Arbeit etabliert Techniken zur Durchsetzung von Sicherheitsrichtlinien
    [Show full text]
  • Beej's Guide to Unix IPC
    Beej's Guide to Unix IPC Brian “Beej Jorgensen” Hall [email protected] Version 1.1.3 December 1, 2015 Copyright © 2015 Brian “Beej Jorgensen” Hall This guide is written in XML using the vim editor on a Slackware Linux box loaded with GNU tools. The cover “art” and diagrams are produced with Inkscape. The XML is converted into HTML and XSL-FO by custom Python scripts. The XSL-FO output is then munged by Apache FOP to produce PDF documents, using Liberation fonts. The toolchain is composed of 100% Free and Open Source Software. Unless otherwise mutually agreed by the parties in writing, the author offers the work as-is and makes no representations or warranties of any kind concerning the work, express, implied, statutory or otherwise, including, without limitation, warranties of title, merchantibility, fitness for a particular purpose, noninfringement, or the absence of latent or other defects, accuracy, or the presence of absence of errors, whether or not discoverable. Except to the extent required by applicable law, in no event will the author be liable to you on any legal theory for any special, incidental, consequential, punitive or exemplary damages arising out of the use of the work, even if the author has been advised of the possibility of such damages. This document is freely distributable under the terms of the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License. See the Copyright and Distribution section for details. Copyright © 2015 Brian “Beej Jorgensen” Hall Contents 1. Intro................................................................................................................................................................1 1.1. Audience 1 1.2. Platform and Compiler 1 1.3.
    [Show full text]
  • Mmap and Dma
    CHAPTER THIRTEEN MMAP AND DMA This chapter delves into the area of Linux memory management, with an emphasis on techniques that are useful to the device driver writer. The material in this chap- ter is somewhat advanced, and not everybody will need a grasp of it. Nonetheless, many tasks can only be done through digging more deeply into the memory man- agement subsystem; it also provides an interesting look into how an important part of the kernel works. The material in this chapter is divided into three sections. The first covers the implementation of the mmap system call, which allows the mapping of device memory directly into a user process’s address space. We then cover the kernel kiobuf mechanism, which provides direct access to user memory from kernel space. The kiobuf system may be used to implement ‘‘raw I/O’’ for certain kinds of devices. The final section covers direct memory access (DMA) I/O operations, which essentially provide peripherals with direct access to system memory. Of course, all of these techniques requir e an understanding of how Linux memory management works, so we start with an overview of that subsystem. Memor y Management in Linux Rather than describing the theory of memory management in operating systems, this section tries to pinpoint the main features of the Linux implementation of the theory. Although you do not need to be a Linux virtual memory guru to imple- ment mmap, a basic overview of how things work is useful. What follows is a fairly lengthy description of the data structures used by the kernel to manage memory.
    [Show full text]
  • An Introduction to Linux IPC
    An introduction to Linux IPC Michael Kerrisk © 2013 linux.conf.au 2013 http://man7.org/ Canberra, Australia [email protected] 2013-01-30 http://lwn.net/ [email protected] man7 .org 1 Goal ● Limited time! ● Get a flavor of main IPC methods man7 .org 2 Me ● Programming on UNIX & Linux since 1987 ● Linux man-pages maintainer ● http://www.kernel.org/doc/man-pages/ ● Kernel + glibc API ● Author of: Further info: http://man7.org/tlpi/ man7 .org 3 You ● Can read a bit of C ● Have a passing familiarity with common syscalls ● fork(), open(), read(), write() man7 .org 4 There’s a lot of IPC ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 5 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 6 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memoryn attach ● Pseudoterminals tio a ● proc_vm_readv() / proc_vm_writev() ● Sockets ic n ● Signals ● Stream vs Datagram (vs uSeq.
    [Show full text]
  • Message Passing Model
    Message Passing Model Giuseppe Anastasi [email protected] Pervasive Computing & Networking Lab. (PerLab) Dept. of Information Engineering, University of Pisa PerLab Based on original slides by Silberschatz, Galvin and Gagne Overview PerLab Message Passing Model Addressing Synchronization Example of IPC systems Message Passing Model 2 Operating Systems Objectives PerLab To introduce an alternative solution (to shared memory) for process cooperation To show pros and cons of message passing vs. shared memory To show some examples of message-based communication systems Message Passing Model 3 Operating Systems Inter-Process Communication (IPC) PerLab Message system – processes communicate with each other without resorting to shared variables. IPC facility provides two operations: send (message ) – fixed or variable message size receive (message ) If P and Q wish to communicate, they need to: establish a communication link between them exchange messages via send/receive The communication link is provided by the OS Message Passing Model 4 Operating Systems Implementation Issues PerLab Physical implementation Single-processor system Shared memory Multi-processor systems Hardware bus Distributed systems Networking System + Communication networks Message Passing Model 5 Operating Systems Implementation Issues PerLab Logical properties Can a link be associated with more than two processes? How many links can there be between every pair of communicating processes? What is the capacity of a link? Is the size of a message that the link can accommodate fixed or variable? Is a link unidirectional or bi-directional? Message Passing Model 6 Operating Systems Implementation Issues PerLab Other Aspects Addressing Synchronization Buffering Message Passing Model 7 Operating Systems Overview PerLab Message Passing Model Addressing Synchronization Example of IPC systems Message Passing Model 8 Operating Systems Direct Addressing PerLab Processes must name each other explicitly.
    [Show full text]
  • Table of Contents
    TABLE OF CONTENTS Chapter 1 Introduction ............................................................................................. 3 Chapter 2 Examples for FPGA ................................................................................. 4 2.1 Factory Default Code ................................................................................................................................. 4 2.2 Nios II Control for Programmable PLL/ Temperature/ Power/ 9-axis ....................................................... 6 2.3 Nios DDR4 SDRAM Test ........................................................................................................................ 12 2.4 RTL DDR4 SDRAM Test ......................................................................................................................... 14 2.5 USB Type-C DisplayPort Alternate Mode ............................................................................................... 15 2.6 USB Type-C FX3 Loopback .................................................................................................................... 17 2.7 HDMI TX and RX in 4K Resolution ........................................................................................................ 21 2.8 HDMI TX in 4K Resolution ..................................................................................................................... 26 2.9 Low Latency Ethernet 10G MAC Demo .................................................................................................. 29 2.10 Socket
    [Show full text]
  • Message Passing
    COS 318: Operating Systems Message Passing Jaswinder Pal Singh Computer Science Department Princeton University (http://www.cs.princeton.edu/courses/cos318/) Sending A Message Within A Computer Across A Network P1 P2 Send() Recv() Send() Recv() Network OS Kernel OS OS COS461 2 Synchronous Message Passing (Within A System) Synchronous send: u Call send system call with M u send system call: l No buffer in kernel: block send( M ) recv( M ) l Copy M to kernel buffer Synchronous recv: u Call recv system call M u recv system call: l No M in kernel: block l Copy to user buffer How to manage kernel buffer? 3 API Issues u Message S l Buffer (addr) and size l Message type, buffer and size u Destination or source send(dest, msg) R l Direct address: node Id, process Id l Indirect address: mailbox, socket, recv(src, msg) channel, … 4 Direct Addressing Example Producer(){ Consumer(){ ... ... while (1) { for (i=0; i<N; i++) produce item; send(Producer, credit); recv(Consumer, &credit); while (1) { send(Consumer, item); recv(Producer, &item); } send(Producer, credit); } consume item; } } u Does this work? u Would it work with multiple producers and 1 consumer? u Would it work with 1 producer and multiple consumers? u What about multiple producers and multiple consumers? 5 Indirect Addressing Example Producer(){ Consumer(){ ... ... while (1) { for (i=0; i<N; i++) produce item; send(prodMbox, credit); recv(prodMbox, &credit); while (1) { send(consMbox, item); recv(consMbox, &item); } send(prodMbox, credit); } consume item; } } u Would it work with multiple producers and 1 consumer? u Would it work with 1 producer and multiple consumers? u What about multiple producers and multiple consumers? 6 Indirect Communication u Names l mailbox, socket, channel, … u Properties l Some allow one-to-one mbox (e.g.
    [Show full text]
  • This Is the Architecture of Android. Android Runs on Top of a Vanilla Kernel with Little Modifications, Which Are Called Androidisms
    4. This is the architecture of Android. Android runs on top of a vanilla kernel with little modifications, which are called Androidisms. The native userspace, includes the init process, a couple of native daemons, hundreds of native libraries and the Hardware Abstraction Layer (HAL). The native libraries are implemented in C/C++ and their functionality is exposed to applications through Java framework APIs. A large part of Android is implemented in Java and until Android version 5.0 the default runtime was Dalvik. Recently a new, more performant runtime, called ART has been integrated in Android (first made available as an option in version 4.4, default runtime from version 5.0). Java runtime libraries are defined in java.* and javax.* packages, and are derived from Apache Harmony project (not Oracle/SUN, in order to avoid copyright and distribution issues.), but several components have been replaced, others extended and improved. Native code can be called from Java through the Java Native Interface (JNI). A large part of the fundamental features of Android are implemented in the system services: display, touch screen, telephony, network connectivity, and so on. A part of these services are implemented in native code and the rest in Java. Each service provides an interface which can be called from other components. Android Framework libraries (also called “the framework API”) include classes for building Android applications. On top, we have the stock applications, that come with the phone. And other applications that are installed by the user. 6. ● Most Linux distributions take the vanilla kernel (from Linux Kernel Archives) and apply their own patches in order to solve bugs, add specific features and improve performance.
    [Show full text]
  • IPC: Mmap and Pipes
    Interprocess Communication: Memory mapped files and pipes CS 241 April 4, 2014 University of Illinois 1 Shared Memory Private Private address OS address address space space space Shared Process A segment Process B Processes request the segment OS maintains the segment Processes can attach/detach the segment 2 Shared Memory Private Private Private address address space OS address address space space space Shared Process A segment Process B Can mark segment for deletion on last detach 3 Shared Memory example /* make the key: */ if ((key = ftok(”shmdemo.c", 'R')) == -1) { perror("ftok"); exit(1); } /* connect to (and possibly create) the segment: */ if ((shmid = shmget(key, SHM_SIZE, 0644 | IPC_CREAT)) == -1) { perror("shmget"); exit(1); } /* attach to the segment to get a pointer to it: */ data = shmat(shmid, (void *)0, 0); if (data == (char *)(-1)) { perror("shmat"); exit(1); } 4 Shared Memory example /* read or modify the segment, based on the command line: */ if (argc == 2) { printf("writing to segment: \"%s\"\n", argv[1]); strncpy(data, argv[1], SHM_SIZE); } else printf("segment contains: \"%s\"\n", data); /* detach from the segment: */ if (shmdt(data) == -1) { perror("shmdt"); exit(1); } return 0; } Run demo 5 Memory Mapped Files Memory-mapped file I/O • Map a disk block to a page in memory • Allows file I/O to be treated as routine memory access Use • File is initially read using demand paging ! i.e., loaded from disk to memory only at the moment it’s needed • When needed, a page-sized portion of the file is read from the file system
    [Show full text]
  • A Machine-Independent DMA Framework for Netbsd
    AMachine-Independent DMA Framework for NetBSD Jason R. Thorpe1 Numerical Aerospace Simulation Facility NASA Ames Research Center Abstract 1.1. Host platform details One of the challenges in implementing a portable In the example platforms listed above,there are at kernel is finding good abstractions for semantically- least three different mechanisms used to perform DMA. similar operations which often have very machine- The first is used by the i386 platform. This mechanism dependent implementations. This is especially impor- can be described as "what you see is what you get": the tant on modern machines which share common archi- address that the device uses to perform the DMA trans- tectural features, e.g. the PCI bus. fer is the same address that the host CPU uses to access This paper describes whyamachine-independent the memory location in question. DMA mapping abstraction is needed, the design consid- DMA address Host address erations for such an abstraction, and the implementation of this abstraction in the NetBSD/alpha and NetBSD/i386 kernels. 1. Introduction NetBSD is a portable, modern UNIX-likeoperat- ing system which currently runs on eighteen platforms covering nine processor architectures. Some of these platforms, including the Alpha and i3862,share the PCI busasacommon architectural feature. In order to share device drivers for PCI devices between different platforms, abstractions that hide the details of bus access must be invented. The details that must be hid- den can be broken down into twoclasses: CPU access Figure 1 - WYSIWYG DMA to devices on the bus (bus_space)and device access to host memory (bus_dma). Here we will discuss the lat- The second mechanism, employed by the Alpha, ter; bus_space is a complicated topic in and of itself, is very similar to the first; the address the host CPU and is beyond the scope of this paper.
    [Show full text]