DOCSLIB.ORG

Diploma Thesis RTAI Networking Mailboxes

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Diploma Thesis RTAI Networking Mailboxes Diploma Thesis RTAI Networking Mailboxes Víctor Rafael Escobar Olmos Submitted on 10.08.2011 Institut I2AR Hochschule Emden / Leer Faculty of engineering Course of studies Computer Software Engineering Diploma Thesis Topic of Diploma Thesis: Create an API to communicate nodes from Real Time tasks, using the user network libraries. Presented by: Name, first name Birthday: in: Escobar Olmos, Víctor Rafael (5025774) 18.11.1986 Barcelona Examiner: Prof. Dr. Uwe Schmidtmann Second examiner: Dipl. Ing. Matthias Wermann Start date: 01.06.2010 Submission deadline: 10.08.2011 The work was the examination board or a person entitled filed in: E R K L Ä R U N G (Official statement) Soweit meine Rechte berührt sind, erkläre ich mich einverstanden, dass die Diploma Thesis Angehörigen der Hochschule Emden / Leer für Studium / Lehre / Forschung uneingeschränkt zugänglich gemacht werden kann. E I D E S S T A T T L I C H E E R K L Ä R U N G (Affidavit) Hiermit erkläre ich an Eides statt, dass ich die vorliegende Diploma Thesis bis auf die of- fizielle Betreuung selbst und ohne fremde Hilfe angefertigt habe und die benutzten Quellen und Hilfsmittel vollständig angegeben sind. Datum, Unterschrift (Víctor Rafael Escobar Olmos) Prüfungskommissionssitzung vom 14. März 2008 Beschluss: 140408/3 5 : 0 : 0 Abstract The task was to design and implement a mailbox system with a public API for Real Time Linux Tasks, using only the user net- work functions for compatibility with the unsupported natively network cards for the Real Time Linux. Extracte La tasca va consistir en dissenyar i implementar un sistema de bústies de correu amb una API pública per a tasques de Real Time Linux, utilitzant només les funcions de xarxa d’usuari per a la compatibilitat amb les targetes de xarxa no suportades nativament per Real Time Linux. Keywords (paraules clau): RTAI, Linux, real time application interface, real time computing, programming in real-time environment, real-time communication, real-time mailboxes. Acknowledgements My sincere thanks to Dipl. Ing. Wermann, Prof. Dr. Schmidtmann and Prof. Dr. Tomaschewski the given chance of working on this project. I am also grateful for the daily support and all the funny moments that I had at the labora- tories E13 and E14 with my colleagues: Jeffrey, Carlos, Kevin, Patrick and the coffee machine. A special thank to Antonio, who gave more help than I could expect from a friend. Finally, a last thank to my family. Contents Contents 1 Introduction 1 1.1 Objectives and justification . .1 2 Basic Information 2 2.1 Used Technology . .2 2.1.1 Real Time Linux and Real Time API Interface . .2 2.2 Technology and software used . .2 3 Analysis and specification 3 3.1 General Description . .3 3.1.1 Glossary and definitions . .3 3.1.2 Project Overview . .4 3.1.3 Project Features and requirements . .4 3.2 Restrictions . .4 3.2.1 Hardware restrictions . .4 3.2.2 Customer restrictions . .5 3.2.3 Software restrictions . .6 3.3 Assumptions and dependencies . .7 4 Design and Solutions 9 4.1 Design decisions . .9 4.2 Software Components based on classes . .9 4.3 Static Vision . 11 4.3.1 Use Cases . 11 4.4 Dynamic Vision . 13 4.4.1 Sequence diagrams . 13 5 Implementation 28 5.1 Previous considerations about the implementation . 28 5.1.1 C Programming language . 28 5.1.2 Coding style . 28 5.1.3 Note about why are a lot of pointers to pointers . 29 5.1.4 Messages and buffers . 31 5.2 Implementation decisions . 32 5.2.1 The Real Time FIFOs and FIFO Handlers . 32 5.2.2 The Internet protocol . 33 5.2.3 Concurrency . 34 5.2.4 Data structures . 36 5.3 Software Components and Classes . 37 5.3.1 Queue . 37 5.3.2 LinuxThread Structure (LTS) . 37 5.3.3 Operation Table (optab) . 38 i Contents 5.3.4 Name IP Table (NIT) . 40 5.3.5 Local Name Table (LNT) . 40 5.3.6 Net Name Table (NNT) . 41 5.4 Macros like functions and customization of some options . 41 5.4.1 Macros like functions . 42 5.4.2 Customization of some options . 42 6 Testing 44 6.1 Tests . 44 6.1.1 Individual testing . 44 6.1.2 Global testing . 44 6.2 Issues and bugs found . 45 Unexpected hang up for segmentation fault: . 45 An Internet packet lost: . 45 Three nodes hangs up at time to load the module: . 45 7 Instalation and User Manual 46 7.1 Installation process . 46 7.1.1 Dependences . 46 7.1.2 Building the rt_net_mbx binaries . 46 7.2 Execution of the program . 47 7.2.1 Load the kernel module . 47 7.2.2 The daemon, the arguments and the configuration file . 48 7.2.3 Load an End User Kernel Module . 49 7.3 How to make an End User Module . 49 7.3.1 Compile a Module . 49 7.3.2 Example of an End User Module . 50 7.3.3 How to load the Module . 55 8 Conclusions 56 9 Bibliography 58 10 Appendix 59 10.1 Public API . 59 10.1.1 Previous considerations . 59 10.1.2 Functions . 59 ii List of Figures List of Figures 1 Original purposed communication map . .5 2 Communication map . .8 3 Sequence diagram: rt_net_mbx_create . 14 4 Sequence diagram: NNT adding a Mailbox . 15 5 Sequence diagram: rt_net_mbx_send the mailbox is on the local node . 16 6 Sequence diagram: rt_net_mbx_send the mailbox does not exist . 17 7 Sequence diagram: rt_net_mbx_send the mailbox exist on a remote node, lo- cal node at kernel space . 18 8 Sequence diagram: rt_net_mbx_send the mailbox exist on a remote node, lo- cal node at user space . 19 9 Sequence diagram: rt_net_mbx_send the mailbox exist on a remote node, re- mote node at user space . 20 10 Sequence diagram: rt_net_mbx_send the mailbox exist on a remote node, re- mote node at kernel space . 21 11 Sequence diagram: rt_net_mbx_exist . 23 12 Sequence diagram: rt_net_mbx_receive . 24 13 Sequence diagram: rt_net_mbx_delete . 26 14 Sequence diagram: NNT deleting a Mailbox . 27 15 Stack when an external initialization has been bad. 30 16 Stack when an external initialization has been good. 31 iii Source codes Source codes 1 Class Queue . 29 2 Kernighan&Ritchie/Kernel code style . 29 3 Basic code style . 29 4 How should not be initialized a variable inside an external function . 30 5 How should be initialized a variable inside an external function . 31 6 Example of buffer to send a message over the network . 31 7 FIFO Handler creation for a RT Task . 33 8 Create a thread and wait for it using the LTS . 38 9 Makefile . 46 10 Check if the RTAI module was previously loaded. 48 11 Load the rtainetd daemon. 48 12 Example of configuration file . 49 13 Example of Makefile for an external module . 49 14 Example of end user module . 50 iv 1 INTRODUCTION 1 Introduction 1.1 Objectives and justification The objective of this project is to design and implement a software solution for the Real Time Linux computers connected to the MPS System made by Festo Didactic GmbH1 placed in the the laboratory for distributed operating systems and applications of the Hochschule Em- den/Leer 2. The MPS System is a flexible manufacturing system model that allows the students of com- puter science and electrical engineering of the Hochschule Emden / Leer to learn the possibil- ities of program in a Real Time system. This system has nine modbus nodes, industrial computers with Real Time Linux, three of them are S-MAX 5006 CE PB from the company Phoenix Contact3 and the other six are SIMATIC Microbox PC from Siemens. The nodes from Siemens have a network card Via-Rhine III which does not have a compatible driver module for Real Time Linux RTNet4 but it also has a compatible driver module for the Linux Kernel. That means that the networking card do not work for the Real Time calls and the manufacturer of the Rhine Network Card5 does not support and provide any compatible Real Time Linux driver for them. To allow the students to have the possibility of use the RTAI functions in a network context with the current hardware, appears the justification of this project: to find alternative ways to communicate the RTAI Tasks between nodes and implement it. During the current document it will be explained how it was possible to design and implement a network system of mailboxes to communicate the Real Time Tasks of all the nodes of the MPS System. 1Festo Didactic GmbH http://www.festo-didactic.com 2Abteilung Technik, Fachbereich Elektrotechnik und Informatik, Labor für verteilte Betriebssysteme und App- likationen. 3Phoenix Contact Deutschland GmbH http://www.phoenixcontact.de 4List of supported Network Adapters by the project RTNet: http://www.rtnet.org/doc.html [9]. 5VIA Technologies, Inc http://www.via.com.tw/en/support/drivers.jsp. 1 2 BASIC INFORMATION 2 Basic Information 2.1 Used Technology 2.1.1 Real Time Linux and Real Time API Interface In computer science, when we refer to the term Real Time operative system it means that the operations that this OS execute will be executed inside of a strict time interval using an optimized algorithm for scheduling to have a much better response. It means that the time of the operation are predictably; or as fast as possible. Some example of uses of real time operative system can be all the systems that need a response inside an interval like the software that controls a motor, or a nuclear plant.
Load more

