DOCSLIB.ORG

Shared Memory • Tizen Platform IPC – D-Bus – Vconf

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Shared Memory • Tizen Platform IPC – D-Bus – Vconf 1 36 전공핵심실습1:운영체제론 Chapter 6. Inter-process Communication (IPC) Sungkyunkwan University Embedded Software Lab. Dongkun Shin Embedded Software Lab. 2 Contents 36 • Linux Kernel IPC – Pipe – FIFO – System V IPC • Semaphore • Message Queue • Shared Memory • Tizen Platform IPC – D-Bus – vconf Embedded Software Lab. 3 Linux Kernel IPC 36 • Pipe • FIFO • System V IPC – Semaphore – Message Queue – Shared Memory Embedded Software Lab. 4 IPC System Call 36 • User uses IPC mechanism via system calls provided by the kernel Tizen IPC System Calls (# syscall number) PIPE FIFO Semaphore Message Queue Shared Memory MSGGET (303) SHMGET (307) PIPE (42) OPEN (5) SEMGET (299) MSGSND (301) SHMAT (305) PIPE2 (359) READ (3) SEMOP (298) WRITE (4) MSGRCV (302) SHMDT (306) IPC System Call Linux Kernel Embedded Software Lab. 5 PIPE 36 • The oldest form of UNIX IPC and provided by all unix systems • Two limitations – Half-duplex : data flows only in one direction – Can be used only between processes that have a common ancestor • Usually used between the parent and child processes • int pipe (int fd[2]); – Two file descriptors are returned through the fd argument • fd[0] : open for reading • fd[1] : open for writing – The output of fd[1] is the input for fd[0] Embedded Software Lab. 6 PIPE (cont.) 36 Embedded Software Lab. 7 PIPE (cont.) 36 • Kernel Implementation (linux/fs/pipe.c) SYSCALL_DEFINE2(pipe2, int __user *, fildes, int, flags) { struct file *files[2]; int fd[2]; int error; create 2 pipe files (later in fifo) and open with O_RDONLY and O_WRONLY flags error = __do_pipe_flags(fd, files, flags); if (!error) { if (unlikely(copy_to_user(fildes, fd, sizeof(fd)))) { fput(files[0]); Copy file descriptors to userspace as an output of the system call fput(files[1]); put_unused_fd(fd[0]); put_unused_fd(fd[1]); error = -EFAULT; } else { fd_install(fd[0], files[0]); fd_install(fd[1], files[1]); } Install file *s in the file descriptor table of the process } return error; } Embedded Software Lab. 8 FIFO (a.k.a named pipe) 36 • Unrelated processes can exchange data, whereas pipes can be used only between related processes • FIFO is a type of file. (S_ISFIFO macro against st_mode) – FIFO is handled by file operations such as open(), close(), read(), and write(), once a FIFO created. – Multiple readers/writers are allowed • int mkfifo (const char *path, mode_t mode) – Generates FIFO with specific file name, path. – Accesses the generated FIFO with open system calls between 2 processes • open(“fifo1”, O_RDONLY) FIFO must have Reader / Writer both. • open(“fifo1”, O_WRONLY) Embedded Software Lab. 9 Create Pipe Files 36 • Create a directory entry • Create an inode • Plug pipefifo_ops to file_operations of the generated pipe or fifo files. const struct file_operations pipefifo_fops = { .open = fifo_open, .llseek = no_llseek, .read = do_sync_read, .aio_read = pipe_read, .write = do_sync_write, .aio_write = pipe_write, .poll = pipe_poll, .unlocked_ioctl = pipe_ioctl, .release = pipe_release, once. fasyncpipefifo_fops= pipe_fasyncis registered ,as file_operations, }; the normal file I/O functions all work with FIFO Embedded Software Lab. 10 FIFO Example 36 • In Shell $ cat /proc/meminfo | grep –I active | tail –n4 > memory.txt Embedded Software Lab. 11 System V IPC 36 • Semaphore, Message Queue, and Shared Memory • Semaphore – Synchronize itself with other processes • Message Queue (Not equal to POSIX Message queue) – Send or receive messages each other • Shared Memory – Share a memory area • System V IPCs shares same kernel data structures and operations (linux/ipc/util.h) – All IPC objects are stored in kernel memory – They are referred to by IPC object identifier – Kernel translate a given key to corresponding ID, whereas processes only can access the key Embedded Software Lab. 12 IPC Identifier 36 • Key of IPC Resources – semget() – Get Semaphores IPC Resources – msgget() – Get Messages IPC Resources – shmget() – Get Share Memory IPC Resources semget() msgget() + IPC Identifier shmget() (XXX) IPC resource Process1 Process2 XXX Some data for share Embedded Software Lab. 13 IPC Resource (include/linux/ipc_namespace.h) 36 ipc_ids represent The data structure similar with radix tree IPC Resources Type to map a id to the corresponding pointer struct idr ipcs_idr kern_ipc_prem kern_ipc_prem kern_ipc_prem represent represent represent IPC Resource IPC Resource IPC Resource Embedded Software Lab. 14 Semaphore 36 • Similar to the kernel semaphores (lock) – include/linux/semaphore.h, kernel/locking/semaphore.c • Counters used to controlled access to shared data structures for multiple processes semget() : get IPC Identifier semop() : Decrease or Increase semaphore count semop( struct sembuf ) struct sembuf Process IPC resource sem_num : Semaphore number sem_op : Add this to semval (increase / decrease semaphore count) sem_flg : Operation flags Some data for share Embedded Software Lab. 15 Semaphore (ipc/sem.c) 36 • Kernel Implementation SYSCALL_DEFINE3(semget, key_t, key, int, nsems, int, semflg) { struct ipc_namespace *ns; struct ipc_ops sem_ops; struct ipc_params sem_params; ns = current->nsproxy->ipc_ns; if (nsems < 0 || nsems > ns->sc_semmsl) return -EINVAL; newary() function allocates new ipc semaphore to ids as invoked via ipcget() sem_ops.getnew = newary; sem_ops.associate = sem_security; sem_ops.more_checks = sem_more_checks; sem_params.key = key; sem_params.flg = semflg; sem_params.u.nsems = nsems; return ipcget(ns, &sem_ids(ns), &sem_ops, &sem_params); } Embedded Software Lab. 16 newary() (ipc/sem.c) 36 ipc_ids represent IPC Resources Type struct idr ipcs_idr sem_array kern_ipc_prem sem_array kern_ipc_prem represent represent represent represent Semephore IPC Resources Semephore IPC Resources Embedded Software Lab. 17 Message Queue 36 • IPC Messages – msgget() : Create IPC Messages resources or get IPC identifier – msgsnd() : Send messages – msgrcv() : Receive messages – POSIX Message Queue is implemented independently Buffer Data Buffer Data Some data for share msgrcv() msgsnd() IPC resource Process1 Process2 XXX Embedded Software Lab. 18 Messages IPC Resources 36 • Kernel Implementation (ipc/msg.c) SYSCALL_DEFINE2(msgget, key_t, key, int, msgflg) { struct ipc_namespace *ns; struct ipc_ops msg_ops; struct ipc_params msg_params; newqueuens = current() function->nsproxy allocates-> ipc_nsnew ipc; message to ids as invoked via ipcget() msg_ops.getnew = newque; msg_ops.associate = msg_security; msg_ops.more_checks = NULL; msg_params.key = key; msg_params.flg = msgflg; return ipcget(ns, &msg_ids(ns), &msg_ops, &msg_params); } Embedded Software Lab. 19 newque() (ipc/msg.c) 36 ipc_ids represent IPC Resources Type struct idr ipcs_idr msg_queue kern_ipc_prem msg_queue kern_ipc_prem State represent State represent Messages IPC Resources Messages IPC Resources msg_queue msg_queue Messages Messages Embedded Software Lab. 20 Shared Memory 36 • shmget() : Create IPC Share Memory resources or get IPC identifier • shmat() : Map IPC Share Memory space for user process memory space • shmdt() : Unmap IPC Share Memory space for user process memory space Process1 Process2 IPC Resource 0 shmat() 0 shmdt() 0 0 Default : 32MB Kernel Kernel Max : 4096 Data Data 0 0 Embedded Software Lab. 21 Shared Memory IPC Resources 36 • Kernel Implementation (ipc/shm.c) SYSCALL_DEFINE3(shmget, key_t, key, size_t, size, int, shmflg) { struct ipc_namespace *ns; struct ipc_ops shm_ops; struct ipc_params shm_params; newsegns ()= functioncurrent -allocates>nsproxy new->ipc_ns shared; memory to ids as invoked via ipcget() shm_ops.getnew = newseg; shm_ops.associate = shm_security; shm_ops.more_checks = shm_more_checks; shm_params.key = key; shm_params.flg = shmflg; shm_params.u.size = size; return ipcget(ns, &shm_ids(ns), &shm_ops, &shm_params); } Embedded Software Lab. 22 newseg() (ipc/shm.c) 36 ipc_ids represent IPC Resources Type struct idr ipcs_idr shmid_kernel kern_ipc_prem shmid_kernel kern_ipc_prem State represent State represent Share Memory IPC Resources Share Memory IPC Resources File Object File Object Embedded Software Lab. 23 Other IPCs in Linux 36 • POSIX IPC Mechanism – Same interface as System V IPC – Implemented in independent pool from System V IPC – Implemented not through key-identifier design but through file-based design – Event-driven support (epoll event) • Unix Domain Socket – General purpose IPC • Socket supports not only IPC but also diverse network protocols. – Simple code style, but high overhead compared to other IPC mechanisms. Embedded Software Lab. 24 Tizen Platform IPC 36 • Various IPC methods are used in Tizen. – D-Bus – vconf – socket – pipe • Old Tizen (2.0, 2.1) used socket and pipe for IPC. • Recent Tizen (2.3~, 3.x) is adopting dbus and vconf for IPC. – Socket D-Bus: system server, AUL, alarm manager, connectivity manager, BlueZ, NFC manager, … Embedded Software Lab. 25 D-Bus 36 • Inter-process communication (IPC) mechanism using socket – Simplify the IPC requirements with single shared channel – Access control using SMACK Fig. 1 IPC without D-Bus Fig. 3 D-Bus and SMACK Fig. 2 IPC with D-Bus Embedded Software Lab. 26 D-Bus Access Control 36 • Access control using SMACK (Simplified Mandatory Access Control Kernel) – dbus daemon allow setting the policy to apply using configuration files explicitly – Set allow or deny interface/destination <busconfig> <policy smack="bluez"> <allow own="org.bluez"/> </policy> <policy smack="bt_agent::public"> <allow send_destination="org.bluez" send_interface="org.bluez.ProfileManager1" send_member="RegisterProfile1"/> </policy>
Load more

Recommended publications
  • A Practical UNIX Capability System
    A Practical UNIX Capability System Adam Langley <[email protected]> 22nd June 2005 ii Abstract This report seeks to document the development of a capability security system based on a Linux kernel and to follow through the implications of such a system. After defining terms, several other capability systems are discussed and found to be excellent, but to have too high a barrier to entry. This motivates the development of the above system. The capability system decomposes traditionally monolithic applications into a number of communicating actors, each of which is a separate process. Actors may only communicate using the capabilities given to them and so the impact of a vulnerability in a given actor can be reasoned about. This design pattern is demonstrated to be advantageous in terms of security, comprehensibility and mod- ularity and with an acceptable performance penality. From this, following through a few of the further avenues which present themselves is the two hours traffic of our stage. Acknowledgments I would like to thank my supervisor, Dr Kelly, for all the time he has put into cajoling and persuading me that the rest of the world might have a trick or two worth learning. Also, I’d like to thank Bryce Wilcox-O’Hearn for introducing me to capabilities many years ago. Contents 1 Introduction 1 2 Terms 3 2.1 POSIX ‘Capabilities’ . 3 2.2 Password Capabilities . 4 3 Motivations 7 3.1 Ambient Authority . 7 3.2 Confused Deputy . 8 3.3 Pervasive Testing . 8 3.4 Clear Auditing of Vulnerabilities . 9 3.5 Easy Configurability .
    [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]
  • 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]
  • Inter-Process Communication, Analysis, Guidelines and Its Impact on Computer Security
    The 7th International Conference for Informatics and Information Technology (CIIT 2010) INTER-PROCESS COMMUNICATION, ANALYSIS, GUIDELINES AND ITS IMPACT ON COMPUTER SECURITY Zoran Spasov Ph.D. Ana Madevska Bogdanova T-Mobile Macedonia Institute of Informatics, FNSM Skopje, Macedonia Skopje, Macedonia ABSTRACT Finally the conclusion will offer a summary of the available programming techniques and implementations for the In this paper we look at the inter-process communication Windows platforms. We will note the security risks and the (IPC) also known as inter-thread or inter-application best practices to avoid them. communication from other knowledge sources. We will look and analyze the different types of IPC in the Microsoft II. INTER -PROCESS COMMUNICATION (IPC) Windows operating system, their implementation and the usefulness of this kind of approach in the terms of Inter-Process Communication (IPC) stands for many communication between processes. Only local techniques for the exchange of data among threads in one or implementation of the IPC will be addressed in this paper. more processes - one-directional or two-directional. Processes Special emphasis will be given to the system mechanisms that may be running locally or on many different computers are involved with the creation, management, and use of connected by a network. We can divide the IPC techniques named pipes and sockets. into groups of methods, grouped by their way of This paper will discuss some of the IPC options and communication: message passing, synchronization, shared techniques that are available to Microsoft Windows memory and remote procedure calls (RPC). We should programmers. We will make a comparison between Microsoft carefully choose the IPC method depending on data load that remoting and Microsoft message queues (pros and cons).
    [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]
  • Open Message Queue Technical Overview Release 5.0
    Open Message Queue Technical Overview Release 5.0 May 2013 This book provides an introduction to the technology, concepts, architecture, capabilities, and features of the Message Queue messaging service. Open Message Queue Technical Overview, Release 5.0 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).
    [Show full text]
  • Sockets in the Kernel
    Linux Kernel Networking – advanced topics (6) Sockets in the kernel Rami Rosen [email protected] Haifux, August 2009 www.haifux.org All rights reserved. Linux Kernel Networking (6)- advanced topics ● Note: ● This lecture is a sequel to the following 5 lectures I gave in Haifux: 1) Linux Kernel Networking lecture – http://www.haifux.org/lectures/172/ – slides:http://www.haifux.org/lectures/172/netLec.pdf 2) Advanced Linux Kernel Networking - Neighboring Subsystem and IPSec lecture – http://www.haifux.org/lectures/180/ – slides:http://www.haifux.org/lectures/180/netLec2.pdf Linux Kernel Networking (6)- advanced topics 3) Advanced Linux Kernel Networking - IPv6 in the Linux Kernel lecture ● http://www.haifux.org/lectures/187/ – Slides: http://www.haifux.org/lectures/187/netLec3.pdf 4) Wireless in Linux http://www.haifux.org/lectures/206/ – Slides: http://www.haifux.org/lectures/206/wirelessLec.pdf 5) Sockets in the Linux Kernel ● http://www.haifux.org/lectures/217/ – Slides: http://www.haifux.org/lectures/217/netLec5.pdf Note ● Note: This is the second part of the “Sockets in the Linux Kernel” lecture which was given in Haifux in 27.7.09. You may find some background material for this lecture in its slides: ● http://www.haifux.org/lectures/217/netLec5.pdf TOC ● TOC: – RAW Sockets – UNIX Domain Sockets – Netlink sockets – SCTP sockets. – Appendices ● Note: All code examples in this lecture refer to the recent 2.6.30 version of the Linux kernel. RAW Sockets ● There are cases when there is no interface to create sockets of a certain protocol (ICMP protocol, NETLINK protocol) => use Raw sockets.
    [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]
  • Interprocess Communication
    06 0430 CH05 5/22/01 10:22 AM Page 95 5 Interprocess Communication CHAPTER 3,“PROCESSES,” DISCUSSED THE CREATION OF PROCESSES and showed how one process can obtain the exit status of a child process.That’s the simplest form of communication between two processes, but it’s by no means the most powerful.The mechanisms of Chapter 3 don’t provide any way for the parent to communicate with the child except via command-line arguments and environment variables, nor any way for the child to communicate with the parent except via the child’s exit status. None of these mechanisms provides any means for communicating with the child process while it is actually running, nor do these mechanisms allow communication with a process outside the parent-child relationship. This chapter describes means for interprocess communication that circumvent these limitations.We will present various ways for communicating between parents and chil- dren, between “unrelated” processes, and even between processes on different machines. Interprocess communication (IPC) is the transfer of data among processes. For example, a Web browser may request a Web page from a Web server, which then sends HTML data.This transfer of data usually uses sockets in a telephone-like connection. In another example, you may want to print the filenames in a directory using a command such as ls | lpr.The shell creates an ls process and a separate lpr process, connecting 06 0430 CH05 5/22/01 10:22 AM Page 96 96 Chapter 5 Interprocess Communication the two with a pipe, represented by the “|” symbol.A pipe permits one-way commu- nication between two related processes.The ls process writes data into the pipe, and the lpr process reads data from the pipe.
    [Show full text]
  • Interprocess Communications (Pipes)
    Multiple methods for Interprocess Communications Three examples: files, pipes, shared memory. In this figure, Local domain sockets would be conceptually similar to a named pipe. The second method refers to pipes Sources for these slides include: • W. Stevens, Unix Network Programming, Volumes 1 and 2 • M. Mitchell, J. Oldham, A. Samuel, Advanced Linux Programming 1 Interprocess Communication (IPC) ⚫ Linux supports the following IPC mechanisms: – Half duplex pipes – Full duplex pipes –only by using 2 pipes (other unix systems do support FD over a single pipe) – FIFOS (also called named pipes) – SYSV style message queues – SYSV style shared memory – Local Domain (UNIX Domain) sockets – Similar to a socket but modifications to the address/name aspect. (PF_LOCAL rather than PF_INET). – Sockets: Two processes can communicate using localhost. But it’s more efficient to use 2 pipes or local domain sockets. Pipe – used in a shell pipeline ⚫ Example of a pipeline - issue the following in a shell: – who | sort | wc 2 10 110 – The shell program creates three processes, two pipes are used as shown below. – The shell would use the dup2 call to duplicate the read end of each pipe to standard input and the write end to standard output. ⚫ int fd[2]; ⚫ pid_t pid; ⚫ pipe(fd); ⚫ pid = fork(); ⚫ If(pid == 0) { – dup2(fd[0], STDIN_FILENO); – exec(whatever); ⚫ } ⚫ The use of dup2 by a shell allows a program or filter to simply operate on data arriving through standard in….and sends output to standard out. It does not need to know the pipe descriptors involved…. 3 – Note – modified the pipeline- the figure assumes lp instead of wc .
    [Show full text]
  • Interacting Modelica Using a Named Pipe for Hardware-In-The-Loop Simulation
    Interacting Modelica using a Named Pipe for Hardware-in-the-loop Simulation Interacting Modelica using a Named Pipe for Hardware-in-the-loop Simulation Arno Ebner Anton Haumer Dragan Simic Franz Pirker Arsenal Research Giefinggasse 2, 1210 Vienna, Austria phone: +43 50550 6663, fax: +43 50550 6595, e-mail: [email protected] Abstract tion for the system model considering the initial val- ues. The paper presents a concept and an implementation In some cases the user or other applications have to of Modelica simulation interaction using the operat- interact with the simulation, for example to: ing system inter-process communication method of • Start or interrupt the simulation the Named Pipe. The main aim of this presented • Change parameters or variables during the simu- work is to implement a hardware-in-the-loop simula- lation tion (HILS) environment based on Dymola which • Communicate with other applications, for exam- runs on a normal Microsoft Windows Personal Com- ple with another simulation environment puter. • Exchange data with an input/output-card or a pe- An energy storage test bench is connected by an ana- ripheral communication interface logue and digital data input/output card with the Dy- • Build up a hardware-in-the-loop simulation envi- mola simulation computer. With this proposed sys- ronment tem, particularly long-time simulations with sample rates up to 30 Hz can be executed very cost effective. Hardware-in-the-loop (HIL) is the integration of real Typical applications are simulations of drive cycles components and system models in a common simu- to test energy storage systems in electrified vehicles lation environment [1].
    [Show full text]
  • Multiprocess Communication and Control Software for Humanoid Robots Neil T
    IEEE Robotics and Automation Magazine Multiprocess Communication and Control Software for Humanoid Robots Neil T. Dantam∗ Daniel M. Lofaroy Ayonga Hereidx Paul Y. Ohz Aaron D. Amesx Mike Stilman∗ I. Introduction orrect real-time software is vital for robots in safety-critical roles such as service and disaster response. These systems depend on software for Clocomotion, navigation, manipulation, and even seemingly innocuous tasks such as safely regulating battery voltage. A multi-process software design increases robustness by isolating errors to a single process, allowing the rest of the system to continue operating. This approach also assists with modularity and concurrency. For real-time tasks such as dynamic balance and force control of manipulators, it is critical to communicate the latest data sample with minimum latency. There are many communication approaches intended for both general purpose and real-time needs [19], [17], [13], [9], [15]. Typical methods focus on reliable communication or network-transparency and accept a trade-off of increased mes- sage latency or the potential to discard newer data. By focusing instead on the specific case of real-time communication on a single host, we reduce communication latency and guarantee access to the latest sample. We present a new Interprocess Communication (IPC) library, Ach,1 which addresses this need, and discuss its application for real-time, multiprocess control on three humanoid robots (Fig. 1). There are several design decisions that influenced this robot software and motivated development of the Ach library. First, to utilize decades of prior development and engineering, we implement our real-time system on top of a POSIX-like Operating System (OS)2.
    [Show full text]