DOCSLIB.ORG

Playing Bluez on the D-Bus

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Playing BlueZ on the D-Bus Marcel Holtmann BlueZ Project [email protected] Abstract possible tasks and configuration options are ac- cessed via the D-Bus interface. This will al- low to abstract the internals of GNOME and The integration of the Bluetooth technology KDE applications from any technical details of into the Linux kernel and the major Linux dis- the Bluetooth specification. Even other appli- tributions has progressed really fast over the cation will get access to the Bluetooth technol- last two years. The technology is present al- ogy without any hassle. most everywhere. All modern notebooks and mobile phones are shipped with built-in Blue- tooth. The use of Bluetooth with a Linux based system is easy and in most cases it only needs 1 Introduction an one-time setup, but all the tools are still com- mand line based. In general this is not so bad, but for a greater success it is needed to seam- The Bluetooth specification [1] defines a clear lessly integrate the Bluetooth technology into abstraction layer for accessing different Blue- the desktop. There have been approaches for tooth hardware options. It is called the Host the GNOME and KDE desktops. Both have Controller Interface (HCI) and is the basis of been quite successful and made the use of Blue- all Bluetooth protocols stacks (see Figure 1). tooth easy. The problem however is that both implemented their own framework around the This interface consists of commands and events Bluetooth library and its daemons and there that provide support for configuring the local were no possibilities for programs from one device and creating connections to other Blue- system to talk to the other. With the final ver- tooth devices. The commands are split into six sion of the D-Bus framework and its adaption different groups: into the Bluetooth subsystem of Linux, it will be simple to make all applications Bluetooth • Link Control Commands aware. • Link Policy Commands The idea is to establish one central Bluetooth daemon that takes care of all task that can’t or • Host Controller and Baseband Commands shouldn’t be handled inside the Linux kernel. These jobs include PIN code and link key man- • Informational Parameters agement for the authentication and encryption, • Status Parameters caching of device names and services and also central control of the Bluetooth hardware. All • Testing Commands 422 • Playing BlueZ on the D-Bus code or to notify of a changed power state. Applications and Profiles Every Bluetooth implementation must imple- OBEX ment the Host Controller Interface and for Linux a specific set of commands has been in- SDP RFCOMM tegrated into the Linux kernel. Another set of commands are implemented through the Blue- L2CAP tooth library. And some of the commands are not implemented at all. This is because they are HCI not needed or because they have been depre- cated by the latest Bluetooth specification. The Link Manager range of commands implemented in the kernel are mostly dealing with Bluetooth connection Baseband handling. The commands in the Bluetooth li- brary are for configuration of the local device Radio and handling of authentication and encryption. While the Host Controller Interface is a clean hardware abstraction, it is not a clean or easy Figure 1: Simple Bluetooth stack programming interface. The Bluetooth library provides an interface to HCI and an applica- With the Link Control Commands it is pos- tion programmer has to write a lot of code to sible to search for other Bluetooth devices in get Bluetooth specific tasks done via HCI. To range and to establish connections to other de- make it easy for application programmers and vices. This group also includes commands to also end users, a task based interface to Blue- handle authentication and encryption. The Link tooth has been designed. The definition of this Policy Commands are controlling the estab- tasks has been done from an application per- lished connections between two or more Blue- spective and they are exported through D-Bus tooth devices. They also control the different via methods and signal. power modes. All local settings of a Blue- tooth device are modified with commands from the Host Controller and Baseband Commands 2 D-Bus integration group. This includes for example the friendly name and the class of device. For detailed in- formation of the local device, the commands The hcid daemon is the main daemon when from the Informational Paramters group can be running Bluetooth on Linux. It handles all de- used. The Status Parameters group provides vice configuration and authentication tasks. All commands for detailed information from the re- configuration is done via a simple configuration mote device. This includes the link quality and file and the PIN code is handled via PIN helper the RSSI value. With the group Testing Com- script. This means that every the configuration mands the device provides commands for Blue- option needed to be changed, it was needed to tooth qualification testing. All commands are edit the configuration file (/etc/bluetooth/ answered by an event that returns the requested hcid.conf) and to restart hcid. The config- value or information. Some events can also ar- uration file still configures the basic and also rive at any time. For example to request a PIN default settings of hcid, but with the D-Bus 2006 Linux Symposium, Volume One • 423 integration all other settings are configurable is attached. With ListAdapters() it is pos- through the D-Bus API. The current API con- sible to get a complete list of paths of the at- sists of three interfaces: tached adapters. If the path is known, it is possible to use the • org.bluez.Manager full Adapter interface to configure the local de- vice or handle tasks like pairing or searching • org.bluez.Adapter for other devices. An example task would be • org.bluez.Security the configuration of the device name. With GetName() the current name can be retrieved and with SetName() it can be changed. The Manager interface provides basic meth- Changing the name results in storing it on the ods for listing all attached adapter and getting filesystem and changing the name with an ap- the default adapter. In the D-Bus API terms propriate HCI command. If the local device al- an adapter is the local Bluetooth device. In ready supports the Bluetooth Lisbon specifica- most cases this might be an USB dongle or tion, then the Extended Inquiry Response will a PCMCIA card. The Adapter interface pro- be also modified. vides methods for configuration of the local device, searching for remote device and han- With the DiscoverDevices() method it dling of remote devices. The Security interface is possible to start the search for other Blue- provides methods to register passkey agents. tooth devices in range. This method call actu- These agents can provide fixed PIN codes, di- ally doesn’t return any remote devices. It only alog boxes or wizards for specific remote de- starts the inquiry procedure of the Bluetooth vices. All Bluetooth applications using the D- chip and every found device is returned via the Bus API don’t have to worry about any Blue- RemoteDeviceFound signal. This allows tooth specific details or details of the Linux spe- all applications to handle new devices even if cific implementation (see Figure 2). the discovery procedure has been initiated by a different application. Besides the provided methods, every interface contains also signals to broadcast changes or events from the HCI. This allows passive ap- plications to get the information without ac- 3 Current status tively interacting with any Bluetooth related task. An example for this would be an applet The methods and signals for the D-Bus API that changes its icon depending on if the local for Bluetooth were chosen very carefully. The device is idle, connected or searching for other goal was to design it with current application devices. needs in mind. It also aims to fulfill the needs of current established desktop frameworks like Every local device is identified by its path. the GNOME Bluetooth subsystem and the KDE For the first Bluetooth adapter, this would Bluetooth framework. So it covers the common be /org/bluez/hci0 and this path will be tasks and on purpose not everything that might used for all methods of the Adapter inter- be possible. The API can be divided into the face. The best way to get this path is to call following sections: DefaultAdapter() from the Manager in- terface. This will always return the current de- fault adapter or in error if no Bluetooth adapter • Local 424 • Playing BlueZ on the D-Bus applications org.bluez.Manager org.bluez.Adapter org.bluez.Security hcid Passkey Manager Core Manager Adapter Manager Security Manager Host Controller Interface kernel Bluetooth Core Bluetooth Drivers Figure 2: D-Bus API overview – version, revision, manufacturer ming languages. With the integration of D- – mode, name, class of device Bus into the Bluetooth subsystem, the use of Bluetooth from various languages becomes re- • Remote ality. The Figure 3 shows an example of chang- My Blue- – version, revision, manufacturer ing the name of the local device into tooth dongle using the Python programming – name, class of device language. – aliases The example in Python is straight forward and – device discovery simple. Using the D-Bus API within a C pro- – pairing, bondings gram is a little bit more complex, but it is still • Security easier than using the native Bluetooth library API. Figure 4 shows an example on how to get – passkey agent the name of the local device. With these methods and signals all standard tasks are covered.
Recommended publications
  • Distributed Programming I (Socket - Nov'09)

    Distributed Programming I (Socket - Nov'09)

    Distributed programming I (socket - nov'09) Warning for programmers network programming is dangerously close to O.S. Network programming: sockets kernel, and therefore: It can easily hang the O.S. verify the results of every operation, without assuming anything as granted Antonio Lioy < [email protected] > APIs can vary in details that are minimal but important consider every possible situation to create english version created and modified by “portable” programs Marco D. Aime < [email protected] > we will try to use Posix 1.g Politecnico di Torino Dip. Automatica e Informatica ISO/OSI, TCP/IP, network programming Exercise – copying data copy the content of file F1 (first parameter on the application command line) into file F2 (second parameter on the 7. application details application command line) user 6. presentation (l6: XDR/XML/... process l5: RPC/SOAP/...) 5. session network programming 4. transport TCP UDP SCTP interface 3. network IPv4, IPv6 kernel communication 2. data link device driver details 1. physical and hardware OSI model IP suite ref. UNP Intro copyfile.c Error messages Error functions must contain at least: best to define standard error reporting functions [ PROG ] program name which accept: [ LEVEL ] error level (info, warning, error, bug) a format string for the error [ TEXT ] error signalling, the most specific as possible a list of parameters to be printed (e.g. input file name and line where the problem has UNP, appendix D.4 (D.3 in 3rd edition) occurred) errno? termination? log level [ ERRNO ] system error number and/or name (if applicable) err_msg no no LOG_INFO err_quit no exit(1) LOG_ERR suggested format: err_ret yes no LOG_INFO err_sys yes exit(1) LOG_ERR ( PROG ) LEVEL - TEXT : ERRNO err_dump yes abort( ) LOG_ERR errlib.h errlib.c © A.Lioy - Politecnico di Torino (2009) B-1 Distributed programming I (socket - nov'09) stdarg.h stdarg.h usage example variable list of arguments (ANSI C) create a function named my_printf declared with an ellipsis (.
  • Beej's Guide to Unix IPC

    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.
  • POSIX Signals

    POSIX Signals

    CSE 410: Systems Programming POSIX Signals Ethan Blanton Department of Computer Science and Engineering University at Buffalo Introduction Signals Blocking Concurrency Sending Signals Summary References POSIX Signals POSIX signals are another form of interprocess communication. They are also a way to create concurrency in programs. For these two reasons, they are rather complicated and subtle! Signals provide a simple message passing mechanism. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Signals as Messages POSIX signals are asynchronous messages. Asynchronous means that their reception can occur at any time.1 The message is the reception of the signal itself. Each signal has a number, which is a small integer. POSIX signals carry no other data. 1Almost. We’ll see how to control it later. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Signal Types There are two basic types of POSIX signals: Reliable signals Real-time signals Real-time signals are much more complicated. In particular, they can carry data. We will discuss only reliable signals in this lecture. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Asynchronous Reception From the point of view of the application: Signals can be blocked or ignored Enabled signals may be received between any two processor instructions A received signal can run a user-defined function called a signal handler This means that enabled signals and program code must very carefully manipulate shared or global data! © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Signals POSIX defines a number of signals by name and number.
  • Programming with POSIX Threads II

    Programming with POSIX Threads II

    Programming with POSIX Threads II CS 167 IV–1 Copyright © 2008 Thomas W. Doeppner. All rights reserved. Global Variables int IOfunc( ) { extern int errno; ... if (write(fd, buffer, size) == –1) { if (errno == EIO) fprintf(stderr, "IO problems ...\n"); ... return(0); } ... } CS 167 IV–2 Copyright © 2008 Thomas W. Doeppner. All rights reserved. Unix was not designed with multithreaded programming in mind. A good example of the implications of this is the manner in which error codes for failed system calls are made available to a program: if a system call fails, it returns –1 and the error code is stored in the global variable errno. Though this is not all that bad for single-threaded programs, it is plain wrong for multithreaded programs. Coping • Fix Unix’s C/system-call interface • Make errno refer to a different location in each thread – e.g. #define errno __errno(thread_ID) CS 167 IV–3 Copyright © 2008 Thomas W. Doeppner. All rights reserved. The ideal way to solve the “errno problem” would be to redesign the C/system-call interface: system calls should return only an error code. Anything else to be returned should be returned via result parameters. (This is how things are done in Windows NT.) Unfortunately, this is not possible (it would break pretty much every Unix program in existence). So we are stuck with errno. What can we do to make errno coexist with multithreaded programming? What would help would be to arrange, somehow, that each thread has its own private copy of errno. I.e., whenever a thread refers to errno, it refers to a different location from any other thread when it refers to errno.
  • UNIT: 4 DISTRIBUTED COMPUTING Introduction to Distributed Programming

    UNIT: 4 DISTRIBUTED COMPUTING Introduction to Distributed Programming

    UNIT: 4 DISTRIBUTED COMPUTING Introduction To Distributed Programming: • Distributed computing is a model in which components of a software system are shared among multiple computers. Even though the components are spread out across multiple computers, they are run as one system. This is done in order to improve efficiency and performance. • Distributed computing allows different users or computers to share information. Distributed computing can allow an application on one machine to leverage processing power, memory, or storage on another machine. Some applications, such as word processing, might not benefit from distribution at all. • In parallel computing, all processors may have access to a shared memory to exchange information between processors. In distributed computing, each processor has its own private memory (distributed memory). Information is exchanged by passing messages between the processors. • Distributed computing systems are omnipresent in today’s world. The rapid progress in the semiconductor and networking infrastructures have blurred the differentiation between parallel and distributed computing systems and made distributed computing a workable alternative to high- performance parallel architectures. • However attractive distributed computing may be, developing software for such systems is hardly a trivial task. Many different models and technologies have been proposed by academia and industry for developing robust distributed software systems. • Despite a large number of such systems, one fact is clear that the software
  • Introduction to POSIX Signals

    Introduction to POSIX Signals

    Introduction to POSIX Signals Michael Jantz Prasad Kulkarni Douglas Niehaus Introduction ● This lab is an introduction to signals in Unix systems. – In it, you will learn about some common uses for signals. – You will also construct a small program that uses signals. ● Unpack the starter code, then make and tag it: – bash> tar zxvf eecs678-signals-lab.tar.gz – cd signals/; make; ctags -R EECS 678 Signals Lab 2 Signals ● A signal is a short message that may be sent to a process or a group of processes. ● The only information given to a process is usually the number identifying the signal; there is no room in standard signals for arguments, a message or other accompanying information. ● Signals serve two main purposes: – To make a process aware that a specific event has occurred. – To cause a process to execute a signal handler function included in its code. EECS 678 Signals Lab 3 Interrupts vs. Signals ● Signals and interrupts are very similar in their behavior ● Important difference: interrupts are sent to the operating system by the hardware, signals are sent to the process by the operating system, or other processes through the OS ● Important similarity: both signals and interrupts associate handlers with asynchronous events which interrupt current processing, thus inserting the handler into current code path ● Signals can thus be thought of as an interrupt in software: – However, note that signals have nothing to do with Soft-IRQs. The name seems related, but these are a method for deferring much of the processing associated with a hardware-interrupt into a less restrictive execution context inside the OS.
  • POSIX Signal Handling in Java

    POSIX Signal Handling in Java

    Technical Document Series POSIX Signal Handling in Java POSIX Signal Handling In Java Introduction POSIX signals inform a running process of external events, such as the user wishing to kill the process, or the operating system signaling an impending shutdown, or the process being suspended or reinstated; or the process may have violated a resource constraint, such as excessive CPU usage or attempts to access areas outside its permitted memory space, and is asked to shutdown. In short, POSIX signals serve many different purposes. Some are even up to interpretation, such as the HUP (HangUP) signal, which is commonly used to inform a process that something about its environment has changed and the process should adjust accordingly. Some programs may interpret this to mean that the configuration has changed and needs to be reloaded; or the log file has been moved for archiving purposes and a new one should be started. The use of signals is widespread, especially on Unix-based operating systems, but Java provides no standard interface for a Java application to hear and react to them. This document shows you how to get around this limitation. The Good, the Bad, and the Ugly The good news is that there is a way to intercept POSIX signals and react to them in Java. This would allow your Java program to avoid being killable with ^C (SIGINT), for example, even ignore termination requests from the operating system (SIGTERM). Neither of these is necessarily a good idea, of course, unless you know exactly why you would want to catch these signals and either handle them yourself or ignore them altogether.
  • Lecture 14: Paging

    Lecture 14: Paging

    Lecture 14: Paging Fall 2018 Jason Tang Slides based upon Operating System Concept slides, http://codex.cs.yale.edu/avi/os-book/OS9/slide-dir/index.html Copyright Silberschatz, Galvin, and Gagne, 2013 "1 Topics • Memory Mappings! • Page Table! • Translation Lookaside Bu$ers! • Page Protection "2 Memory Mapped • Logical address translated not to memory but some other location! • Memory-mapped I/O (MMIO): hardware redirects read/write of certain addresses to physical device! • For example, on x86, address 0x3F8 usually mapped to first serial port! • Memory-mapped file (mmap): OS redirects read/write of mapped memory region to file on disk! • Every call to read() / write() involves a system call! • Writing to a pointer faster, and OS can translate in the background (also see upcoming lecture) "3 Memory-Mapped File • In Linux, typical pattern is to:! • Open file, using open() function! • Optional: preallocate file size, using ftruncate()! • Create memory mapping, using mmap() function! • Do work, and then release mapping using munmap() function! • Kernel might not write data to disk until munmap() "4 mmap() function void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset) • addr is target address of mapping, or NULL to let kernel decide! • length is number of bytes to map! • prot defines what mapping protection (read-only or read/write)! • flags sets other options! • fd is file descriptor that was returned by open()! • offset is o$set into file specified by fd "5 mmap() example part 1 • See man page for each of these functions
  • Interprocess Communication 1 Processes • Basic Concept to Build

    Interprocess Communication 1 Processes • Basic Concept to Build

    Interprocess Communication 1 Processes • Basic concept to build the OS, from old IBM mainframe OS to the most modern Windows • Used to express the requirements to be met by an OS – Interleave the execution of multiple processes, to maximize CPU utilization while providing good response time – Allocate resources to processes using a policy while avoiding deadlocks – Support interprocess communications and user creation of processes to help structuring applications • Background – Computer platform * Collection of hardware resources – CPU, memory, I/O modules, timers, storage devices – Computer applications * Developed to perform some task * Input, processing, output – Efficient to write applications for a given CPU * Common routines to access computer resources across platforms * CPU provides only limited support for multiprogramming; software manages sharing of CPU and other re- sources by multiple applications concurrently * Data and resources for multiple concurrent applications must be protected from other applications • Process – Abstraction of a running program – Unit of work in the system – Split into two abstractions in modern OS * Resource ownership (traditional process view) * Stream of instruction execution (thread) – Pseudoparallelism, or interleaved instructions – A process is traced by listing the sequence of instructions that execute for that process • Modeling sequential process/task – Program during execution – Program code – Current activity – Process stack * Function parameters * Return addresses * Temporary variables –
  • Dressing up Data For

    Dressing up Data For

    Dressing up data for Hannes Mühleisen DSC 2017 Problem? • People push large amounts of data into R • Databases, Parquet/Feather … • Need native SEXP for compatibility • R has no abstraction for data access • INTEGER(A)[i] * INTEGER(B)[j] etc. • Data possibly never actually used 2 Sometimes lucky • Perfectly compatible bits: • int my_int_arr[100]; • double my_dbl_arr[100]; • Doctor SEXP header in front of data and good to go • Implemented in MonetDBLite with custom allocator • Next version on CRAN will have this https://github.com/hannesmuehleisen/MonetDBLite 3 Zero-Copy in MonetDBLite Page 1 Page 2 Page 3 Page 4 Page 5 addr = mmap(col_file, len, NULL) col_file addr addr1 = mmap(NULL, len + PAGE_SIZE, NULL) addr2 = mmap(col_file, len, addr1 + 4096) addr3 = addr1 + PAGE_SIZE - sizeof(SEXPREC_ALIGN) SEXP res = allocVector3(INTSXP, len/sizeof(int), &allocator); Page 0 Page 1 Page 2 Page 3 Page 4 Page 5 col_file addr1 res & addr3 4 Demo 1 Stock R, MonetDBLite & zero-copy library(“DBI”) con <- dbConnect(MonetDBLite::MonetDBLite(), "/tmp/dscdemo") dbGetQuery(con, "SELECT COUNT(*) FROM onebillion”) # 1 1e+09 system.time(a <- dbGetQuery(con, "SELECT i FROM onebillion”)) # user system elapsed # 0.032 0.000 0.033 .Internal(inspect(a$i)) # @20126efd8 13 INTSXP g0c6 [NAM(2)] (len=1000000000, tl=0) 1,2,3,4,5,... Native R Vector w. zero-copy! 5 Not always so lucky • What if we have to actually convert? • Strings, TIMESTAMP to POSIXct etc. • NULL/NA mismatches • More involved data representations • compressed, batched, hybrid row/col, … • Need to convert all data before handing control over to R. • Can take forever, takes memory, non-obvious wait time 6 ALTREP • Luke Tierney, Gabe Becker & Tomas Kalibera • Abstract vectors, ELT()/GET_REGION() methods • Lazy conversion! static void monetdb_altrep_init_int(DllInfo *dll) { R_altrep_class_t cls = R_make_altinteger_class(/* .
  • Signals and Pipes

    Signals and Pipes

    Signals and Pipes Signals and Pipes 1/20 Learning Objectives Signals and Pipes I Understand synchronization issues with respect to signals I Learn about the client-server model using pipes and named pipes I Understand basic concepts of servers and daemons 2/20 More on Signals Signals and Pipes I Two main system calls that deal with signals: signal() and sigaction(). The sigaction() call is consistent across various systems whereas signal() is not necessarily consistent across systems but is simpler to use. See man page for details on both. I Examples: I signal-ex1.c I signal-ex2.c 3/20 Signal Handling after Exec Signals and When a program is exec’d the status of all signals is either default or Pipes ignore. The exec functions changes the disposition of any signals that are being caught to their default action (why?) and leaves the status of all other signals alone. For example: if (fork()==0) {// the child process if(signal(SIGINT, SIG_IGN) == SIG_ERR) err_ret ("failed␣to␣set␣SIGINT␣behavior"); if(signal(SIGTSTP, SIG_IGN) == SIG_ERR) err_ret ("failed␣to␣set␣SIGTSTP␣behavior"); execvp(program, argv); // the exec 'd program will ignore the // signalsSIGINT andSIGTSTP 4/20 Signal Handling for an Application Signals and How an application ought to set its signal handling: Pipes An application process should catch the signal only if the signal is not currently being ignored. int sig_int(), sig_quit(); if(signal(SIGINT, SIG_IGN) != SIG_IGN) signal(SIGINT, sig_int); if(signal(SIGQUIT, SIG_IGN) != SIG_IGN) signal(SIGQUIT, sig_quit); See code example: signal-ex3.c 5/20 Other Signal Issues Signals and Pipes I Signals are set to their default after being caught (under Linux and System V UNIX semantics).
  • 6.828: Virtual Memory for User Programs

    6.828: Virtual Memory for User Programs

    6.828: Virtual Memory for User Programs Adam Belay <[email protected]> Plan for today • Previously: Discussed using virtual memory tricks to optimize the kernel • This lecture is about virtual memory for user programs: • Concurrent garbage collection • Generational garbage collection • Concurrent checkpointing • Data-compression paging • Persistent stores What primitives do we need? • Trap: handle page-fault traps in usermode • Prot1: decrease the accessibility of a page • ProtN: decrease the accessibility of N pages • Unprot: increase the accessibility of a page • Dirty: returns a list of dirtied pages since previous call • Map2: map the same physical page at two different virtual addresses, at different levels of protection, in the same address space What about UNIX? • Processes manage virtual memory through higher- level abstractions • An address space consists of a non-overlapping list of Virtual Memory Areas (VMAs) and a page table • Each VMA is a contiguous range of virtual addresses that shares the same permissions and is backed by the same object (e.g. a file or anonymous memory) • VMAs help the kernel decide how to handle page faults Unix: mmap() • Maps memory into the address space • Many flags and options • Example: mapping a file mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, offset); • Example: mapping anonymous memory mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); Unix: mprotect() • Changes the permissions of a mapping • PROT_READ, PROT_WRITE, and PROT_EXEC • Example: make mapping read-only mprotect(addr, len, PROT_READ); • Example: make mapping trap on any acCess mprotect(addr, len, PROT_NONE); Unix: munmap() • Removes a mapping • Example: munmap(addr, len); Unix: sigaction() • Configures a signal handler • Example: get signals for memory access violations act.sa_sigaction = handle_sigsegv; act.sa_flags = SA_SIGINFO; sigemptyset(&act.sa_mask); sigaction(SIGSEGV, &act, NULL); Unix: Modern implementations are very complex e.g.