Recommended publications
  • Acceleration of Applications with FPGA-Based Computing Machines: Code Restructuring
    FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO Acceleration of Applications with FPGA-Based Computing Machines: Code Restructuring Tiago Lascasas dos Santos Mestrado Integrado em Engenharia Informática e Computação Supervisor: João M. P. Cardoso, PhD Co-supervisor: João Bispo, PhD July 31, 2020 c Tiago Santos, 2020 Acceleration of Applications with FPGA-Based Computing Machines: Code Restructuring Tiago Lascasas dos Santos Mestrado Integrado em Engenharia Informática e Computação Approved in oral examination by the committee: Chair: Prof. João Paulo de Castro Canas Ferreira, PhD External Examiner: Dr. José Gabriel de Figueiredo Coutinho, PhD Supervisor: Prof. João Manuel Paiva Cardoso, PhD July 31, 2020 Abstract Field-programmable gate arrays (FPGAs) can be used to accelerate performance-critical programs from a wide range of fields and still providing energy-efficient solutions. Programs written in high level languages, such as C and C++, can be compiled to FPGAs through High-level Synthesis (HLS). Although FPGAs benefit the most from parallel and data-streaming applications, efficient compilation to FPGAs is a problem for both tools and developers. Most applications do not follow these patterns, and extensive code restructuring and the use of HLS directives need to be applied to a program in order to take advantage of FPGAs. Code restructuring and the use of HLS directives often needs to be manually performed by an experienced developer, and as such there is a need to automate this process. This dissertation proposes a framework that automatically optimizes C code via directives, using a source-to-source compiler on a stage prior to HLS. This optimization is primarily applied by strategies that select, configure and insert directives on the code to be input to an HLS tool, e.g., Vivado HLS, in order to synthesize more efficient hardware accelerators.
    [Show full text]
  • Linux DVB API Version 4
    Linux DVB API Version 4 http://www.linuxdvb.org v 0.3 April 15, 2005 Copyright c 2004,2005 The Linux DVB developers Written by Michael Hunold <[email protected]> Parts are based on the Linux DVB API Version 3 documentation, released under the GNU Free Documentation License. Written by Dr. Ralph J.K. Metzler and Dr. Marcus O.C. Metzler. Copyright 2002, 2003 Convergence GmbH. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation. http://www.gnu.org/licenses/fdl.html Contents 1 Introduction 1 1.1 Goals ....................................... 1 1.2 Related technologies ............................... 2 1.3 History ...................................... 2 2 Design 4 2.1 Present situation ................................. 4 2.2 Linux DVB API Version 3 problems ...................... 4 2.3 Linux DVB API Version 3 vs. Version 4 .................... 5 3 Concepts 6 3.1 Control concept .................................. 6 3.2 Capability concept ................................ 6 3.3 Connection concept ................................ 6 3.4 Status concept .................................. 7 4 Frontend API 8 4.1 Device informations ............................... 8 4.2 Satellite equipment control (SEC) commands ................ 9 4.3 DiSEqC commands ............................... 11 4.4 Frontend status ................................. 12 4.5 Configuration and tuning ........................... 12 4.6 Event handling ................................. 14 5 Memory input API 15 5.1 Device informations ............................... 15 5.2 Configuration .................................. 15 5.3 Data input .................................... 16 6 Demux API 17 6.1 Capabilities ................................... 18 6.2 Device input setup ............................... 19 6.3 MPEG-2 TS filters ............................... 19 6.3.1 TS decoder feeds ............................ 20 6.3.2 Pid filters ...............................
    [Show full text]
  • Windows Internals, Sixth Edition, Part 2
    spine = 1.2” Part 2 About the Authors Mark Russinovich is a Technical Fellow in ® the Windows Azure™ group at Microsoft. Windows Internals He is coauthor of Windows Sysinternals SIXTH EDITION Administrator’s Reference, co-creator of the Sysinternals tools available from Microsoft Windows ® The definitive guide—fully updated for Windows 7 TechNet, and coauthor of the Windows Internals and Windows Server 2008 R2 book series. Delve inside Windows architecture and internals—and see how core David A. Solomon is coauthor of the Windows Internals book series and has taught components work behind the scenes. Led by a team of internationally his Windows internals class to thousands of renowned internals experts, this classic guide has been fully updated Windows developers and IT professionals worldwide, SIXTH for Windows 7 and Windows Server® 2008 R2—and now presents its including Microsoft staff. He is a regular speaker 6EDITION coverage in two volumes. at Microsoft conferences, including TechNet As always, you get critical, insider perspectives on how Windows and PDC. operates. And through hands-on experiments, you’ll experience its Alex Ionescu is a chief software architect and internal behavior firsthand—knowledge you can apply to improve consultant expert in low-level system software, application design, debugging, system performance, and support. kernel development, security training, and Internals reverse engineering. He teaches Windows internals courses with David Solomon, and is ® In Part 2, you will: active in the security research community.
    [Show full text]
  • Implementing IBM Flashsystem 900 Model AE3
    Front cover Implementing IBM FlashSystem 900 Model AE3 Detlef Helmbrecht Jim Cioffi Jon Herd Jeffrey Irving Christian Karpp Volker Kiemes Carsten Larsen Adrian Orben Redbooks International Technical Support Organization Implementing IBM FlashSystem 900 Model AE3 March 2018 SG24-8414-00 Note: Before using this information and the product it supports, read the information in “Notices” on page ix. First Edition (March 2018) This edition applies to the IBM FlashSystem 900 Model AE3. © Copyright International Business Machines Corporation 2018. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . ix Trademarks . .x Preface . xi Authors. xi Now you can become a published author, too! . xiv Comments welcome. xiv Stay connected to IBM Redbooks . xiv Chapter 1. Introduction to FlashSystem . 1 1.1 FlashSystem storage overview . 3 1.2 IBM FlashCore technology . 4 1.2.1 IBM Piece of Mind Initiative. 5 1.3 Why flash technology matters . 6 1.4 IBM FlashSystem family product differentiation . 7 1.5 Technology and architectural design overview . 8 1.5.1 Hardware-only data path. 9 1.5.2 3DTLC flash memory chips. 10 1.5.3 Flash module capacities . 10 1.5.4 Gateway interface FPGA . 11 1.5.5 Flash controller FPGA. 11 1.5.6 IBM Variable Stripe RAID and 2D Flash RAID overview . 12 1.5.7 Inline hardware data compression . 14 1.5.8 Encryption . 14 1.6 Usability plus reliability, availability, and serviceability enhancements . 16 1.6.1 Automatic battery reconditioning. 16 1.6.2 Remote Support Assistance .
    [Show full text]
  • Locks and Raspberries: a Comparative Study of Single-Board Computers for Access Control
    UPTEC F 16013 Examensarbete 30 hp April 2016 Locks and raspberries: a comparative study of single-board computers for access control Andreas Romin Abstract Locks and raspberries: a comparative study of single-board computers for access control Andreas Romin Teknisk- naturvetenskaplig fakultet UTH-enheten Over the past decade, there has been a drastic development of the single-board computer market. These computers are now in a position where they can compete Besöksadress: with classic embedded hardware. Such fast improvement has led ASSA ABLOY, a Ångströmlaboratoriet Lägerhyddsvägen 1 well-known lock and security company, to see value in replacing some of their Hus 4, Plan 0 existing access control hardware with an off-the-shelf single-board computer. Therefore, a comparative study of single-board computers was performed for this Postadress: company. Some of the compared properties were price, performance (i.e. CPU, Box 536 751 21 Uppsala memory, USB, network, operating temperature and power consumption) and other relevant information such as operating systems, open/closed source hardware and Telefon: future availability. Information and testing data from nine different computers was 018 – 471 30 03 compiled and analyzed. This data was then used to determine the best-suited Telefax: candidates that could possibly replace the current access control hardware. They 018 – 471 30 00 were chosen in accordance to three different categories: performance, power consumption and open source hardware. The ODROID C1+, the Raspberry Pi A+ Hemsida: and the A20 OLinuXino Lime2 proved to be the best candidates for these three http://www.teknat.uu.se/student categories respectively. Furthermore, it was also concluded that the company behind a computer is just as important as the computer itself, where the best company in this study was determined to be Olimex.
    [Show full text]
  • Introduction to 64 Bit Intel Assembly Language Programming for Linux
    Introduction to 64 Bit Intel Assembly Language Programming for Linux Introduction to 64 Bit Intel Assembly Language Programming for Linux Ray Seyfarth October 27, 2011 Ray Seyfarth School of Computing University of Southern Mississippi Hattiesburg, MS 39406 USA Seyfarth, Ray Introduction to 64 Bit Intel Assembly Language Programming Includes index. ISBN-13: 978-1466470033 ISBN-10: 1466470038 @2011 Ray Seyfarth All rights reserved. This work may not be translated or copied in whole or in part without the written permission of the copyright holder, except for brief excerpts in connection with reviews or scholarly analyses. Preface The Intel CPU architecture has evolved over 3 decades fr om a 16 bit CPU with no memory protection, through a period with 32 bit processors with sophisticated architectures into the current series of processors which support all the old modes of operation in addition to a greatly expanded 64 bit mode of operation. Assembly textbooks tend to focus on the history and generally conclude with a discussion on the 32 bit mode. Students are introduced to the concepts of 16 bit CPUs with segment registers allowing access to 1 megabyte of internal memory. This is an unnecessary fo cus on the past. With the x86-64 architecture there is almost a complete departure from the past. Segment registers are essentially obsolete and more reg­ ister usage is completely general purpose, with the glaring exception of the repeat-string loops which use specific registers and have no operands. Both these changes contribute to simpler assembly language program­ mmg. There are now 16 general purpose integer registers with a few spe­ cialized instructions.
    [Show full text]
  • The Potential of Dynamic Binary Modification and CPU- FPGA Socs for Simulation
    The University of Manchester Research The Potential of Dynamic Binary Modification and CPU- FPGA SoCs for Simulation DOI: 10.1109/FCCM.2017.36 Document Version Accepted author manuscript Link to publication record in Manchester Research Explorer Citation for published version (APA): Mawer, J., Palomar, O., Gorgovan, C., Nisbet, A., & Luján, M. (2017). The Potential of Dynamic Binary Modification and CPU-FPGA SoCs for Simulation. In The 25th IEEE International Symposium on Field- Programmable Custom Computing Machines https://doi.org/10.1109/FCCM.2017.36 Published in: The 25th IEEE International Symposium on Field-Programmable Custom Computing Machines Citing this paper Please note that where the full-text provided on Manchester Research Explorer is the Author Accepted Manuscript or Proof version this may differ from the final Published version. If citing, it is advised that you check and use the publisher's definitive version. General rights Copyright and moral rights for the publications made accessible in the Research Explorer are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Takedown policy If you believe that this document breaches copyright please refer to the University of Manchester’s Takedown Procedures [http://man.ac.uk/04Y6Bo] or contact [email protected] providing relevant details, so we can investigate your claim. Download date:04. Oct. 2021 The Potential of Dynamic Binary Modification and CPU-FPGA SoCs for Simulation John Mawer, Oscar Palomar, Cosmin Gorgovan, Andy Nisbet, Will Toms and Mikel Lujan´ School of Computer Science, University of Manchester, UK ffi[email protected] Abstract—In this paper we describe a flexible infrastructure early in the development cycle.
    [Show full text]
  • Build Your Own Ambilight - 11
    Install Linux on an External Disk • eMMC Recovery • GPIO Shutdown Year Two Issue #16 Apr 2015 ODROIDMagazine KALIKALI LinuxLinuxODROID’sODROID’s advancedadvanced penetrationpenetration testingtesting distributiondistribution Build • Automate your house with OpenHAB your • ODROID-C1 triple boot own • Android Dev: Low Memory Killer Daemon Ambilight • Play the original Warcraft series on Linux What we stand for. We strive to symbolize the edge of technology, future, youth, humanity, and engineering. Our philosophy is based on Developers. And our efforts to keep close relationships with developers around the world. For that, you can always count on having the quality and sophistication that is the hallmark of our products. Simple, modern and distinctive. So you can have the best to accomplish everything you can dream of. We are now shipping the ODROID U3 devices to EU countries! Come and visit our online store to shop! Address: Max-Pollin-Straße 1 85104 Pförring Germany Telephone & Fax phone : +49 (0) 8403 / 920-920 email : [email protected] Our ODROID products can be found at http://bit.ly/1tXPXwe EDITORIAL ali Linux is one of our favorite distributions, as it in- cludes a wide variety of security penetration testing Ksoftware. Offensive Security, the developers of Kali, are ODROID fans, and have released a version for every model so far. Kali on the ODROID can be the basis for a lucrative busi- ness, offering something that every company needs: peace of mind. Learn how to install Kali Linux on the ODROID-C1,and you may be able to offer affordable security testing with minimum startup costs. Also featured is another amazing technical guide by Venkat showing us how to make our homes smarter using OpenHAB, as well as a tutorial by Marian on Ambilight, which makes it more fun to watch videos and listen to music.
    [Show full text]
  • Reactos Suspends Development for Source Code Review - Linux.Com Reactos Suspends Development for Source Code Review by - February 1, 2006
    8/20/2020 ReactOS suspends development for source code review - Linux.com ReactOS suspends development for source code review By - February 1, 2006 Author: Stephen Feller The ReactOS team has suspended development to do a code review amid concerns that stolen code from the world’s most used OS found its way into the project. ReactOS, the 10-year-old project to create a functional, free, and open source version of Windows NT, suspended development on January 27 after a meeting to discuss whether leaked code had been added to the project’s code base. The OS also will not be available for download while developers perform a full review of the 3 million or so lines in the ReactOS code base. A letter posted to the ReactOS Web site included three specific tasks developers will take on as a result of the concerns: Clarify the ReactOS Intellectual Property Policy Statement requirements for clean room reverse engineering to conform to those required by US law; audit the ReactOS code base and rewrite any code that was not implemented along the clarified guidelines; and require developers contributing major code to the project to sign a document that says they agree to the project’s policies. According to Steven Edwards, the recently elected project coordinator for ReactOS, developers on the project have raised the possibility that a developer had reverse-engineered a part of the Windows code in violation of US copyright and trade secrecy laws and practices. Leaks of parts of the source code for Windows 2000 and NT have been circulating on the Internet for a few years, but “there is nothing in the code base that we believe is a copy and paste from a leaked bad source,” Edwards said.
    [Show full text]
  • A Crack on the Glass Evaluation of Consumer Windows OS Security Architecture and Its Feasibility As a Potential Isolation Provider for "Qubes Windows Lite"
    A crack on the glass Evaluation of consumer Windows OS security architecture and its feasibility as a potential isolation provider for "Qubes Windows Lite" “Well, dreams, they feel real while we're in them right? Its only when we wake up then we realize that something was actually strange.” -- Cobb, Inception Abstract In this paper we describe our attempt at creating Qubes Windows Native Isolation system, which is a collection of isolated application containers. We discuss the project requirements, what technical means are needed to implement such system and why the available Windows APIs and system architecture is not appropriate for the task. Rafał Wojdyła, Invisible Things Lab [email protected] Page 1 1. Introduction to Qubes OS Qubes OS strives to provide strong desktop security by isolation [1]. Having separate domains dedicated to different tasks helps to mitigate potential attacks – a PDF exploit coming from an untrusted site that compromises “public” domain will not affect “work” domain provided they are properly isolated. Qubes R2 is built on top of a Linux host and Xen hypervisor – domains are implemented as lightweight VMs administered from the trusted one, traditionally called dom0. This of course implies we trust that Xen-provided isolation is good, but one needs to start somewhere. The next iteration of Qubes is built on top of the Odyssey framework [2] – the goal of which is to decouple Qubes core from Xen. Qubes Odyssey uses the libvirt [3] project to implement a hypervisor abstraction layer. That means we can replace Xen with a different virtual machine manager (VMM) – Hyper-V, Virtual Box, VMWare or others.
    [Show full text]
  • Free and Open Source Software
    Free and open source software Copyleft ·Events and Awards ·Free software ·Free Software Definition ·Gratis versus General Libre ·List of free and open source software packages ·Open-source software Operating system AROS ·BSD ·Darwin ·FreeDOS ·GNU ·Haiku ·Inferno ·Linux ·Mach ·MINIX ·OpenSolaris ·Sym families bian ·Plan 9 ·ReactOS Eclipse ·Free Development Pascal ·GCC ·Java ·LLVM ·Lua ·NetBeans ·Open64 ·Perl ·PHP ·Python ·ROSE ·Ruby ·Tcl History GNU ·Haiku ·Linux ·Mozilla (Application Suite ·Firefox ·Thunderbird ) Apache Software Foundation ·Blender Foundation ·Eclipse Foundation ·freedesktop.org ·Free Software Foundation (Europe ·India ·Latin America ) ·FSMI ·GNOME Foundation ·GNU Project ·Google Code ·KDE e.V. ·Linux Organizations Foundation ·Mozilla Foundation ·Open Source Geospatial Foundation ·Open Source Initiative ·SourceForge ·Symbian Foundation ·Xiph.Org Foundation ·XMPP Standards Foundation ·X.Org Foundation Apache ·Artistic ·BSD ·GNU GPL ·GNU LGPL ·ISC ·MIT ·MPL ·Ms-PL/RL ·zlib ·FSF approved Licences licenses License standards Open Source Definition ·The Free Software Definition ·Debian Free Software Guidelines Binary blob ·Digital rights management ·Graphics hardware compatibility ·License proliferation ·Mozilla software rebranding ·Proprietary software ·SCO-Linux Challenges controversies ·Security ·Software patents ·Hardware restrictions ·Trusted Computing ·Viral license Alternative terms ·Community ·Linux distribution ·Forking ·Movement ·Microsoft Open Other topics Specification Promise ·Revolution OS ·Comparison with closed
    [Show full text]
  • Partial Array Self-Refresh in Linux
    Partial Array Self-refresh in Linux Henrik Kjellberg, E05 [email protected] March 7, 2010 Abstract Partial Array Self-refresh is a technique to turn o the memory self- refresh from parts of a memory if it is not used, to reduce the power consumption during idle mode. In this paper I will start with describing what Partial Array Self- refresh is. I will briey describe the memory management in Linux and how it works. I will describe some dierent approaches that can be used to accomplish Partial Array Self-refresh in a Linux environment and then implement one of the approaches. I will also describe what else has to be done to achieve good results from Partial Array Self-refresh in the form of defragmentation and anti-fragmentation. 1 2 Contents 1 Introduction 6 2 Previous work 6 3 Aim of the thesis 7 4 Memory system overview 7 4.1 Paging . 7 4.2 Non-Unied Memory Access . 8 4.3 Virtual memory . 8 4.4 Linux . 8 4.4.1 The Buddy Allocator . 9 4.4.2 The SLAB allocator . 10 5 Design analysis 11 5.1 Disabling of allocations . 12 5.1.1 Memory hotplug . 12 5.1.2 Pre-validate power down . 13 5.2 Defragmentation . 13 5.3 Anti-fragmentation . 14 6 My implementation 15 7 Evaluation 17 7.1 Partial Array Self-refresh (PASR) feasibility . 17 7.2 Overhead . 18 8 The future 19 9 Conclusions 21 10 Acknowledgements 22 Appendix A: Tools 23 A.1 Procfs . 23 A.2 Pasr-info .
    [Show full text]