Emphasizing on the Rhythm Generation Mechanism

Total Page:16

File Type:pdf, Size:1020Kb

Emphasizing on the Rhythm Generation Mechanism DEVELOPMENT OF SPINAL CIRCUITS FOR SWIMMING IN ZEBRAFISH (DANIO RERIO) LARVAE Emphasizing on the rhythm generation mechanism Yann Roussel Supervisor: Dr. Tuan Bui Examiners: Dr. Emily Standen, Dr. John Lewis and Dr. Michael Hildebrand External examiner: Dr. Joe Fetcho A thesis submitted in partial fulfillment of the requirements for the Doctorate in Philosophy degree in Biology Department of Biology Faculty of Science University of Ottawa © Yann Roussel, Ottawa, Canada, 2018 Table of content ABSTRACT viii RESUMÉ x PREFACE xii ACKNOWLEDGMENTS xiii Introduction 1 Motor control and the spinal cord 1 Locomotion 2 Swimming in zebrafish and its development 7 Neurogenesis in zebrafish larvae spinal cord 10 Changes in spinal circuitry during early development of zebrafish 11 Chapter 1: A Developmental Switch in the Operation of Larval Zebrafish Spinal Locomotor Circuits 17 ABSTRACT 18 Significance Statement 19 Introduction 20 Materials and Methods 23 Animal Care 23 Video recording and analysis 23 Animal preparation for electrophysiology 24 Chemogenetic ablation of DA neurons 24 Extracellular recordings 25 Intracellular recordings 26 Fluorescent imaging and cell counts 26 Data Analysis 27 Results 30 Increasingly stronger effect of strychnine on rhythmogenesis from 3 to 5 dpf 30 Differential effect of strychnine along the rostrocaudal axis 31 Secondary motoneurons preferentially generated caudally at 3 dpf 33 Arrhythmic synaptic inhibition to motoneurons becomes rhythmic at 3 dpf 33 Chemical ablation of dopaminergic neurons does not preclude a WGDR to SGDR transition 34 Modelling the maturation of zebrafish swimming with two coupled oscillators 36 Discussion 39 Proposed maturation of the neural control of swimming in developing zebrafish 40 Role of dopaminergic neurons in pattern generation 43 #ii Future directions 43 Chapter 2: Testing mechanisms of rhythmogenesis in spinal locomotor circuits of the developing zebrafish spinal cord 58! ABSTRACT 59 Introduction 60 Methods 63 Animal Care 63 Animal preparation for electrophysiology 63 Extracellular recordings 63 Intracellular recordings 64 ZAP 65 Data Analysis 65 Results 69 Lack of spinal neurons with subthreshold rhythmogenic intrinsic properties 69 Gap junctions are dispensable to the rhythmic tail beats after 3 dpf 71 Blocking persistent sodium current decreases the rhythm of tail beats in burst swimming fish 73 Dual patch-clamp recordings further confirm establishment of network oscillators at 5 dpf 74 Discussion 77 SUPPLEMENTARY DATA 88 Chapter 3: Modelling the maturation of swimming in Zebrafish (Danio rerio) through the development of spinal circuits 90! ABSTRACT 91 Introduction 92 Methods 96 Modelling environment 96 Modelling of single neurons 96 Modelling synapses 96 Spatial arrangement of spinal neurons 97 Noise in the network 98 Musculoskeletal model 99 Results 100 Part 1. Early locomotor behaviour, coiling, is encoded by a fully electrical network 100 Coiling results from unilateral gap-junction coupling 100 Network description 101 Simulation results 102 Part 2. Double coiling, an intermediate state toward swimming generated by a hybrid spinal circuit 103 iii# Double coiling is generated by a balance between excitatory and inhibitory commissural neurons 103 Network description 104 Simulation results 105 Part 3. First step of swimming: Burst swimming 106 Network oscillators drive episodes of tail beats 106 Network description 107 Simulation results 108 Part 4. Transitioning to beat-and-glide swimming 109 Network oscillators completely take over 109 Network description 110 Simulation results 112 Discussion 115 PM based network for early simple behaviour 115 Network oscillator for more refined movements 115 Competing during a transition period 117 Mechanisms of transition of burst to beat-and-glide swimming 118 Conclusion 138! Identification of mechanisms for rhythm generation in developing zebrafish larvae 138 Future directions 142 Switch in intrinsic properties 142 Identify sources of synaptic inhibition during swimming 142 Future maturation mechanism to integrate turns and slow/fast swimming modules 143 Incorporate sensory feedback in model 145 Incorporate supraspinal centers in model 146 Comparison with other animal models 147 Appendixes 150! Appendix 1 150 Ouabain does not perturbed rhythm generation nor episode duration 150 Discussion 151 Appendix 2 154 Pyridoxine-dependent epilepsy in zebrafish caused by aldh7a1 deficiency 154 Appendix 3 155 Insights into the genotypic/phenotypic spectrum and the pathophysiology of PLPBP-deficiency from novel B6-responsive clinical features, cellular, yeast and zebrafish models 155 Bibliography 156 iv# LIST OF TABLES Table 4.1. Parameter values of simple spiking neuron models of all populations involved in the modelling process 133! Table 4.2. Electrical synapse (gap junctions) weights used for modelling. 134! Table 4.3. Chemical synapses (glutamatergic in white and glycinergic in grey) weights used for modelling. Pre-synaptic neurons are in columns. Post-synaptic neurons in rows. 135! Table 4.4. Glutamatergic (white) and glycinergic (grey) reversal potential and time constants used to model respective synapses. 136 #v LIST OF FIGURES Figure 1.1. Schematic of the two general mechanisms for rhythm generation in the spinal cord. 14 Figure 1.2. Main types of spinal interneurons involved in motor control according to their morphological classification in the Zebrafish larva. 15 Figure 2.1. Larval zebrafish tail beat frequency during swimming is mainly between 20 and 40 Hz. 45 Figure 2.2. Greater effect of strychnine on tail beat rhythmicity at 5 dpf than at 3 and 4 dpf. 47 Figure 2.3. Effect of strychnine on fictive swimming in spinalized fish at 3 dpf and 5 dpf. 49 Figure 2.4. Differential effect of strychnine along the rostrocaudal axis of the zebrafish. 50 Figure 2.5. Cell count of secondary motoneurons and Chx10+ spinal neurons. 52 Figure 2.6. IPSCs mature from arrhythmic at 3 dpf to rhythmic with a frequency close to that of tail beats at 5 dpf during swimming episodes. 53 Figure 2.7. Metronidazole-treated Tg(dat:NTR-CFP) fish exhibit a development profile closer to 5 dpf rather than 3 dpf. 54 Figure 2.8. Coupled oscillator model of architectural change from pacemaker to network oscillator-based spinal locomotor circuits of developing zebrafish. 56 Figure 3.1. Subthreshold frequency preference analysis of caudal spinal neurons fails to identify pacemakers. 80 Figure 3.2. Carbenoxolone (CBX) reinforces the effect of strychnine at 3dpf but is dispensable at 4 and 5 dpf. 82 Figure 3.3. Riluzole disturbs rhythm of tail beats but only at 3 dpf. 84 Figure 3.4. Dual recordings in beat-and-glide swimming fish. 86 Figure 3.S1. Typical spiking activity of current-clamped spinal motoneurons (MN) and interneurons (IN). 88 Figure 3.S2. K-mean clustering of impedance profiles features on projection over PC1 and PC2. 89 Figure 4.1. Musculo-skeletal model helps to read network output. 123 Figure 4.2. Single coiling model relies on a fully electrical network driven by pacemaker neurons. 124 Figure 4.3. Double coiling model relies on a hybrid network of electrical and chemical synapses. 125 Figure 4.4. Emergence of half-centre oscillators during burst swimming. 127 Figure 4.5. Beat-and-glide swimming model requires both the implementation of a new population of neurons and maturation of intrinsic properties of existing neurons. 129 Figure 4.6. Beat-and-glide model network with adaptive CINs and MNs and tonic IIAs reproduces experimental observations of tail beat rhythm generation. 131 Video 4.S1 Single coiling model behavior 137 Video 4.S2 Double coiling model behavior 137 Video 4.S3 Burst swimming model behavior 137 Video 4.S4 Beat-and-glide swimming model behavior 137 Figure Appendix.1. Ouabain has little to no effect on tail beats rhythm or episode rhythm. 153 vi# LEGEND 5-HT : serotonin CPG : central pattern Mtz : metronidazole CaP : caudal primary generator PF : pattern formation CBX : carbenoxolone CoSA : commissural PM : pacemaker CEN : commissural secondary ascending pMN : primary motoneuron excitatory neuron DA : dopamine RG : rhythm generation CiA : circumferential Dpf : days-post-fertilization Rilu : riluzole ascending FFT : fast Fourier transform RoP : rostral primary CiD : circumferential Glu : glutamate/ SGDR : Strongly glycine descending glutamatergic dependent rhythm CIN : commissural Gly : glycine/ glycinergic sMN : secondary inhibitory neuron Hpf : hours-post-fertilization motoneuron CNS : central nervous IC : ipsilateral caudal Str : strychnine system IED : ipsilateral excitatory UCoD : unipolar CoBL : commissural descending commissural descending bifurcating longitudinal IIA : ipsilateral inhibitory VeLD : ventral longitudinal CoLA : commissural ascending descending! longitudinal ascending IN : interneuron WGDR : Weakly glycine CoLo : commissural local MCoD : multipolar dependent rhythm CoPA : commissural primary commissural descending ascending MiP : middle primary MN : motoneuron #vii ABSTRACT It has long been established that the spinal cord is able to produce locomotor activity on its own. Despite extensive research identifying and describing the involvement of multiple spinal neuron populations that are part of the spinal locomotor circuit, the manner in which these different components act together to precisely control the rhythm and the pattern of activation of muscles during locomotion remains largely undetermined. We sought to shed light on how the components of spinal locomotor circuits interact to produce robust locomotion
Recommended publications
  • 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]
  • Can Microkernels Mitigate Microarchitectural Attacks?⋆
    Can Microkernels Mitigate Microarchitectural Attacks?? Gunnar Grimsdal1, Patrik Lundgren2, Christian Vestlund3, Felipe Boeira1, and Mikael Asplund1[0000−0003−1916−3398] 1 Department of Computer and Information Science, Link¨oping University, Sweden ffelipe.boeira,[email protected] 2 Westermo Network Technologies [email protected] 3 Sectra AB, Link¨oping,Sweden Abstract. Microarchitectural attacks such as Meltdown and Spectre have attracted much attention recently. In this paper we study how effec- tive these attacks are on the Genode microkernel framework using three different kernels, Okl4, Nova, and Linux. We try to answer the question whether the strict process separation provided by Genode combined with security-oriented kernels such as Okl4 and Nova can mitigate microar- chitectural attacks. We evaluate the attack effectiveness by measuring the throughput of data transfer that violates the security properties of the system. Our results show that the underlying side-channel attack Flush+Reload used in both Meltdown and Spectre, is effective on all in- vestigated platforms. We were also able to achieve high throughput using the Spectre attack, but we were not able to show any effective Meltdown attack on Okl4 or Nova. Keywords: Genode, Meltdown, Spectre, Flush+Reload, Okl4, Nova 1 Introduction It used to be the case that general-purpose operating systems were mostly found in desktop computers and servers. However, as IoT devices are becoming in- creasingly more sophisticated, they tend more and more to require a powerful operating system such as Linux, since otherwise all basic services must be im- plemented and maintained by the device developers. At the same time, security has become a prime concern both in IoT and in the cloud domain.
    [Show full text]
  • Operating System Support for Run-Time Security with a Trusted Execution Environment
    Operating System Support for Run-Time Security with a Trusted Execution Environment - Usage Control and Trusted Storage for Linux-based Systems - by Javier Gonz´alez Ph.D Thesis IT University of Copenhagen Advisor: Philippe Bonnet Submitted: January 31, 2015 Last Revision: May 30, 2015 ITU DS-nummer: D-2015-107 ISSN: 1602-3536 ISBN: 978-87-7949-302-5 1 Contents Preface8 1 Introduction 10 1.1 Context....................................... 10 1.2 Problem....................................... 12 1.3 Approach...................................... 14 1.4 Contribution.................................... 15 1.5 Thesis Structure.................................. 16 I State of the Art 18 2 Trusted Execution Environments 20 2.1 Smart Cards.................................... 21 2.1.1 Secure Element............................... 23 2.2 Trusted Platform Module (TPM)......................... 23 2.3 Intel Security Extensions.............................. 26 2.3.1 Intel TXT.................................. 26 2.3.2 Intel SGX.................................. 27 2.4 ARM TrustZone.................................. 29 2.5 Other Techniques.................................. 32 2.5.1 Hardware Replication........................... 32 2.5.2 Hardware Virtualization.......................... 33 2.5.3 Only Software............................... 33 2.6 Discussion...................................... 33 3 Run-Time Security 36 3.1 Access and Usage Control............................. 36 3.2 Data Protection................................... 39 3.3 Reference
    [Show full text]
  • KOS - Principles, Design, and Implementation
    KOS - Principles, Design, and Implementation Martin Karsten, University of Waterloo Work In Progress - September 29, 2015 Abstract KOS is an experimental operating system kernel that is designed to be simple and accessible to serve as a platform for research, experimen- tation, and teaching. The overall focus of this project is on system-level infrastructure software, in particular runtime systems. 1 Introduction KOS (pronounce "Chaos") is an experimental operating system kernel that is designed to be simple and accessible to serve as a platform for research, ex- perimentation, and teaching. It is focused on building a nucleus kernel that provides the basic set of operating system functionality, primarily for resource mediation, that must realistically be implemented for execution in privileged mode. While being simple KOS is not simplistic and avoids taking design shortcuts that would prohibit adding more sophisticated resource management strategies later on { inside the kernel or at higher software layers. The nu- cleus kernel is augmented with several prototype subsystems typically found in an operating system to eventually support running realistic applications. The entire code base is written in C++, except for small assembler parts. The C++ code makes use of advanced language features, such as code reuse with efficient strong type safety using templates, the C++ library for data struc- ture reuse, as well as (limited) polymorphism. Existing open-source software is reused for non-nucleus subsystems as much as possible. The project is hosted at https://git.uwaterloo.ca/mkarsten/KOS 2 Motivation In principle, an operating system has two basic functions. First, it consolidates low-level hardware interfaces and provides higher-level software abstractions to facilitate and alleviate application programming.
    [Show full text]
  • Embassies: Radically Refactoring the Web Jon Howell, Bryan Parno, John R
    Embassies: Radically Refactoring the Web Jon Howell, Bryan Parno, John R. Douceur, Microsoft Research Abstract of evolving complexity. On the Internet, application Web browsers ostensibly provide strong isolation for providers, or vendors, run server-side applications over the client-side components of web applications. Unfor- which they exercise total control, from the app down tunately, this isolation is weak in practice; as browsers to the network stack, firewall, and OS. Even when ven- add increasingly rich APIs to please developers, these dors are tenants of a shared datacenter, each tenant au- complex interfaces bloat the trusted computing base and tonomously controls its software stack down to the ma- erode cross-app isolation boundaries. chine code, and each tenant is accessible only via IP. We reenvision the web interface based on the notion The strong isolation among virtualized Infrastructure-as- of a pico-datacenter, the client-side version of a shared a-Service datacenter tenants derives not from physical server datacenter. Mutually untrusting vendors run their separation but from the execution interface’s simplicity. code on the user’s computer in low-level native code con- This paper extends the semantics of datacenter rela- tainers that communicate with the outside world only via tionships to the client’s web experience. Suspending dis- IP. Just as in the cloud datacenter, the simple semantics belief momentarily, suppose every client had ubiquitous makes isolation tractable, yet native code gives vendors high-performance Internet connectivity. In such a world, the freedom to run any software stack. Since the datacen- exploiting datacenter semantics is easy: The client is ter model is designed to be robust to malicious tenants, it merely a screencast (VNC) viewer; every app runs on is never dangerous for the user to click a link and invite its vendor’s servers and streams a video of its display to a possibly-hostile party onto the client.
    [Show full text]
  • Master Thesis
    Charles University in Prague Faculty of Mathematics and Physics MASTER THESIS Petr Koupý Graphics Stack for HelenOS Department of Distributed and Dependable Systems Supervisor of the master thesis: Mgr. Martin Děcký Study programme: Informatics Specialization: Software Systems Prague 2013 I would like to thank my supervisor, Martin Děcký, not only for giving me an idea on how to approach this thesis but also for his suggestions, numerous pieces of advice and significant help with code integration. Next, I would like to express my gratitude to all members of Hele- nOS developer community for their swift feedback and for making HelenOS such a good plat- form for works like this. Finally, I am very grateful to my parents and close family members for supporting me during my studies. I declare that I carried out this master thesis independently, and only with the cited sources, literature and other professional sources. I understand that my work relates to the rights and obligations under the Act No. 121/2000 Coll., the Copyright Act, as amended, in particular the fact that the Charles University in Pra- gue has the right to conclude a license agreement on the use of this work as a school work pursuant to Section 60 paragraph 1 of the Copyright Act. In Prague, March 27, 2013 Petr Koupý Název práce: Graphics Stack for HelenOS Autor: Petr Koupý Katedra / Ústav: Katedra distribuovaných a spolehlivých systémů Vedoucí diplomové práce: Mgr. Martin Děcký Abstrakt: HelenOS je experimentální operační systém založený na mikro-jádrové a multi- serverové architektuře. Před započetím této práce již HelenOS obsahoval početnou množinu moderně navržených subsystémů zajišťujících různé úkoly v rámci systému.
    [Show full text]
  • A Multiserver User-Space Unikernel for a Distributed Virtualization System
    A Multiserver User-space Unikernel for a Distributed Virtualization System Pablo Pessolani Departamento de Ingeniería en Sistemas de Información Facultad Regional Santa Fe, UTN Santa Fe, Argentina [email protected] Abstract— Nowadays, most Cloud applications are developed application components began to be deployed in Containers. using Service Oriented Architecture (SOA) or MicroService Containers (and similar OS abstractions such as Jails [7] and Architecture (MSA). The scalability and performance of them Zones [8]) are isolated execution environments or domains is achieved by executing multiple instances of its components in in user-space to execute groups of processes. Although different nodes of a virtualization cluster. Initially, they were Containers share the same OS, they provide enough security, deployed in Virtual Machines (VMs) but, they required enough performance and failure isolation. As Containers demand computational, memory, network and storage resources to fewer resources than VMs [9], they are a good choice to hold an Operating System (OS), a set of utilities, libraries, and deploy swarms. the application component. By deploying hundreds of these Another option to reduce resource requirements is to use application components, the resource requirements increase a the application component embedded in a Unikernel [10, lot. To minimize them, usually small OSs with small memory footprint are used. Another way to reduce the resource 11]. A Unikernel is defined as “specialized, single-address- requirements is integrating the application components in a space machine image constructed by using library operating Unikernel. This article proposes a Unikernel called MUK, system” [12]. A Unikernel is a technology which integrates based on a multiserver OS, to be used as a tool to integrate monolithically network, storage, and file systems services Cloud application components.
    [Show full text]
  • State Spill in Modern Operating Systems
    A Characterization of State Spill in Modern Operating Systems Kevin Boos, Emilio Del Vecchio, and Lin Zhong Rice University fkevinaboos, edd5, [email protected] Abstract states change and propagate throughout the system, showing that modularity is necessary but insufficient. For example, Understanding and managing the propagation of states in several process migration works have cited “residual depen- operating systems has become an intractable problem due dencies” that remain on the source system as an obstacle to to their sheer size and complexity. Despite modularization post-migration correctness on the target system [38, 55, 34]. efforts, it remains a significant barrier to many contemporary Fault isolation and fault tolerance literature has long realized computing goals: process migration, fault isolation and the undesirable effects of fate sharing among software mod- tolerance, live update, software virtualization, and more. ules as well as the difficulty of restoring a process or whole Though many previous OS research endeavors have achieved machine statefully after a failure, due to the sprawl of states these goals through ad-hoc, tedious methods, we argue that spread among different system components [28, 26, 52, 51]. they have missed the underlying reason why these goals are Live update and hot-swapping research has long sought to overcome the state maintenance issues and inter-module de- so challenging: state spill. pendencies that plague their implementations when transi- State spill occurs when a software entity’s state undergoes tioning from an old to a new version, forcing developers to lasting changes as a result of a transaction from another entity. write complex state transfer functions [7, 25, 27, 48, 5].
    [Show full text]
  • FOSDEM 2018 Schedule
    FOSDEM 2018 - Saturday 2018-02-03 (1/15) Janson K.1.105 (La H.2215 (Ferrer) H.1301 (Cornil) H.1302 (Depage) H.1308 (Rolin) H.1309 (Van Rijn) H.2111 Fontaine)… 09:30 Welcome to FOSDEM 2018 09:45 10:00 Consensus as a Service 10:15 10:30 The path to Data-plane The State of Go video - It's a lot more micro-services than just a HTML5 tag 10:45 11:00 Next Generation Python 3: 10 years later OpenDaylight as a De-mystifying Advanced Go debugging Internet Initiative Platform for Network contributing to with Delve Programmability PostgreSQL 11:15 11:30 Ligato: a platform for Networking deepdive Rendering of subtitles in development of cloud- HTML5 with imscJS native VNFs 11:45 12:00 Unix Architecture Surviving in an Open Easy GnuPG Networking-VPP PostgreSQL -- A Crash Testing and Automation An update on VLC and Evolution from the 1970 Source Niche: the Course in the Era of Containers the VideoLAN PDP-7 to the 2018 Pythran case community FreeBSD 12:15 BulletinBoard DHT and wireguard-p2p 12:30 ONAP – A road to Upspin and a future of Kodi v18 features and network automation ↴ the Internet ↴ improvements ↴ Nakadi Event Broker ↴ 12:45 FOSDEM 2018 - Saturday 2018-02-03 (2/15) H.2213 H.2214 H.3227 H.3228 AW1.120 AW1.121 AW1.125 AW1.126 09:30 09:45 10:00 10:15 10:30 A real life story about Cypher: An evolving Status of the Apache CANCELLED Simulating Arrival & Informal Everything is a device! product testing with query language for ODF Toolkit (incubating) Multilevel Caches in Discussions robotframework property graphs Cachegrind 10:45 Working in the ODF
    [Show full text]
  • Genode Operating System Framework Platforms
    GENODE Operating System Framework 21.05 Platforms Norman Feske Contents Contents 1 Introduction3 2 Porting Genode to a new SoC4 2.1 Preparatory steps................................9 2.1.1 Licensing considerations........................9 2.1.2 Selecting a suitable SoC........................ 10 2.1.3 Start by taking the known-good path................ 11 2.1.4 Setting up an efficient development workflow........... 12 2.2 Getting acquainted with the target platform................. 14 2.2.1 Getting a first impression....................... 15 2.2.2 The U-Boot boot loader........................ 19 2.3 Bare-metal serial output............................ 24 2.4 Kernel skeleton................................. 34 2.4.1 A tour through the code base..................... 34 2.4.2 A new home for the board support.................. 41 2.4.3 Getting to grips using meaningful numbers............. 48 2.4.4 A first life sign of the kernel...................... 55 2.5 Low-level debugging.............................. 57 2.5.1 Option 1: Walking the source code.................. 58 2.5.2 Option 2: One step of ground truth at a time............ 60 2.5.3 Option 3: Backtraces.......................... 62 2.6 Excursion to the user land........................... 64 2.7 Device access from the user level....................... 73 2.7.1 Using a GPIO pin for sensing a digital signal............ 74 2.7.2 Driving an LED via a GPIO pin.................... 81 2.7.3 Responding to device interrupts................... 84 2.8 One Platform driver to rule them all..................... 90 2.8.1 Platform driver............................. 90 2.8.2 Session interfaces for accessing pins................. 95 2.8.3 PIO device driver............................ 96 2.8.4 Dynamic configuration testing...................
    [Show full text]
  • General-Purpose Computing with Virtualbox on Genode/NOVA
    General-purpose computing with VirtualBox on Genode/NOVA Norman Feske <[email protected]> Outline 1. VirtualBox 2. NOVA microhypervisor and Genode 3. Transplantation of VirtualBox to NOVA 4. Demo 5. War stories 6. Project Turmvilla 7. The Book “Genode Foundations” General-purpose computing with VirtualBox on Genode/NOVA2 Outline 1. VirtualBox 2. NOVA microhypervisor and Genode 3. Transplantation of VirtualBox to NOVA 4. Demo 5. War stories 6. Project Turmvilla 7. The Book “Genode Foundations” General-purpose computing with VirtualBox on Genode/NOVA3 Architecture overview config, status SVC VM xpcom VM process xpcom process IPCD xpcom xpcom VBoxManage VirtualBox Application /dev/vboxdrv /dev/vboxdrv General-purpose computing with VirtualBox on Genode/NOVA4 Starting up a VM process VM process open /dev/vboxdrv kernel vboxdrv.ko General-purpose computing with VirtualBox on Genode/NOVA5 VM process running root mode non-root mode VM process load VMMR0 /dev/vboxdrv kernel vboxdrv.ko VMMR0 / Hypervisor General-purpose computing with VirtualBox on Genode/NOVA6 Entering the Guest OS root mode non-root mode VM process ioctrl VM RUN /dev/vboxdrv Guest OS kernel vboxdrv.ko world switch General-purpose computing with VirtualBox on Genode/NOVA7 Flow of a virtualization event root mode non-root mode VM process VM RUN returns /dev/vboxdrv Guest OS kernel vboxdrv.ko no yes VMMR0 ? world switch General-purpose computing with VirtualBox on Genode/NOVA8 root mode non-root mode VM process /dev/vboxdrv Guest OS kernel highly complex vboxdrv.ko VMMR0
    [Show full text]
  • Genode Operating System Framework Foundations
    GENODE Operating System Framework 15.05 Foundations Norman Feske Contents Contents 1. Introduction9 1.1. Operating-system framework......................... 14 1.2. Licensing and commercial support...................... 16 1.3. About this document.............................. 17 I. Foundations 18 2. Getting started 19 2.1. Obtaining the source code........................... 20 2.2. Source-tree structure.............................. 21 2.3. Using the build system............................. 24 2.4. A simple system scenario........................... 26 2.5. Hello world................................... 29 2.5.1. Using a custom source-code repository............... 29 2.5.2. Source code and build description.................. 29 2.5.3. Building the component........................ 30 2.5.4. Defining a system scenario...................... 31 3. Architecture 33 3.1. Capability-based security........................... 35 3.1.1. Capability spaces, object identities, and RPC objects........ 35 3.1.2. Delegation of authority and ownership............... 36 3.1.3. Capability invocation......................... 37 3.1.4. Capability delegation through capability invocation........ 40 3.2. Recursive system structure........................... 42 3.2.1. Component ownership......................... 42 3.2.2. Tree of components........................... 43 3.2.3. Services and sessions.......................... 43 3.2.4. Client-server relationship....................... 46 3.3. Resource trading................................ 50 3.3.1. Resource
    [Show full text]