The Design of the EMPS Multiprocessor Executive for Distributed Computing

Total Page:16

File Type:pdf, Size:1020Kb

The Design of the EMPS Multiprocessor Executive for Distributed Computing The design of the EMPS multiprocessor executive for distributed computing Citation for published version (APA): van Dijk, G. J. W. (1993). The design of the EMPS multiprocessor executive for distributed computing. Technische Universiteit Eindhoven. https://doi.org/10.6100/IR393185 DOI: 10.6100/IR393185 Document status and date: Published: 01/01/1993 Document Version: Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers) Please check the document version of this publication: • A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website. • The final author version and the galley proof are versions of the publication after peer review. • The final published version features the final layout of the paper including the volume, issue and page numbers. Link to publication General rights Copyright and moral rights for the publications made accessible in the public portal 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. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal. If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement: www.tue.nl/taverne Take down policy If you believe that this document breaches copyright please contact us at: [email protected] providing details and we will investigate your claim. Download date: 03. Oct. 2021 The Design of the EMPS Multiprocessor Executive for Distributed Computing The Design of the EMPS Multiprocessor Executive for Distributed Computing PROEFSCHRIFT ter verkrijging van de graad van doctor aan de Technische Universiteit Eindhoven, op gezag van de Rector Magnificus, prof. dr. J.H. van Lint, voor een commissie aangewezen door het College van Dekanen in het openbaar te verdedigen op dinsdag 16 maart 1993 om 16.00 uur door GERARDUS JOHANNES WICHARDUS VAN DIJK geboren te Nijmegen druk: wibra dissertatiecJrukkerij. halmond. Dit proefschrift is goedgekeurd door de promotoren prof. dr. dipl. ing. D.K. Hammer en prof. dr. S.J. Mullender copromotor: dr. ir. K. Kopinga Contents 1 Introduction 1 1.1 Application areas ...................... .. 1 1.1.1 Real-time data-processing and experiment control . 1 1.1.2 Dependable Distributed Computing 4 1.2 Distributed operating systems 7 1.3 Design philosophy . 10 1.4 Development stages ...... 12 1.5 Overview............ 12 2 Design of the Hardware Architecture 15 2.1 Parallel processing architectures 16 2.1.1 Organization of system memory 17 2.1.2 Interconnection network .... 18 2.1.2.1 Hierarchical duster systems 19 2.2 EMPS Hardware architecture 20 2.2.1 The computer module 22 2.2.2 The memory module. 25 2.2.3 The system controller 26 2.2.4 The local area network controller . 26 2.2.5 Inter-node communication 26 3 Design of the Software Architecture 27 3.1 The EMPSNudeus ...... 30 3.1.1 Memory management. 32 3.1.2 Process management. .. 35 3.1.2.1 Process address 35 3.1.2.2 Process states . 36 3.1.2.3 Process switching 37 3.1.2.4 Tasks and processes 40 3.1.2.5 Memory management. 41 ii CONTENTS 3.1.3 Process synchronization. 45 3.1.4 Tune management .... 46 3.1.5 Interrupt handling .... 48 3.1.6 Interprocess communication (IPC) 50 3.1.6.1 Mailbox communication 52 3.1.6.2 Mailbox address . 54 3.1.6.3 Mailbox. 54 3.1.6.4 Port..... 56 3.2 The EMPS Kernel. ...... 58 3.2.1 Process management. 61 3.2.2 Mailbox management 62 3.2.3 Device management . 63 3.3 The EMPS operating system. 66 3.3.1 File access. 66 3.4 System initialization ..... 68 4 Implementation of Interprocess Communication (IPC) 69 4.1 Service layer ..... .... 70 4.1.1 Service layer interface 72 4.1.1.1 Service data 72 4.1.1.2 Services... 73 4.1.2 Service layer implementation. 74 4.1.2.1 Messages....... 74 4.1.2.2 Protocol for transparent mailbox access 76 4.1.2.3 Mailboxes 78 4.2 MAC layer .......... 81 4.2.1 MAC layer interface . 81 4.2.1.1 Service data 81 4.2.1.2 Services... 82 4.2.2 MAC layer implementation . 82 4.2.2.1 Protocols for datagram communication 83 4.3 Example of communication 87 4.4 Implementation issues . 89 4.5 Performance evaluation 89 5 Efficient Process Migration 95 5.1 Related work ... 96 5.2 Process migration ... 98 5.2.1 Interface..... 98 5.2.2 Implementation 99 5.2.2.1 Process context. 100 5.2.2.2 Additional mailbox services 100 CONTENTS iii 5.2.2.3 Implementationissues 103 5.2.3 Example of process migration. 103 5.3 Performance evaluation 105 5.4 Discussion . 109 6 Summary 111 A Graphical representation 115 B Used class interfaces 119 B.1 Tables. 119 B.2 Queues 120 B.3 Arrays. 120 B.4 Lists .. 121 C Software architecture 123 C1 Implementationof EMPS nucleus classes 123 C1.1 Low-level memory management . 123 C1.2 Process management. ...... 124 C1.2.1 Memory management. 125 C1.3 Process synchronization. 125 C1.4 Tune management . 126 C1.5 Interrupt handling . 127 C1.6 IPC . 128 C2 Implementation of EMPS kernel classes 129 C2.1 Process management. 129 C2.2 Mailbox management ..... 132 C2.3 Device management ...... 138 D Interprocess communication architecture 139 D.1 Implementation of the service layer 139 D.1.1 Service data . 141 D.1.2 Services ........... 143 D.1.3 Mailboxes.......... 145 D.2 Implementation of the MAC layer 146 D.2.1 Service data . 146 D.2.2 Services . 147 D.2.2.1 Intra-duster protocol 149 D.2.2.2 Inter-node protocol . 150 1 Introduction 1.1 Application areas The design of the EMPS (Eindhoven Multi-ProcessorSystem) executive for distributed computing was triggered by two different application areas, viz. real-time data-processing and control of physics experiments, and dependable distributed computing. 1.1.1 Real-time data-processing and experiment control In 1979, the Department of Physics of the Eindhoven University of Tech­ nology initiated the standardization of hardware and software for data­ acquisition and control of physics experiments. This resulted in the design of a general-purpose Physics Data Acquisition System (PhyDAS) and an interpretative development environment EPEP (Eindhoven Program Edi­ tor and Processor). The goal in the overall design of PhyDAS is to provide a general­ purpose real-time measurement system that can be used as a framework for intelligent, state-of-the-art interface modules, e.g. analog-to-digital converters (ADC), digital-to-analogconverters (DAC), scalers (SCA), pre­ set scalers (PSC), multi channel analyzers (MCA), and transient recorders (TRC) (See Fig. 1.1). PhyDAS has a separate measuring bus (PhyBUS) that interconnects the interface modules. By separating the computer bus and measuring bus, the interface modules are independent of the type of computer that is used in the experiment, and the real-time behavior of the system is more predictable. 1 2 Introduction file server other nodes SYSTEM BUS PHYBUs PHYPAD Figure 1.1: Typical EMPS-PhyDAS configuration. The EMPS system consists of several computer modules (C) and shared memory modules (M), interconnected by a cluster bus. A system bus interconnects several clusters into a node. Each node has a system controller (SC), an inter-node communication module (IN), and a local area network controller (LAN). A detailed description of these modules is presented in Chapter 2. A converter (CNV) interconnects the system bus of the EMPS system and the PhyBUS of the PhyDAS system. Goals for the design of PhyDAS were 1. Real-time processing: The system meets real-time demands by guar­ anteeing that worst-case response times are bounded. 2. Modularity, extendibility: Different interface modules can be used to construct the required hardware configuration for a given experi­ ment. 3. Multiprocessor configuration: To increase the performance and relia­ bility of the system, multiple processors can be used for controlling 1.1 Application areas 3 the interface modules and processing the data. 4. Cost-effectiveness: The life cycle of computers is generally much shorter that the life cycle of the interface modules. By separating the computer bus and the measuring bus, the use of new micropro­ cessor architectures is very cost-effective since the same interface modules can be used. EPEP is the name of the operating system and the programming lan­ guage. Goals for the design of EPEP [1] were 1. Object-based: TheimplementationofEPEP is object-basedfor reasons ofmodularity and extendibility. The programming language, which is not object-based, is a Pascal-like language. 2. Interpreter language: An interpreter language is preferred rather than a compiler-language because it is often necessary that the settings of interface modules can be adapted while running an experiment, without stopping and re-compiling the program. 3. Multitasking operating system: The motivations for structuring EPEP as a multi-process system are: • In a real-time system, processes must respond to asynchronous events.
Recommended publications
  • A Programmable Microkernel for Real-Time Systems∗
    A Programmable Microkernel for Real-Time Systems∗ Christoph M. Kirsch Marco A.A. Sanvido Thomas A. Henzinger University of Salzburg VMWare Inc. EPFL and UC Berkeley [email protected] tah@epfl.ch ABSTRACT Categories and Subject Descriptors We present a new software system architecture for the im- D.4.7 [Operating Systems]: Organization and Design— plementation of hard real-time applications. The core of the Real-time systems and embedded systems system is a microkernel whose reactivity (interrupt handling as in synchronous reactive programs) and proactivity (task General Terms scheduling as in traditional RTOSs) are fully programma- Languages ble. The microkernel, which we implemented on a Strong- ARM processor, consists of two interacting domain-specific Keywords virtual machines, a reactive E (Embedded) machine and a proactive S (Scheduling) machine. The microkernel code (or Real Time, Operating System, Virtual Machine microcode) that runs on the microkernel is partitioned into E and S code. E code manages the interaction of the system 1. INTRODUCTION with the physical environment: the execution of E code is In [9], we advocated the E (Embedded) machine as a triggered by environment interrupts, which signal external portable target for compiling hard real-time code, and in- events such as the arrival of a message or sensor value, and it troduced, in [11], the S (Scheduling) machine as a universal releases application tasks to the S machine. S code manages target for generating schedules according to arbitrary and the interaction of the system with the processor: the exe- possibly non-trivial strategies such as nonpreemptive and cution of S code is triggered by hardware interrupts, which multiprocessor scheduling.
    [Show full text]
  • TOWARD a POETICS of NEW MEDIA By
    'A Kind of Thing That Might Be': Toward A Poetics of New Media Item Type text; Electronic Dissertation Authors Thompson, Jason Craig Publisher The University of Arizona. Rights Copyright © is held by the author. Digital access to this material is made possible by the University Libraries, University of Arizona. Further transmission, reproduction or presentation (such as public display or performance) of protected items is prohibited except with permission of the author. Download date 28/09/2021 20:28:02 Link to Item http://hdl.handle.net/10150/194959 ‘A KIND OF THING THAT MIGHT BE’: TOWARD A POETICS OF NEW MEDIA by Jason Thompson _____________________ Copyright © Jason Thompson 2008 A Dissertation Submitted to the Faculty of the DEPARTMENT OF ENGLISH In Partial Fulfillment of the Requirements For the Degree of DOCTOR OF PHILOSOPHY WITH A MAJOR IN RHETORIC, COMPOSITION, AND THE TEACHING OF ENGLISH In the Graduate College THE UNIVERSITY OF ARIZONA 2008 2 THE UNIVERSITY OF ARIZONA GRADUATE COLLEGE As members of the Dissertation Committee, we certify that we have read the dissertation prepared by Jason Thompson entitled A Kind of Thing that Might Be: Toward a Rhetoric of New Media and recommend that it be accepted as fulfilling the dissertation requirement for the Degree of Doctor of Philosophy. ______________________________________________________________________ Date: 07/07/2008 Ken McAllister _______________________________________________________________________ Date: 07/07/2008 Theresa Enos _______________________________________________________________________ Date: 07/07/2008 John Warnock Final approval and acceptance of this dissertation is contingent upon the candidate’s submission of the final copies of the dissertation to the Graduate College. I hereby certify that I have read this dissertation prepared under my direction and recommend that it be accepted as fulfilling the dissertation requirement.
    [Show full text]
  • Amigaos 3.2 FAQ 47.1 (09.04.2021) English
    $VER: AmigaOS 3.2 FAQ 47.1 (09.04.2021) English Please note: This file contains a list of frequently asked questions along with answers, sorted by topics. Before trying to contact support, please read through this FAQ to determine whether or not it answers your question(s). Whilst this FAQ is focused on AmigaOS 3.2, it contains information regarding previous AmigaOS versions. Index of topics covered in this FAQ: 1. Installation 1.1 * What are the minimum hardware requirements for AmigaOS 3.2? 1.2 * Why won't AmigaOS 3.2 boot with 512 KB of RAM? 1.3 * Ok, I get it; 512 KB is not enough anymore, but can I get my way with less than 2 MB of RAM? 1.4 * How can I verify whether I correctly installed AmigaOS 3.2? 1.5 * Do you have any tips that can help me with 3.2 using my current hardware and software combination? 1.6 * The Help subsystem fails, it seems it is not available anymore. What happened? 1.7 * What are GlowIcons? Should I choose to install them? 1.8 * How can I verify the integrity of my AmigaOS 3.2 CD-ROM? 1.9 * My Greek/Russian/Polish/Turkish fonts are not being properly displayed. How can I fix this? 1.10 * When I boot from my AmigaOS 3.2 CD-ROM, I am being welcomed to the "AmigaOS Preinstallation Environment". What does this mean? 1.11 * What is the optimal ADF images/floppy disk ordering for a full AmigaOS 3.2 installation? 1.12 * LoadModule fails for some unknown reason when trying to update my ROM modules.
    [Show full text]
  • Chapter 1. Origins of Mac OS X
    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
    [Show full text]
  • P U B L I C a T I E S
    P U B L I C A T I E S 1 JANUARI – 31 DECEMBER 2001 2 3 INHOUDSOPGAVE Centrale diensten..............................................................................................................5 Coördinatoren...................................................................................................................8 Faculteit Letteren en Wijsbegeerte..................................................................................9 - Emeriti.........................................................................................................................9 - Vakgroepen...............................................................................................................10 Faculteit Rechtsgeleerdheid...........................................................................................87 - Vakgroepen...............................................................................................................87 Faculteit Wetenschappen.............................................................................................151 - Vakgroepen.............................................................................................................151 Faculteit Geneeskunde en Gezondheidswetenschappen............................................268 - Vakgroepen.............................................................................................................268 Faculteit Toegepaste Wetenschappen.........................................................................398 - Vakgroepen.............................................................................................................398
    [Show full text]
  • Last Updated August 05, 2020 by the Keeper of the List the Current Dod
    Last Updated August 05, 2020 by the Keeper of the List The current DoD FAQ is Version 10.1.5, accept no others! It's located at: http://www.denizensofdoom.com ######################################################### ## Please note: email addresses all are modified to ## ## avoid spam, by changing the "@" to " at ". ## ######################################################### 0001:John R. Nickerson:Toronto/CA:jrn at me.utoronto.ca 0002:Bruce Robinson:CO:bruce_w_robinson at ccm.jf.intel.com 0003:Chuck Rogers:CO:charlesrogers at avaya.com 0004:Dave Lawrence:NY:tale at dd.org 0004.1:Jack Lawrence:VT:tale at dd.org 0004.2:Abigail Lawrence:VT:tale at dd.org 0005:Steve Garnier:OH:sgarnier at mr.marconimed.com 0006:Paul O'Neill:OR:RETIRED 0007:Mike Bender:CA:bender at Eng.Sun.COM 0008:Charles Blair:IL:cjdb at midway.uchicago.edu 0009:Ilana Stern:CO:ilana at ncar.ucar.edu 0010:Alex Matthews:CO:matthews at jila.bitnet 0011:John Sloan:CO:jsloan at diag.com 0012:Rick Farris:CA:rfarris at serene.uucp 0013:Randy Davis:CA:dod1 xx randydavis.cc 0014:Janett Levenson:CO:jlevenso at ducair.bitnet 0015:Doug Elwood:CO:elwoodd at comcast.net 0016:Charlie Ganimian:MA:cig at genrad.com 0017:Jeff Carter:OR:jcarter at nosun.UUCP 0018:Gerald Lotto:MA:lotto at midas.harvard.edu 0019:Jim Bailey:OR:jimb at pogo.wv.tek.com 0020:Tom Borman:CA:borman at twisted.metaphor.com 0021:Warren Lewis:NC: 0022:Ken Neff:TX:kneff at tivoli.com 0023:Laurie Pitman:CA:laurie at pitmangroup.com 0024:Paul Mech:OH:ttmech at davinci.lerc.nasa.gov 0025:Ken Konecki:IL:kenk at tellabs.com 0026:Tim Lange:IN:tim at purdue.edu 0027:Janet Lange:IN:lange at purdue.edu 0028:Bob Olson:IL:olson at cs.uiuc.edu 0029:Dee Olson:IL:olson at cs.uiuc.edu 0030:Bruce Leung:IL:brucepleung at gmail.com 0031:Jim Strock:IN:ar2 at mentor.cc.purdue.edu 0032:Eugene Styer:KY:styer at eagle.eku.edu 0033:Dan Weber:IL:dweber at cogsci.uiuc.edu 0034:Deborah Hooker:CO:deb at ysabel.org 0035:Chuck Wessel:MN:wessel at src.honeywell.com 0036:Paul Blumstein:VA:pbandj at pobox.com 0037:M.
    [Show full text]
  • Morpho-Syntactic Interactions Between V and C in Romance1
    Dialectologia. Special issue, V (2015), 293-319. ISSN: 2013-2247 Received 7 August 2015. Accepted 26 September 2015. MORPHO-SYNTACTIC INTERACTIONS BETWEEN V AND C IN ROMANCE1 Ángel J. GALLEGO Universitat Autònoma de Barcelona [email protected] Abstract This paper discusses a series of morpho-syntactic (a)symmetries that emerge in the vP and CP levels of different Romance languages. The (a)symmetries considered indicate a P or D oriented nature for specific functional heads placed in the vP and CP domains, an idea that has been at the forefront of micro-parametric studies ever since the 80s (cf. Kayne 1984, 2000; Uriagereka 1995). The consequences of this investigation for the status of parameter theory are further considered (cf. Chomsky 1981; Baker 2001; Biberauer 2008; Kayne 2000; Picallo 2014) and the study of the lexicon, arguably the main locus of linguistic variation (cf. Halle & Marantz 1993; Hale & Keyser 1993; Starke 2014; Uriagereka 2008). Keywords complementizers, lexicon, micro-parameters, Romance languages, variation, verbs INTERACCIONES MORFOSINTÁCTICAS ENTRE V Y C EN ROMANCE Resumen Este trabajo discute una serie de (a)simetrías morfosintácticas que aparecen en los niveles del Sv y el SC de diferentes lenguas románicas. Dichas (a)simetrías indican que núcleos funcionales pertenecientes a los dominios Sv y SC despliegan una naturaleza similar a P o a D, una idea que ha 1 A previous version of this paper was presented at the V Westmost Europe Dialect Syntax (Wedisyn) Meeting, held at the Universidad Autónoma de Madrid (24-25 April 2014), whose audience I thank for questions and suggestions. Special thanks go to Roberta D’Alessandro, Carlota de Benito, Inés Fernández-Ordóñez, and Álvaro Octavio de Toledo for comments and (on-going) discussion.
    [Show full text]
  • Contributors to This Issue
    Contributors to this Issue Stuart I. Feldman received an A.B. from Princeton in Astrophysi- cal Sciences in 1968 and a Ph.D. from MIT in Applied Mathemat- ics in 1973. He was a member of technical staf from 1973-1983 in the Computing Science Research center at Bell Laboratories. He has been at Bellcore in Morristown, New Jersey since 1984; he is now division manager of Computer Systems Research. He is Vice Chair of ACM SIGPLAN and a member of the Technical Policy Board of the Numerical Algorithms Group. Feldman is best known for having written several important UNIX utilities, includ- ing the MAKE program for maintaining computer programs and the first portable Fortran 77 compiler (F77). His main technical interests are programming languages and compilers, software confrguration management, software development environments, and program debugging. He has worked in many computing areas, including aþbraic manipulation (the portable Altran sys- tem), operating systems (the venerable Multics system), and sili- con compilation. W. Morven Gentleman is a Principal Research Oftcer in the Com- puting Technology Section of the National Research Council of Canada, the main research laboratory of the Canadian govern- ment. He has a B.Sc. (Hon. Mathematical Physics) from McGill University (1963) and a Ph.D. (Mathematics) from princeton University (1966). His experience includes 15 years in the Com- puter Science Department at the University of Waterloo, ûve years at Bell Laboratories, and time at the National Physical Laboratories in England. His interests include software engi- neering, embedded systems, computer architecture, numerical analysis, and symbolic algebraic computation. He has had a long term involvement with program portability, going back to the Altran symbolic algebra system, the Bell Laboratories Library One, and earlier.
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • QUICK START GUIDE 4G Lite Product Series Table of Contents
    QUICK START GUIDE 4G Lite Product Series Table of Contents STEP ONE: OVERVIEW 1 to 4 STEP TWO: WIRING 5 to 11 STEP THREE: COMMUNICATION 12 to 15 STEP FOUR: ACP OR SDAC 16 to 17 STEP FIVE: SOFTWARE 18 to 21 STEP SIX: ENROLLMENT 22 to 24 STEP SEVEN: TIME & ATTENDANCE OPERATION 25 to 29 ACP OR SDAC (4G V-Station Lite) STEP FOUR: QUICK START GUIDE II Product Packaging Checklist 4G CR-PASS, 4G V-FLEX LITE AND 4G SECURECONTROL 4G V-STATION LITE QTY ITEM QTY ITEM 1 4G CR-Pass Device or 4G V-Flex Lite or 4G V-Station Lite 1 4G SecureControl Device 1 Installation CD 1 Terminal Block, 1x12po, 3.5mm, RA 1 Installation Guide (on Installation CD) 1 Terminal Block, 1x14po, 3.5mm, RA 1 Operator’s Manual (on Installation CD) 1 Quick Start Guide (Hard-copy and on Installation CD) 1 Quick Start Guide (Hard-copy and on Installation CD) 4 Dry Wall Anchor, Nylon, #4-8, 1” Length 1 SST Wall Mount Plate 4 Self-Tapping Screw, Philip Pan Head, SST, #6, 1” Length 1 4G MicroUSB Device Cable 1 Logo Sticker 1 4G MicroUSB PC Cable 1 Clamp-on Ferrite Core (WLAN Only) 1 Clamp-on Ferrite Core 1 Antenna, Omni Plug Connector (WLAN Only) 1 Machine Screw, Pin-in-Hex Security, Pan Head, SST, 6-32, 1/4” Length 1 Security Key, Pin-in-Hex, 2.5” Length NOTE: Electronic documentation is provided in Adobe® 1 Security Screw Retainer, Stainless Steel Acrobat® format (PDF). Adobe® Acrobat® Reader is available 2 Self-Tapping Screw, Philip Pan Head, SST, #6, 1” Length on the Installation CD or at http://www.adobe.com OVERVIEW 2 Dry Wall Anchor, Nylon, #4-8, 1” Length 2 Machine Screw,
    [Show full text]
  • Introduction
    CS307 Operating Systems Introduction Fan Wu Department of Computer Science and Engineering Shanghai Jiao Tong University Spring 2020 Operating Systems Operating Systems 2 Operating Systems UNIX-family: BSD(Berkeley Software Distribution), System-V, GNU/Linux, MINIX, Nachos, OS X, iOS BSD-family: FreeBSD, NetBSD, OpenBSD System-V-family: AIX, HP-UX, IRIX, Solaris Linux-family: Red Hat, Debian, Ubuntu, Fedora, openSUSE, Linux Mint, Google's Android, WebOS, Meego MS-DOS, Microsoft Windows, Windows Mobile, Win-CE, WP8 AmigaOS Symbian, MeeGo Google Chrome OS OS/2 XrossMediaBar(XMB) for PS3, Orbis OS for PS4 Input Output System for Wii Tiny-OS, LynxOS, QNX, VxWorks Operating Systems 3 Four Components of a Computer System People, machines, other computers Application programs define the ways in which theSystem system programs resources are arecomputer used to software solve the computingdesigned to problems operate theof thecomputer users hardware and toControls provide and a platformcoordinates for runninguse of hardware application among programsvarious applications and users provides basic computing resources Operating Systems 4 Computer System Structure Hardware – provides basic computing resources CPU, memory, I/O devices Operating system – Controls and coordinates use of hardware among various applications and users System programs – are computer software designed to operate the computer hardware and to provide a platform for running application programs BIOS and device drivers Application programs – define the ways in
    [Show full text]
  • Microkernel Construction Introduction
    Microkernel Construction Introduction Nils Asmussen 04/09/2020 1 / 32 Normal Organization Thursday, 4th DS, 2 SWS Slides: www.tudos.org ! Studies ! Lectures ! MKC Subscribe to our mailing list: www.tudos.org/mailman/listinfo/mkc2020 In winter term: Microkernel-based operating systems (MOS) Various labs 2 / 32 Organization due to COVID-19 Slides and video recordings of lectures will be published Questions can be asked on the mailing list Subscribe to the mailing list! Practical exercises are planed for the end of the semester Depending on how COVID-19 continues, exercises are in person or we use some video-conferencing tool 3 / 32 Goals 1 Provide deeper understanding of OS mechanisms 2 Look at the implementation details of microkernels 3 Make you become enthusiastic microkernel hackers 4 Propaganda for OS research done at TU Dresden and Barkhausen Institut 4 / 32 Outline Organization Monolithic vs. Microkernel Kernel design comparison Examples for microkernel-based systems Vision vs. Reality Challenges Overview About L4/NOVA 5 / 32 Monolithic Kernel System Design u s Application Application Application e r k Kernel e r File Network n e Systems Stacks l m Memory Process o Drivers Management Management d e Hardware 6 / 32 Monolithic Kernel OS (Propaganda) System components run in privileged mode No protection between system components Faulty driver can crash the whole system Malicious app could exploit bug in faulty driver More than 2=3 of today's OS code are drivers No need for good system design Direct access to data structures Undocumented
    [Show full text]