DOCSLIB.ORG

Helenos Project Project Documentation Contents

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Helenos Project Project Documentation Contents HelenOS project project documentation Contents Contents 2 1 Introduction 4 1.1 How to read this document ...................... 4 2 Project 5 2.1 Specification .............................. 5 2.2 Project meetings ........................... 6 2.3 Planning work ............................. 6 2.4 Kernel camps ............................. 6 2.5 Coding style .............................. 7 3 Developers 8 3.1 Jakub Jerm´aˇr ............................. 8 3.2 Ondˇrej Palkovsk´y ........................... 8 3.3 Martin Dˇeck´y ............................. 9 3.4 Jakub V´aˇna .............................. 9 3.5 Josef Cejkaˇ .............................. 9 3.6 Sergey Bondari ............................ 9 4 Software 10 4.1 Communication tools ......................... 10 4.2 Concurrent versions systems ..................... 11 4.3 Web tools ............................... 12 4.4 Third party components of HelenOS ................ 12 4.5 Build tools ............................... 13 4.6 Virtual environments ......................... 14 4.6.1 Bochs ............................. 15 4.6.2 GXemul ............................ 15 4.6.3 msim .............................. 15 4.6.4 PearPC ............................ 16 4.6.5 QEMU ............................. 16 4.6.6 Simics ............................. 16 2 4.6.7 Ski ............................... 17 4.6.8 VMware ............................ 17 A Goals and Achievements 19 A.1 Overall Conception .......................... 19 A.2 1a ................................... 20 A.3 Particular features .......................... 21 A.4 Implementation details ........................ 22 References 23 3 Chapter 1 Introduction The HelenOS project[1] is an effort to develop portable and general purpose operating system. Operating systems in general are very non-trivial pieces of software. It takes many people, many months and many tools to design and develop even medium size and feature-limited kernel and userspace layer. This report aims to document the development process of the HelenOS oper- ating system as it is specified in [2] and as it has been carried out by the original six developers (i.e. Jakub Jerm´aˇr,OndˇrejPalkovsk´y,Martin Dˇeck´y,Jakub V´aˇna, Josef Cejkaˇ and Sergey Bondari) in their work on Software project1 at Faculty of Mathematics and Physics at Charles University in Prague. Other aspects of the wider HelenOS project (e.g. master theses related to the topic) are not discussed here. 1.1 How to read this document Chapter 2 provides an insight into project’s timeline, planning, development. It also presents some statistic data related to the HelenOS project. Chapter 3 evaluates contributions and project dedication of each individual developer. Chapter 4 gives thorough coverage of the third-party software involved with HelenOS and also experience comming from using that software. 1Software project is the name of a subject at MFF UK. It is supposed to last two semesters at least. 4 Chapter 2 Project The HelenOS project was formed in late October 2004, when the six developers grouped and decided to adopt previous work of Jakub Jerm´aˇron the SPARTAN kernel1 as a foundation for their new operating system. 2.1 Specification The team had then worked on a specification[2] until March 8, 2005. The spec- ification was based on Martin Dˇeck´y’sdraft and incorporated many suggestions from other members of the team. The biggest part of the discussion was con- cerned about how many and what processor architectures we will support. At that time, the SPARTAN kernel supported ia32 and mips32 to the extent that kernel threads could be scheduled. The ia32 port could do some very basic virtual memory operations and was capable of SMP service. Moreover, the mips32 port ran only in the msim simulator. None of them supported userspace threads. We realized the need to support at least one 64-bit architecture and have long discussed whether it should be amd64 or ia64. We also considered ppc64. At the end, we decided to declare support for three new architectures, five architectures in total. Both amd64 and ia64 made it to the specifications, as well as PowerPC. As for PowerPC, the specification didn’t say whether ppc32 or ppc64 or both will be supported.2 It is worth noting that we wanted to be sure of access to respective hardware or at least simulator, prior to committing to support particular architecture. The decision to support almost all suggested architectures3 came after we had known for sure the above condition was satisfied. 1The SPARTAN kernel has been developed by Jakub Jerm´aˇrsince 2001. 2This has later proven a bit problematic because it is not very clear what ppc32 should be (i.e. the 32-bit G4 processor is not compatible with the 32-bit mode of the G5 processor. 3Namely, we didn’t declare support for sparc64, but it got supported anyway as part of Jakub Jerm´aˇr’smaster thesis. 5 We constructed our specification so that it contained a well defined set of mandatory features of the kernel and the userspace layer that had to be im- plemented. Besides the mandatory features, there was also an optional part comprising of three research or experimental topics. We hoped to eventually find time to work on them. 2.2 Project meetings After adopting our specification, we started to meet regularily every two weeks for the sake of consultations. The regular meetings were cancelled only during the exam periods and summer holiday. The first meeting took place on April 28, 2005. There were exactly twenty two project meetings before 0.2.0 release. The Faculty of Mathematics and Physics officially opened our project on June 10, 2005. However, serious collective work on the project, preceeded by individual efforts of some team members, began two months later. 2.3 Planning work In the beginning, we structured our work by creating three two-member teams, each dedicated to one new architecture (i.e. amd64, ia64 and ppc32). However, dividing into couples didn’t work out for the amd64 and ppc32 teams. In the end, both of those architectures were supported only with one member of respec- tive team. This might have been because of two factors. First, the collective responsibility for the project allowed the less motivated members to work less than others. Second, over the time, some developers profiled out to be good at specific tasks to which they later adhered and were forwarded more similar work. It was generally accepted within the team if one of the couple traded one architecure-specific task for another task on HelenOS. 2.4 Kernel camps There were two really important moments in our development process. Both of them took place in Harrachov, Czech Republic, where five team members moved two times, each time for a week of full-time intensive HelenOS development. These actions were called Kernel Camp 2005 and Winter Camp 2006. The former camp took place in August 2005 and was focused on getting all the architectures into our source tree and deepening their support. The latter camp took place in March 2006 and was dedicated to userspace support. In fact, we made the second camp the deadline for userspace milestone. With the exception of ppc32, all ports had some support for userspace prior to the second camp. Both of the camps moved the project miles ahead. 6 2.5 Coding style We have adopted common coding style specification in order to improve code readibility and maintainability. Even though the specification relates only to stylistic matters, following it has the potential to encourage and improve cooper- ation within the team and provide good preconditions for future project growth. 7 Chapter 3 Developers 3.1 Jakub Jerm´aˇr Jakub is the original author of the SPARTAN kernel and the initiator of the idea to start the HelenOS project. Once the team was composed, he implemented considerable parts of the ia64 code and he also worked on the mips32 memory management. On the generic front, Jakub designed the generic virtual address translation interface for the 4-level hierarchical page table translation mecha- nism as well as the global page hash table translation mechanism. He has been involved in the address space management functions and userspace synchroniza- tion through futexes. Other areas in which he contributed include the kernel console and the kernel ELF loader. Jakub is also the author of the generic buddy system framework as well as the B+tree implementation. His latest contribution is the userspace PCI driver. 3.2 Ondˇrej Palkovsk´y Ondˇrej has completely created the amd64 port and completed the mips32 port to the extent that it runs on a real MIPS machine1. Besides the architecture specific involvement, Ondˇrejprogrammed the slab allocator and modified the frame allocator to be self-contained which in turn let the old and very limited heap manager be removed from the kernel entirely. He also created architecture independent FPU lazy switching framework. Other example of his activity is the IPC subsystem and partial TLS2 support. Lastly, Ondˇrejequipped the kernel console with features found in userspace command shells (e.g. tab completion of commands and command history through keyboard arrows) and wrote the kernel configuration software. 1SGI Indy 2Thread local storage. 8 3.3 Martin Dˇeck´y Right from the beginning, Martin has cared about project’s code purity and readibility. He was the first developer to start writing Doxygen-style comments. He has promoted the proper use of C language const keywords and extensive typedefing. On the tools front, he has rewritten the initial build system and created all our toolchain build scripts. Martin worked and much improved the ia32 and amd64 kernel booting using the Grub bootloader and Multiboot specification. He also created specialized boot loaders for mips32 and ppc32 — architectures that don’t provide many other ways to load userspace init tasks. Finally, Martin bacame the sole author of the entire ppc32 port and has encountered partial success in booting ppc64 port to real hardware3. 3.4 Jakub V´aˇna Jakub has worked on ia32 and the ia64 FPU context switching and passive ia32 and active and passive ia64 console.
Load more

Recommended publications
  • The Politics of Roman Memory in the Age of Justinian DISSERTATION Presented in Partial Fulfillment of the Requirements for the D
    The Politics of Roman Memory in the Age of Justinian DISSERTATION Presented in Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy in the Graduate School of The Ohio State University By Marion Woodrow Kruse, III Graduate Program in Greek and Latin The Ohio State University 2015 Dissertation Committee: Anthony Kaldellis, Advisor; Benjamin Acosta-Hughes; Nathan Rosenstein Copyright by Marion Woodrow Kruse, III 2015 ABSTRACT This dissertation explores the use of Roman historical memory from the late fifth century through the middle of the sixth century AD. The collapse of Roman government in the western Roman empire in the late fifth century inspired a crisis of identity and political messaging in the eastern Roman empire of the same period. I argue that the Romans of the eastern empire, in particular those who lived in Constantinople and worked in or around the imperial administration, responded to the challenge posed by the loss of Rome by rewriting the history of the Roman empire. The new historical narratives that arose during this period were initially concerned with Roman identity and fixated on urban space (in particular the cities of Rome and Constantinople) and Roman mythistory. By the sixth century, however, the debate over Roman history had begun to infuse all levels of Roman political discourse and became a major component of the emperor Justinian’s imperial messaging and propaganda, especially in his Novels. The imperial history proposed by the Novels was aggressivley challenged by other writers of the period, creating a clear historical and political conflict over the role and import of Roman history as a model or justification for Roman politics in the sixth century.
    [Show full text]
  • Design and Evaluation of Self-Management Approaches for Virtual Machine-Based Environments
    Fachhochschule Wiesbaden Fachbereich Design Informatik Medien Studiengang Informatik Master-Thesis zur Erlangung des akademischen Grades Master of Science – M.Sc. Design and Evaluation of Self-Management Approaches for Virtual Machine-Based Environments vorgelegt von Dan Marinescu am 29. Februar 2008 Referent: Prof. Dr. Reinhold Kröger Korreferent: Prof. Dr. Steffen Reith II Erklärung gem. BBPO, Ziff. 6.4.2 Ich versichere, dass ich die Master-Thesis selbstständig verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe. Wiesbaden, 29.02.2008 Dan Marinescu Hiermit erkläre ich mein Einverständnis mit den im Folgenden aufgeführten Verbreitungs- formen dieser Master-Thesis: Verbreitungsform ja nein Einstellung der Arbeit in die √ Bibliothek der FHW Veröffentlichung des Titels der √ Arbeit im Internet Veröffentlichung der Arbeit im √ Internet Wiesbaden, 29.02.2008 Dan Marinescu III IV Contents 1 Introduction 1 2 Background 5 2.1 Virtualization ................................ 5 2.1.1 Taxonomy ............................. 5 2.1.2 Case Study: Xen .......................... 10 2.1.3 Live Migration ........................... 13 2.1.4 Hardware-Assisted Virtualization ................. 16 2.1.5 Management of Vitual Machine Environments .......... 17 2.2 Service Level Management ......................... 20 2.3 Autonomic Computing ........................... 21 2.3.1 Motivation ............................. 21 2.3.2 Taxonomy ............................. 22 2.3.3 Architectural Considerations .................... 23 2.3.4 Examples of Autonomic Computing Systems ........... 24 2.4 Complexity theory and Optimization .................... 25 2.4.1 Introduction to Complexity Theory ................ 25 2.4.2 Complexity Classes ......................... 25 2.4.3 Optimization Problems ....................... 26 2.4.4 The Knapsack Family of Problems ................. 27 2.4.5 Approximation Algorithms ..................... 29 2.4.6 Heuristics .............................. 32 V 3 Analysis 37 3.1 State of the Art ..............................
    [Show full text]
  • Virtual Square: All the Virtuality You Always Wanted but You Were Afraid to Ask
    Virtual Square: all the virtuality you always wanted but you were afraid to ask. Renzo Davoli i Computer Science Department vol Da ALMA MATER STUDIORUM: University of Bologna o Renz eft, yl WorkShop 2007 sul Calcolo e Reti dell'INFN op C 7 Rimini, 10 maggio 2007 00 2 © re ua Sq l ua t Vir Virtual Square VIRTUAL VIRTUAL VIRTUAL SQUARED i VIRTUAL SQUARE vol Da o VIRTUAL VIRTUAL Renz eft, VIRTUAL yl VIRTUAL op C 7 00 2 VIRTUAL © re VIRTUAL ua Sq l ua t Vir VIRTUALITY today ● Virtual Machines – historical topic – lots of papers – lots of tools i vol Da – ... but something is already missing o Renz ● Virtual Networking eft, yl op – less historical C 7 00 2 – several papers © re ua Sq l ua t Vir Virtual Square Virtualization concepts and tools are disconnected. i There is a world of new applications that vol Da can be realized by interoperating, o Renz integrated virtuality eft, yl op C 7 UNIFICATION IS NEEDED 00 2 © re ua Sq l ua t Vir Virtual Square © 2007 Copyleft, Renzo Davoli Vi rtual S qu are Some Examples of VM (free software) ● Qemu: PVM or SVM, User Mode User Access (or dual-mode with KQEMU, proprietary sw). – cross emulation platform (ia32, ia64, ppc, i m68k, sparc, arm...) vol Da o – dynamic translation Renz ● eft, XEN: SVM, Native. yl op C 7 – xen uses para-virtualization (O.S. in domain0 00 2 © has the real device drivers). re ua – (xen ideas come from the Denali project: Sq l ua t SVN, Native, real virtualization).
    [Show full text]
  • Authentication Services in Mobile Ad-Hoc Networks
    Authentication Services in Mobile Ad-hoc Networks LOgiciels-Réseaux Willy Jiménez 08013 -LOR Hakima Chaouchi Maryline Laurent-Maknavicius _______________________________________________________________________________ Authentication Services in Mobile Ad-hoc Networks ABSTRACT The deployment of wireless ad hoc networks is useful for people when they desire to communicate even if they are not connected to any infrastructure, with the purpose of playing games, sharing internet connection, or exchange files. In some ad hoc scenarios, they might know each other, so they can establish trusted relationships. However, if the number or users and mobility increase then it is more complicated to trust all users and a security mechanism is required. Few researches has been done in this field to find security solutions for MANETs deployments; one of them proposes a framework where the traditional AAA services are distributed inside the network with the idea of allowing secure exchange of services that could be chargeable. Based on this framework, we evaluate technical solutions, focusing mainly on the Authentication service; in order to have real implementations. One possibility is using virtualization technology to offer a de-centralized authentication service. Another solution is the development of a secure version of a routing protocol that uses a de-centralized authentication service as a previous requirement to allow any node to join the ad hoc routing domain. Willy Jiménez Hakima Chaouchi Maryline Laurent-Maknavicius Etudiant Maître de Conférences
    [Show full text]
  • Perceptions of the Ancient Jews As a Nation in the Greek and Roman Worlds
    Perceptions of the Ancient Jews as a Nation in the Greek and Roman Worlds By Keaton Arksey A Thesis submitted to the Faculty of Graduate Studies of The University of Manitoba In partial fulfilment of the requirements of the degree of MASTER OF ARTS Department of Classics University of Manitoba Winnipeg Copyright © 2016 by Keaton Arksey Abstract The question of what made one Jewish in the ancient world remains a fraught topic for scholars. The current communis opinio is that Jewish communities had more in common with the Greeks and Romans than previously thought. Throughout the Diaspora, Jewish communities struggled with how to live amongst their Greco-Roman majority while continuing to practise their faith and thereby remain identifiably ‘Jewish’. To describe a unified Jewish identity in the Mediterranean in the period between 200 BCE and 200 CE is incorrect, since each Jewish community approached its identity in unique ways. These varied on the basis of time, place, and how the non-Jewish population reacted to the Jews and interpreted Judaism. This thesis examines the three major centres of Jewish life in the ancient world - Rome, Alexandria in Egypt, and Judaea - demonstrate that Jewish identity was remarkably and surprisingly fluid. By examining the available Jewish, Roman, and Greek literary and archaeological sources, one can learn how Jewish identity evolved in the Greco-Roman world. The Jews interacted with non-Jews daily, and adapted their neighbours’ practices while retaining what they considered a distinctive Jewish identity. Each chapter of this thesis examines a Jewish community in a different region of the ancient Mediterranean.
    [Show full text]
  • Cisco Telepresence Server 4.4(1.16) MR1 Open Source Documentation
    Open Source Used In Cisco TelePresence Server 4.4(1.16) MR1 Cisco Systems, Inc. www.cisco.com Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco website at www.cisco.com/go/offices. Text Part Number: 78EE117C99-139358573 Open Source Used In Cisco TelePresence Server 4.4(1.16) MR1 1 This document contains licenses and notices for open source software used in this product. With respect to the free/open source software listed in this document, if you have any questions or wish to receive a copy of any source code to which you may be entitled under the applicable free/open source license(s) (such as the GNU Lesser/General Public License), please contact us at [email protected]. In your requests please include the following reference number 78EE117C99-139358573 Contents 1.1 Brian Gladman's AES Implementation 11-01-11 1.1.1 Available under license 1.2 busybox 1.15.1 :15.el6 1.2.1 Available under license 1.3 Coreboot d9b5d897d7f05d0ee8f9411628b757beea990b4b 1.3.1 Available under license 1.4 curl and libcurl 7.44.0 :7.44.0 1.4.1 Available under license 1.5 dhcp 4.1.1-P1 1.5.1 Available under license 1.6 expat 2.2.0 1.6.1 Available under license 1.7 FatFS R0.05 1.7.1 Available under license 1.8 freetype 2.5.3 1.8.1 Available under license 1.9 fribidi 0.19.6 :1 1.9.1 Available under license 1.10 G.722 2.00 1.10.1 Available under license 1.11 HMAC n/a 1.11.1 Available under license 1.12 icelib f50dffe9820bb7e32ac7b9b1b1d19aa3431227a2 1.12.1 Available under license 1.13
    [Show full text]
  • Virtualization Technologies Overview Course: CS 490 by Mendel
    Virtualization technologies overview Course: CS 490 by Mendel Rosenblum Name Can boot USB GUI Live 3D Snaps Live an OS on mem acceleration hot of migration another ory runnin disk alloc g partition ation system as guest Bochs partially partially Yes No Container s Cooperati Yes[1] Yes No No ve Linux (supporte d through X11 over networkin g) Denali DOSBox Partial (the Yes No No host OS can provide DOSBox services with USB devices) DOSEMU No No No FreeVPS GXemul No No Hercules Hyper-V iCore Yes Yes No Yes No Virtual Accounts Imperas Yes Yes Yes Yes OVP (Eclipse) Tools Integrity Yes No Yes Yes No Yes (HP-UX Virtual (Integrity guests only, Machines Virtual Linux and Machine Windows 2K3 Manager in near future) (add-on) Jail No Yes partially Yes No No No KVM Yes [3] Yes Yes [4] Yes Supported Yes [5] with VMGL [6] Linux- VServer LynxSec ure Mac-on- Yes Yes No No Linux Mac-on- No No Mac OpenVZ Yes Yes Yes Yes No Yes (using Xvnc and/or XDMCP) Oracle Yes Yes Yes Yes Yes VM (manage d by Oracle VM Manager) OVPsim Yes Yes Yes Yes (Eclipse) Padded Yes Yes Yes Cell for x86 (Green Hills Software) Padded Yes Yes Yes No Cell for PowerPC (Green Hills Software) Parallels Yes, if Boot Yes Yes Yes DirectX 9 Desktop Camp is and for Mac installed OpenGL 2.0 Parallels No Yes Yes No partially Workstati on PearPC POWER Yes Yes No Yes No Yes (on Hypervis POWER 6- or (PHYP) based systems, requires PowerVM Enterprise Licensing) QEMU Yes Yes Yes [4] Some code Yes done [7]; Also supported with VMGL [6] QEMU w/ Yes Yes Yes Some code Yes kqemu done [7]; Also module supported
    [Show full text]
  • Vmware Et Sécurité
    HERVÉ SCHAUER CONSULTANTS Cabinet de Consultants en Sécurité Informatique depuis 1989 Spécialisé sur Unix, Windows, TCP/IP et Internet OSSIROSSIR GroupeGroupe SURSUR 88 juilletjuillet 20082008 VMwareVMware etet sécuritésécurité JulienJulien RaeisRaeis <[email protected]> NicolasNicolas CollignonCollignon <[email protected]> AgendaAgenda Rappels sur la virtualisation Mesures de sécurité intégrées à VMware Virtualisation et DMZ Revue des vulnérabilités Retour d'expérience HSC 2/64 Copyright Hervé Schauer Consultants 2008 - Reproduction Interdite Rappels sur la virtualisation 3/64 Copyright Hervé Schauer Consultants 2008 - Reproduction Interdite DéfinitionsDéfinitions « Virtuel : Se dit des éléments (terminaux, mémoire...) d'un système informatique considérés comme ayant des propriétés différentes de leurs caractéristiques physiques » - Grand Dictionnaire Encyclopédique Larousse « Virtualisation : abstraction des ressources d'un système informatique. » 4/64 Copyright Hervé Schauer Consultants 2008 - Reproduction Interdite HistoriqueHistorique Concept introduit dans les années 60 But : partitionner les ressources des coûteux mainframes de l'époque IBM M44/44X, naissance du terme « pseudo-machine » Première implémentation de machines virtuelles IBM CP-40 Système tournant sur S/360-40 Perte d'intérêt dans les années 80 Déport des applications sur des clients et serveurs x86 Architecture « bon marché » Mais coûts d'infrastructure physique élevés, manque de protection en cas de panne, maintenance des postes de travail coûteuse, etc.
    [Show full text]
  • Comparison of Platform Virtual Machines - Wikipedia
    Comparison of platform virtual machines - Wikipedia... http://en.wikipedia.org/wiki/Comparison_of_platform... Comparison of platform virtual machines From Wikipedia, the free encyclopedia The table below compares basic information about platform virtual machine (VM) packages. Contents 1 General Information 2 More details 3 Features 4 Other emulators 5 See also 6 References 7 External links General Information Name Creator Host CPU Guest CPU Bochs Kevin Lawton any x86, AMD64 CHARON-AXP Stromasys x86 (64 bit) DEC Alphaserver CHARON-VAX Stromasys x86, IA-64 VAX x86, x86-64, SPARC (portable: Contai ners (al so 'Zones') Sun Microsystems (Same as host) not tied to hardware) Dan Aloni helped by other Cooperati ve Li nux x86[1] (Same as parent) developers (1) Denal i University of Washington x86 x86 Peter Veenstra and Sjoerd with DOSBox any x86 community help DOSEMU Community Project x86, AMD64 x86 1 of 15 10/26/2009 12:50 PM Comparison of platform virtual machines - Wikipedia... http://en.wikipedia.org/wiki/Comparison_of_platform... FreeVPS PSoft (http://www.FreeVPS.com) x86, AMD64 compatible ARM, MIPS, M88K GXemul Anders Gavare any PowerPC, SuperH Written by Roger Bowler, Hercul es currently maintained by Jay any z/Architecture Maynard x64 + hardware-assisted Hyper-V Microsoft virtualization (Intel VT or x64,x86 AMD-V) OR1K, MIPS32, ARC600/ARC700, A (can use all OVP OVP Imperas [1] [2] Imperas OVP Tool s x86 (http://www.imperas.com) (http://www.ovpworld compliant models, u can write own to pu OVP APIs) i Core Vi rtual Accounts iCore Software
    [Show full text]
  • Foreign Library Interface by Daniel Adler Dia Applications That Can Run on a Multitude of Plat- Forms
    30 CONTRIBUTED RESEARCH ARTICLES Foreign Library Interface by Daniel Adler dia applications that can run on a multitude of plat- forms. Abstract We present an improved Foreign Function Interface (FFI) for R to call arbitary na- tive functions without the need for C wrapper Foreign function interfaces code. Further we discuss a dynamic linkage framework for binding standard C libraries to FFIs provide the backbone of a language to inter- R across platforms using a universal type infor- face with foreign code. Depending on the design of mation format. The package rdyncall comprises this service, it can largely unburden developers from the framework and an initial repository of cross- writing additional wrapper code. In this section, we platform bindings for standard libraries such as compare the built-in R FFI with that provided by (legacy and modern) OpenGL, the family of SDL rdyncall. We use a simple example that sketches the libraries and Expat. The package enables system- different work flow paths for making an R binding to level programming using the R language; sam- a function from a foreign C library. ple applications are given in the article. We out- line the underlying automation tool-chain that extracts cross-platform bindings from C headers, FFI of base R making the repository extendable and open for Suppose that we wish to invoke the C function sqrt library developers. of the Standard C Math library. The function is de- clared as follows in C: Introduction double sqrt(double x); We present an improved Foreign Function Interface The .C function from the base R FFI offers a call (FFI) for R that significantly reduces the amount of gate to C code with very strict conversion rules, and C wrapper code needed to interface with C.
    [Show full text]
  • Download (4MB)
    Establishing trusted Machine-to-Machine communications in the Internet of Things through the use of behavioural tests Thesis submitted in accordance with the requirements of the University of Liverpool for the degree of Doctor in Philosophy by Valerio Selis April 2018 \Be less curious about people and more curious about ideas." Marie Curie Abstract Today, the Internet of Things (IoT) is one of the most important emerging technolo- gies. Applicable to several fields, it has the potential to strongly influence people's lives. \Things" are mostly embedded machines, and Machine-to-Machine (M2M) communica- tions are used to exchange information. The main aspect of this type of communication is that a \thing" needs a mechanism to uniquely identify other \things" without human intervention. For this purpose, trust plays a key role. Trust can be incorporated in the smartness of \things" by using mobile \agents". From the study of the IoT ecosystem, a new threat against M2M communications has been identified. This relates to the opportunity for an attacker to employ several forged IoT-embedded machines that can be used to launch attacks. Two \things-aware" detection mechanisms have been proposed and evaluated in this work for incorporation into IoT mobile trust agents. These new mechanisms are based on observing specific thing-related behaviour obtained by using a characterisation algorithm. The first mechanism uses a range of behaviours obtained from real embedded ma- chines, such as threshold values, to detect whether a target machine is forged. This detection mechanism is called machine emulation detection algorithm (MEDA). MEDA takes around 3 minutes to achieve a detection accuracy of 79.21%, with 44.55% of real embedded machines labelled as belonging to forged embedded machines.
    [Show full text]
  • Computer Architectures an Overview
    Computer Architectures An Overview PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 25 Feb 2012 22:35:32 UTC Contents Articles Microarchitecture 1 x86 7 PowerPC 23 IBM POWER 33 MIPS architecture 39 SPARC 57 ARM architecture 65 DEC Alpha 80 AlphaStation 92 AlphaServer 95 Very long instruction word 103 Instruction-level parallelism 107 Explicitly parallel instruction computing 108 References Article Sources and Contributors 111 Image Sources, Licenses and Contributors 113 Article Licenses License 114 Microarchitecture 1 Microarchitecture In computer engineering, microarchitecture (sometimes abbreviated to µarch or uarch), also called computer organization, is the way a given instruction set architecture (ISA) is implemented on a processor. A given ISA may be implemented with different microarchitectures.[1] Implementations might vary due to different goals of a given design or due to shifts in technology.[2] Computer architecture is the combination of microarchitecture and instruction set design. Relation to instruction set architecture The ISA is roughly the same as the programming model of a processor as seen by an assembly language programmer or compiler writer. The ISA includes the execution model, processor registers, address and data formats among other things. The Intel Core microarchitecture microarchitecture includes the constituent parts of the processor and how these interconnect and interoperate to implement the ISA. The microarchitecture of a machine is usually represented as (more or less detailed) diagrams that describe the interconnections of the various microarchitectural elements of the machine, which may be everything from single gates and registers, to complete arithmetic logic units (ALU)s and even larger elements.
    [Show full text]