DOCSLIB.ORG

Hardware Abstraction Layer (HAL) Whitepaper

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Hardware Abstraction Layer (HAL) Whitepaper ABSTRACTION LAYER FOR IMPLEMENTATION OF EXTENSIONS IN PROGRAMMABLE NETWORKS Hardware Abstraction Layer (HAL) Whitepaper simplicity for the integrators are the main motivation assumptions for disseminating the HAL 1. Abstract concept. This Whitepaper describes the concept of Hardware Adaptation Layer (HAL) for applying the 2.1. Purpose of proposed solution OpenFlow protocol to the non-OpenFlow hardware. In this document, first, the motivation and high level goals of designing the HAL is explained as well as the Although OpenFlow has clear specifications [ONF], high level goals and supported network platforms. when it comes to implementing those Then, the logical architecture of HAL is presented specifications on devices or platforms, each including the architectural and functional implementation is different because of requirements. As next chapter the network heterogeneity of platforms and their architectures. hardware integration models are provided and the Moreover, the official OpenFlow specification is supported hardware platforms are classified. designed for wired Ethernet platforms and it does Finally, the proposed implementation of HAL is not support other platforms such as circuit presented including the software interfaces for switched and wireless platforms. Designing a platform integrators such as the Abstract mechanism, targeting hardware-level forwarding Forwarding API and the Pipeline Interface. platforms to provide a clean, simple, extensible and flexible interface between software and hardware will facilitate providing abstracted information of underlying hardware or platform 2. Motivation for the for creating an abstracted elements for controlling software. This mechanism will expose all of HAL functionality and performance of modern Software Defined Networking concept is getting networking hardware, while maintaining the useful more and more popularity as a solution for more properties of embedded operating systems on the efficient network management. The OpenFlow hardware platform but at the same time it will be protocol is the most mature proof of concept of platform agnostic. the SDN. The idea of separating the data and control elements in network devices is being As part of SDN activities the ALIEN project aims to supplied in new network equipment. Although, the undertake the challenge of provide simple concept OpenFlow is usually not supported in many specific for non-OpenFlow hardware platforms integrators network equipments e.g. the optical devices, by designing and defining functions of a Hardware hardware without possibility to be upgraded or Abstraction Layer (HAL). This abstraction without packet processing API. Enabling OpenFlow mechanism aims to hide hardware complexity as on all those non-OpenFlow devices with possible well as technology and vendor specific features requirements for HAL was categorised in from OpenFlow control framework. functional and architectural. 2.2. Supported network platforms The desired HAL should follow some architectural guideline in order to support the intended The targeted platform for HAL are: platforms. Packet Switch: All devices that perform any HAL has to reside between controller and the form of L2 switching are fell into this group. device i.e. controller can get control access on Optical: Basically all circuit switched devices data path only through HAL. (WDM/TDM) are categorized in optical group. HAL components should be reusable as much Network Processor (NP) / NetFPGA: Any device as possible. This will lead to smaller code, that its data plane can be programmed to better troubleshooting and management. perform any (L2-L4) packet processing. It should be portable, platform-independent Access Networks technologies (DOCSIS, and flexible to give ability to be implemented GPON,GEPON...): Since these technologies’ data on various platforms. plane architecture is so different to the rest of HAL has to have certain functionalities in order to platforms, it was decided to put it in separate provide a platform for controllers to control the group so that its abstraction could be done data path: without compromising its functionality. It has to provide an interface to upper layers In the ALIEN project the implementation of the (applications) for handling hardware dependent HAL architecture will be validated on various issues network equipment such as: EZappliance with It has to provide rich information enough to EZchip NP3 network processor, GEPON, NetFPGA, support full featured network operating DOCSIS, ATCA with Cavium Octeon network systems (controllers) processor, ADVA Layer 0 Switch, Dell/Force10 It has to expose interfaces for hardware 7024 switch with ASIC and Cavium Octeon. reprogrammability. For example, an ASIC packet-processing fast path could support programmability for deep-packet inspection 3. Logical architecture operations. Another example could be NetFPGAs which users can define their own of HAL function on the hardware. It has to provide interface for hardware Following the SDN concept and according to resource management. OpenFlow architecture, the data path or It has to provide mechanism for controlling forwarding engine inside of an OpenFlow device shared abstracted resources such as must be controlled and managed by a controller forwarding-table in virtualized environment who resides outside of the device and communicates to the device via a secure channel. 3.2. Proposed HAL architecture The data path is represented to the controller in an abstracted fashion as a table or tables with Following the functional and architectural flows holding packets information and actions requirements for desired HAL a unified associated to them which could be manipulated architecture is proposed. Hardware platform (programmed) by the controller software. categorization helps to build organized and modular components which then yields to create 3.1. Requirements for HAL a flexible and extensible HAL. In the following, HAL components and their functionalities are Optimum HAL for network devices to support described. OpenFlow protocol needs to have certain features so that it can support the current and future The proposed HAL consists of two separate layers: architecture of networking devices. The upper Hardware Interface Layer (HIL) and lower Hardware Presentation Layer (HPL). 2 Figure 2 - Virtualization architecture Bare Metal Management: Although the ultimate goal of creating HAL is to provide an interface for controlling hardware, each hardware platform has Figure 1 - HAL architecture different protocol for device management and configuration. The bare metal management HIL: Components in the HIL altogether provide an component is responsible for hardware implementation of common device control and initialization and management. In case of device management protocols i.e. OpenFlow, etc. configuration changes in hardware platform or The HIL components are independent of introducing new user-defined functionality into the underlying hardware platform. platform, this component will provide tools and interfaces for such events. OpenFlow endpoint: is a protocol endpoint responsible for maintaining connection with a HPL: The Hardware Presentation Layer (HPL) controller. includes few components which have distinct Virtualization: This component is proposed as a functionality. The northbound of HPL provides an method to provide virtualization capabilities to API for upper layer to create extended OpenFlow HAL-compatible devices. It has three different table. In the following, HPL components and their functionalities: (i) communicating with the role and functionality are explained. Network Management System (NMS) of the Infrastructure Provider (by considering the NMS Device Information Model: is a model of the responsible for properly configuring the virtual configured OF switch that represents switch’s state network instances), (ii) communicating with which probably is platform independent. It is not a multiple OF controllers through the OpenFlow representation of a specific hardware. Pure data protocol and (iii) slicing the flowspace. The Virtual model without processing. Agent (VA) slices the overall flowspace among Translator: is part of device driver. it is responsible many OF Controllers based on the configuration for translating all entries and actions from received from the NMS. On the other hand VA OpenFlow switch model (DIM) into platform ensures setting-up control channels with each specific commands and configurations. This connected OF controller by creating one virtual module is not obligatory, e.g. for devices that switch per controller. Virtual switches of the same supports OpenFlow data model. VA may use different versions of the OpenFlow Orchestrator: is part of driver components and protocol, depending on the capabilities of the responsible for configuring the entire subnetwork, controller assigned to their slice. i.e. multiple components, to simulate the behavior of OF switch modeled by DIM. As an example, GEPON needs configuration for both optical and electrical parts for appropriate functioning. 3 Device driver: is a piece of software that performs and exposes a part of a network as a single device. data processing using hardware In this case the HAL implementation must device/accelerators. In case of closed devices, it orchestrate a group of devices to behave as a only configures a device to obtain the same single network element. This integration model is behavior like modeled by DMI OF switch (a kind of suitable for platforms
Load more

Recommended publications
  • The Interplay of Compile-Time and Run-Time Options for Performance Prediction Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel
    The Interplay of Compile-time and Run-time Options for Performance Prediction Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel To cite this version: Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel. The Interplay of Compile-time and Run-time Options for Performance Prediction. SPLC 2021 - 25th ACM Inter- national Systems and Software Product Line Conference - Volume A, Sep 2021, Leicester, United Kingdom. pp.1-12, 10.1145/3461001.3471149. hal-03286127 HAL Id: hal-03286127 https://hal.archives-ouvertes.fr/hal-03286127 Submitted on 15 Jul 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. The Interplay of Compile-time and Run-time Options for Performance Prediction Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel Univ Rennes, INSA Rennes, CNRS, Inria, IRISA Rennes, France [email protected] ABSTRACT Both compile-time and run-time options can be configured to reach Many software projects are configurable through compile-time op- specific functional and performance goals. tions (e.g., using ./configure) and also through run-time options (e.g., Existing studies consider either compile-time or run-time op- command-line parameters, fed to the software at execution time).
    [Show full text]
  • Mashup Architecture for Connecting Graphical Linux Applications Using a Software Bus Mohamed-Ikbel Boulabiar, Gilles Coppin, Franck Poirier
    Mashup Architecture for Connecting Graphical Linux Applications Using a Software Bus Mohamed-Ikbel Boulabiar, Gilles Coppin, Franck Poirier To cite this version: Mohamed-Ikbel Boulabiar, Gilles Coppin, Franck Poirier. Mashup Architecture for Connecting Graph- ical Linux Applications Using a Software Bus. Interacción’14, Sep 2014, Puerto de la Cruz. Tenerife, Spain. 10.1145/2662253.2662298. hal-01141934 HAL Id: hal-01141934 https://hal.archives-ouvertes.fr/hal-01141934 Submitted on 14 Apr 2015 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Mashup Architecture for Connecting Graphical Linux Applications Using a Software Bus Mohamed-Ikbel Gilles Coppin Franck Poirier Boulabiar Lab-STICC Lab-STICC Lab-STICC Telecom Bretagne, France University of Bretagne-Sud, Telecom Bretagne, France gilles.coppin France mohamed.boulabiar @telecom-bretagne.eu franck.poirier @telecom-bretagne.eu @univ-ubs.fr ABSTRACT functionalities and with different and redundant implemen- Although UNIX commands are simple, they can be com- tations that forced special users as designers to use a huge bined to accomplish complex tasks by piping the output of list of tools in order to accomplish a bigger task. In this one command, into another's input.
    [Show full text]
  • Modeling of Hardware and Software for Specifying Hardware Abstraction
    Modeling of Hardware and Software for specifying Hardware Abstraction Layers Yves Bernard, Cédric Gava, Cédrik Besseyre, Bertrand Crouzet, Laurent Marliere, Pierre Moreau, Samuel Rochet To cite this version: Yves Bernard, Cédric Gava, Cédrik Besseyre, Bertrand Crouzet, Laurent Marliere, et al.. Modeling of Hardware and Software for specifying Hardware Abstraction Layers. Embedded Real Time Software and Systems (ERTS2014), Feb 2014, Toulouse, France. hal-02272457 HAL Id: hal-02272457 https://hal.archives-ouvertes.fr/hal-02272457 Submitted on 27 Aug 2019 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Modeling of Hardware and Software for specifying Hardware Abstraction Layers Yves BERNARD1, Cédric GAVA2, Cédrik BESSEYRE1, Bertrand CROUZET1, Laurent MARLIERE1, Pierre MOREAU1, Samuel ROCHET2 (1) Airbus Operations SAS (2) Subcontractor for Airbus Operations SAS Abstract In this paper we describe a practical approach for modeling low level interfaces between software and hardware parts based on SysML operations. This method is intended to be applied for the development of drivers involved on what is classically called the “hardware abstraction layer” or the “basic software” which provide high level services for resources management on the top of a bare hardware platform.
    [Show full text]
  • Release Notes for X11R7.5 the X.Org Foundation 1
    Release Notes for X11R7.5 The X.Org Foundation 1 October 2009 These release notes contains information about features and their status in the X.Org Foundation X11R7.5 release. Table of Contents Introduction to the X11R7.5 Release.................................................................................3 Summary of new features in X11R7.5...............................................................................3 Overview of X11R7.5............................................................................................................4 Details of X11R7.5 components..........................................................................................5 Build changes and issues..................................................................................................10 Miscellaneous......................................................................................................................11 Deprecated components and removal plans.................................................................12 Attributions/Acknowledgements/Credits......................................................................13 Introduction to the X11R7.5 Release This release is the sixth modular release of the X Window System. The next full release will be X11R7.6 and is expected in 2010. Unlike X11R1 through X11R6.9, X11R7.x releases are not built from one monolithic source tree, but many individual modules. These modules are distributed as individ- ual source code releases, and each one is released when it is ready, instead
    [Show full text]
  • Thread Scheduling in Multi-Core Operating Systems Redha Gouicem
    Thread Scheduling in Multi-core Operating Systems Redha Gouicem To cite this version: Redha Gouicem. Thread Scheduling in Multi-core Operating Systems. Computer Science [cs]. Sor- bonne Université, 2020. English. tel-02977242 HAL Id: tel-02977242 https://hal.archives-ouvertes.fr/tel-02977242 Submitted on 24 Oct 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Ph.D thesis in Computer Science Thread Scheduling in Multi-core Operating Systems How to Understand, Improve and Fix your Scheduler Redha GOUICEM Sorbonne Université Laboratoire d’Informatique de Paris 6 Inria Whisper Team PH.D.DEFENSE: 23 October 2020, Paris, France JURYMEMBERS: Mr. Pascal Felber, Full Professor, Université de Neuchâtel Reviewer Mr. Vivien Quéma, Full Professor, Grenoble INP (ENSIMAG) Reviewer Mr. Rachid Guerraoui, Full Professor, École Polytechnique Fédérale de Lausanne Examiner Ms. Karine Heydemann, Associate Professor, Sorbonne Université Examiner Mr. Etienne Rivière, Full Professor, University of Louvain Examiner Mr. Gilles Muller, Senior Research Scientist, Inria Advisor Mr. Julien Sopena, Associate Professor, Sorbonne Université Advisor ABSTRACT In this thesis, we address the problem of schedulers for multi-core architectures from several perspectives: design (simplicity and correct- ness), performance improvement and the development of application- specific schedulers.
    [Show full text]
  • Foot Prints Feel the Freedom of Fedora!
    The Fedora Project: Foot Prints Feel The Freedom of Fedora! RRaahhuull SSuunnddaarraamm SSuunnddaarraamm@@ffeeddoorraapprroojjeecctt..oorrgg FFrreeee ((aass iinn ssppeeeecchh aanndd bbeeeerr)) AAddvviiccee 101011:: KKeeeepp iitt iinntteerraaccttiivvee!! Credit: Based on previous Fedora presentations from Red Hat and various community members. Using the age old wisdom and Indian, Free software tradition of standing on the shoulders of giants. Who the heck is Rahul? ( my favorite part of this presentation) ✔ Self elected Fedora project monkey and noisemaker ✔ Fedora Project Board Member ✔ Fedora Ambassadors steering committee member. ✔ Fedora Ambassador for India.. ✔ Editor for Fedora weekly reports. ✔ Fedora Websites, Documentation and Bug Triaging projects volunteer and miscellaneous few grunt work. Agenda ● Red Hat Linux to Fedora & RHEL - Why? ● What is Fedora ? ● What is the Fedora Project ? ● Who is behind the Fedora Project ? ● Primary Principles. ● What are the Fedora projects? ● Features, Future – Fedora Core 5 ... The beginning: Red Hat Linux 1994-2003 ● Released about every 6 months ● More stable “ .2” releases about every 18 months ● Rapid innovation ● Problems with retail channel sales model ● Impossible to support long-term ● Community Participation: ● Upstream Projects ● Beta Team / Bug Reporting The big split: Fedora and RHEL Red Hat had two separate, irreconcilable goals: ● To innovate rapidly. To provide stability for the long-term ● Red Hat Enterprise Linux (RHEL) ● Stable and supported for 7 years plus. A platform for 3rd party standardization ● Free as in speech ● Fedora Project / Fedora Core ● Rapid releases of Fedora Core, every 6 months ● Space to innovate. Fedora Core in the tradition of Red Hat Linux (“ FC1 == RHL10” ) Free as in speech, free as in beer, free as in community support ● Built and sponsored by Red Hat ● ...with increased community contributions.
    [Show full text]
  • The Pulseaudio Sound Server Linux.Conf.Au 2007
    Introduction What is PulseAudio? Usage Internals Recipes Outlook The PulseAudio Sound Server linux.conf.au 2007 Lennart Poettering [email protected] Universit¨atHamburg, Department Informatik University of Hamburg, Department of Informatics Hamburg, Germany January 17th, 2007 Lennart Poettering The PulseAudio Sound Server 2 What is PulseAudio? 3 Usage 4 Internals 5 Recipes 6 Outlook Introduction What is PulseAudio? Usage Internals Recipes Outlook Contents 1 Introduction Lennart Poettering The PulseAudio Sound Server 3 Usage 4 Internals 5 Recipes 6 Outlook Introduction What is PulseAudio? Usage Internals Recipes Outlook Contents 1 Introduction 2 What is PulseAudio? Lennart Poettering The PulseAudio Sound Server 4 Internals 5 Recipes 6 Outlook Introduction What is PulseAudio? Usage Internals Recipes Outlook Contents 1 Introduction 2 What is PulseAudio? 3 Usage Lennart Poettering The PulseAudio Sound Server 5 Recipes 6 Outlook Introduction What is PulseAudio? Usage Internals Recipes Outlook Contents 1 Introduction 2 What is PulseAudio? 3 Usage 4 Internals Lennart Poettering The PulseAudio Sound Server 6 Outlook Introduction What is PulseAudio? Usage Internals Recipes Outlook Contents 1 Introduction 2 What is PulseAudio? 3 Usage 4 Internals 5 Recipes Lennart Poettering The PulseAudio Sound Server Introduction What is PulseAudio? Usage Internals Recipes Outlook Contents 1 Introduction 2 What is PulseAudio? 3 Usage 4 Internals 5 Recipes 6 Outlook Lennart Poettering The PulseAudio Sound Server Introduction What is PulseAudio? Usage Internals Recipes Outlook Who Am I? Student (Computer Science) from Hamburg, Germany Core Developer of PulseAudio, Avahi and a few other Free Software projects http://0pointer.de/lennart/ [email protected] IRC: mezcalero Lennart Poettering The PulseAudio Sound Server Introduction What is PulseAudio? Usage Internals Recipes Outlook Introduction Lennart Poettering The PulseAudio Sound Server It’s a mess! There are just too many widely adopted but competing and incompatible sound systems.
    [Show full text]
  • HAL Manual V2.5, 2018-10-21 I
    HAL Manual V2.5, 2018-10-21 i HAL Manual V2.5, 2018-10-21 HAL Manual V2.5, 2018-10-21 ii Contents I Hardware Abstract Layer1 1 HAL Introduction 2 1.1 HAL is based on traditional system design techniques................................2 1.1.1 Part Selection.................................................2 1.1.2 Interconnection Design............................................2 1.1.3 Implementation................................................3 1.1.4 Testing....................................................3 1.1.5 Summary...................................................3 1.2 HAL Concepts....................................................4 1.3 HAL components...................................................5 1.3.1 External Programs with HAL hooks.....................................5 1.3.2 Internal Components.............................................5 1.3.3 Hardware Drivers...............................................6 1.3.4 Tools and Utilities..............................................6 1.4 Timing Issues In HAL................................................6 2 Advanced HAL Tutorial 8 2.1 Introduction......................................................8 2.1.1 Notation...................................................8 2.1.2 Tab-completion................................................8 2.1.3 The RTAPI environment...........................................8 2.2 A Simple Example..................................................9 2.2.1 Loading a component.............................................9 2.2.2 Examining the
    [Show full text]
  • Debian and Ubuntu
    Debian and Ubuntu Lucas Nussbaum lucas@{debian.org,ubuntu.com} lucas@{debian.org,ubuntu.com} Debian and Ubuntu 1 / 28 Why I am qualified to give this talk Debian Developer and Ubuntu Developer since 2006 Involved in improving collaboration between both projects Developed/Initiated : Multidistrotools, ubuntu usertag on the BTS, improvements to the merge process, Ubuntu box on the PTS, Ubuntu column on DDPO, . Attended Debconf and UDS Friends in both communities lucas@{debian.org,ubuntu.com} Debian and Ubuntu 2 / 28 What’s in this talk ? Ubuntu development process, and how it relates to Debian Discussion of the current state of affairs "OK, what should we do now ?" lucas@{debian.org,ubuntu.com} Debian and Ubuntu 3 / 28 The Ubuntu Development Process lucas@{debian.org,ubuntu.com} Debian and Ubuntu 4 / 28 Linux distributions 101 Take software developed by upstream projects Linux, X.org, GNOME, KDE, . Put it all nicely together Standardization / Integration Quality Assurance Support Get all the fame Ubuntu has one special upstream : Debian lucas@{debian.org,ubuntu.com} Debian and Ubuntu 5 / 28 Ubuntu’s upstreams Not that simple : changes required, sometimes Toolchain changes Bugfixes Integration (Launchpad) Newer releases Often not possible to do work in Debian first lucas@{debian.org,ubuntu.com} Debian and Ubuntu 6 / 28 Ubuntu Packages Workflow lucas@{debian.org,ubuntu.com} Debian and Ubuntu 7 / 28 Ubuntu Packages Workflow Ubuntu Karmic Excluding specific packages language-(support|pack)-*, kde-l10n-*, *ubuntu*, *launchpad* Missing 4% : Newer upstream
    [Show full text]
  • Developing Programs Using the Hardware Abstraction Layer, Nios II
    6. Developing Programs Using the Hardware Abstraction Layer January 2014 NII52004-13.1.0 NII52004-13.1.0 This chapter discusses how to develop embedded programs for the Nios® II embedded processor based on the Altera® hardware abstraction layer (HAL). This chapter contains the following sections: ■ “The Nios II Embedded Project Structure” on page 6–2 ■ “The system.h System Description File” on page 6–4 ■ “Data Widths and the HAL Type Definitions” on page 6–5 ■ “UNIX-Style Interface” on page 6–5 ■ “File System” on page 6–6 ■ “Using Character-Mode Devices” on page 6–8 ■ “Using File Subsystems” on page 6–15 ■ “Using Timer Devices” on page 6–16 ■ “Using Flash Devices” on page 6–19 ■ “Using DMA Devices” on page 6–25 ■ “Using Interrupt Controllers” on page 6–30 ■ “Reducing Code Footprint in Embedded Systems” on page 6–30 ■ “Boot Sequence and Entry Point” on page 6–37 ■ “Memory Usage” on page 6–39 ■ “Working with HAL Source Files” on page 6–44 The application program interface (API) for HAL-based systems is readily accessible to software developers who are new to the Nios II processor. Programs based on the HAL use the ANSI C standard library functions and runtime environment, and access hardware resources with the HAL API’s generic device models. The HAL API largely conforms to the familiar ANSI C standard library functions, though the ANSI C standard library is separate from the HAL. The close integration of the ANSI C standard library and the HAL makes it possible to develop useful programs that never call the HAL functions directly.
    [Show full text]
  • Running Android on the Raspberry Pi
    Running Android on the Raspberry Pi Android Pie meets Raspberry Pi Chris Simmonds Android Makers 2019 Running Android on the Raspberry Pi1 Copyright © 2011-2019, 2net Ltd License These slides are available under a Creative Commons Attribution-ShareAlike 4.0 license. You can read the full text of the license here http://creativecommons.org/licenses/by-sa/4.0/legalcode You are free to • copy, distribute, display, and perform the work • make derivative works • make commercial use of the work Under the following conditions • Attribution: you must give the original author credit • Share Alike: if you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one (i.e. include this page exactly as it is) • For any reuse or distribution, you must make clear to others the license terms of this work Running Android on the Raspberry Pi2 Copyright © 2011-2019, 2net Ltd About Chris Simmonds • Consultant and trainer • Author of Mastering Embedded Linux Programming • Working with embedded Linux since 1999 • Android since 2009 • Speaker at many conferences and workshops "Looking after the Inner Penguin" blog at http://2net.co.uk/ @2net_software https://uk.linkedin.com/in/chrisdsimmonds/ Running Android on the Raspberry Pi3 Copyright © 2011-2019, 2net Ltd • It’s a good testing ground for new ideas • It’s fun! No, really it is! Why? • Porting Android to a dev board is a great way to learn about Android Running Android on the Raspberry Pi4 Copyright © 2011-2019, 2net Ltd • It’s fun! No, really
    [Show full text]
  • Hotplugging with Udev, HAL, and D-Bus HOTHOT WIREDWIRED
    LINUXKNOW-HOW USER SchlagwortHotplugging sollte hier stehen Hotplugging with Udev, HAL, and D-Bus HOTHOT WIREDWIRED Hardware which just works is what every user wants. Current Linux distributions go a long way to fulfilling that dream. In this article, we will be investigating how the hotplug system works. BY OLIVER FROMMEL, MARCEL HILZINGER AND RENÉ REBE s it really that difficult? You only wanted Linux to launch the right manages the actions associated with a Iprogram when you attached your hotplug event. In this case, the agent new digital camera, but the operating manages the task of adding and register- which in turn start other agents. It is system has decided to sit this one out. ing the new device. common for multiple hotplug agents to This scenario is all too common, The steps the agent performs may work together. For example, when you although the situation has started to vary depending on your distribution and connect an external hard disk, first the improve. Linux should handle any kind the type of hardware you are installing. USB agent loads, then the SCSI agent of hardware correctly, but the ability to Since most hotplug-capable hardware loads to mount the individual partitions manage USB and Firewire devices attaches to a USB port, the USB agent is as SCSI devices with the help of the usb- plugged in or unplugged while the com- perhaps a good example. The USB agent storage module. If you attach a Bluetooth puter is running (known as hotplugging first checks if a driver is available for the dongle, the USB agent runs first, fol- [1]) has become increasingly important.
    [Show full text]