• Refine Query
  • Source
  • Publication year
  • to
  • Language
  • 16
  • 3
  • 2
  • 1
  • 1
  • 1
  • 1
  • 1
  • Tagged with
  • 31
  • 31
  • 19
  • 16
  • 13
  • 13
  • 11
  • 7
  • 7
  • 6
  • 6
  • 5
  • 5
  • 4
  • 4
  • About
  • The Global ETD Search service is a free service for researchers to find electronic theses and dissertations. This service is provided by the Networked Digital Library of Theses and Dissertations.
    Our metadata is collected from universities around the world. If you manage a university/consortium/country archive and want to be added, details can be found on the NDLTD website.
1

Performance Optimizations for Isolated Driver Domains

Shirole, Sushrut Madhukar 23 June 2014 (has links)
In most of today's operating system architectures, device drivers are tightly coupled with other kernel components. In such systems, a fault caused by a malicious or faulty device driver often leads to complete system failure, thereby reducing the overall reliability of the system. Even though a majority of the operating systems provide protection mechanisms at the user level, they do not provide the same level of protection for kernel components. Using virtualization, device drivers can be executed in separate, isolated virtual machines, called driver domains. Such domains provide the same level of isolation to device drivers as operating systems provide to user level applications. Domain-based isolation has the advantage that it is compatible with existing drivers and transparent to the kernel. However, domain-based isolation incurs significant performance overhead due to the necessary interdomain communication. This thesis investigates techniques for reducing this overhead. The key idea is to replace the interrupt-based notification between domains with a spinning-based approach, thus trading CPU capacity for increased throughput. We implemented a prototype, called the Isolated Device Driver system (IDDR), which includes front-end and back-end drivers and a communication module. We evaluated the impact of our optimizations for a variety of block devices. Our results show that our solution matches or outperforms Xen's isolated driver domain in most scenarios we considered. / Master of Science
2

DRVBLD: a UNIX Device Driver Builder

Cano, Agustin F. 05 1900 (has links)
New peripheral devices are being developed at an ever increasing rate. Before such accessories can be used in the UNIX environment (UNIX is a trademark of Bell Laboratories), they must be able to communicate with the operating system. This involves writing a device driver for each device. In order to do this, very detailed knowledge is required of both the device to be integrated and the version of UNIX to which it will be attached. The process is long, detailed and prone to subtle problems and errors. This paper presents a menu-driven utility designed to simplify and accelerate the design and implementation of UNIX device drivers by freeing developers from many of the implementation specific low-level details.
3

A comparative study of the Linux and windows device driver architecture with a focus on IEEE1394 (high speed serial bus) drivers /

Tsegaye, Melekam Asrat. January 2002 (has links)
Thesis (M. Sc. (Computer Science))--Rhodes University, 2004.
4

Device drivers : a comparison of different development strategies

Loubser, Johannes Jacobus 03 1900 (has links)
Thesis (MSc)--Stellenbosch University, 2000. / ENGLISH ABSTRACT: Users are not supposed to modify an operating system kernel, but it is often necessary to add a device driver for a new peripheral device. Device driver development is a difficult and time-consuming process that must be performed by an expert. Drivers are difficult to debug and a malfunctioning driver could cause the operating system to crash. Ways are therefore needed to make the development of device drivers safer and easier. A number of different device driver development methods are examined in this thesis. An existing micro-kernel that supports in-kernel device drivers as well as extensible device drivers has been modified to support user-level and loadable drivers. These extensions ensured that all the development methods were implemented in the same environment and a comparison could thus be made on a fair basis. A comparison of the different methods with respect to the efficiency of the resulting device driver, as well as the ease of the development process, is presented. / AFRIKAANSE OPSOMMING: Gebruikers is nie veronderstelom aan 'n bedryfstelsel te verander nie, maar tog is dit gereeld nodig om 'n toesteldrywer vir 'n nuwe randapparaat by te voeg. Die ontwikkeling van 'n toesteldrywer is 'n tydrowende en moeilike proses en moet deur 'n kundige aangepak word. Toesteldrywers is moeilik om te ontfout en kan deur verkeerde werking die hele stelsel tot stilstand bring. Daar is dus tegnieke nodig om die ontwikkeling van toestelhanteerders makliker en veiliger te maak. 'n Aantal verskillende ontwikkelingsmetodes vir toesteldrywers word in hierdie tesis ondersoek. 'n Bestaande mikro-kern wat in-kern, sowel as uitbreibare toesteldrywers ondersteun, is aangepas om gebruikersvlak en laaibare toestelhanteerders te ondersteun. Hierdie uitbreiding het verseker dat al die ontwikkelingsmetodes in dieselfde omgewing geïmplementeer is. Dit was dus moontlik om die metodes op 'n regverdige grondslag te vergelyk. Die vergelyking is gedoen ten opsigte van die effektiwiteit van die resulterende toesteldrywer sowel as die moeilikheidsgraad van die ontwikkelingsproses.
5

A DEVICE DRIVER ARCHITECTURE FOR TELEMETRY APPLICATIONS

DiLemmo, Marc C. 10 1900 (has links)
International Telemetering Conference Proceedings / October 26-29, 1998 / Town & Country Resort Hotel and Convention Center, San Diego, California / This paper illustrates a device driver implementation used to support a PC compatible telemetry device. Device requirements included operation on Windows NT 4.0, Windows 95, Windows NT 5.0 and Windows 98 platforms. A single device driver was not possible due to the differences between driver requirements on the various operating systems. The Windows Driver Model (WDM) was considered for NT 5.0 and Win98, however, NT 4.0 and Win95 does not support the WDM. To minimize software development and support efforts, it was clear that an architecture compatible to both WDM, NT 4.0 and Windows 95 needed to be developed. The resulting layered device driver architecture provides a common upper interface and uses a register based model to describe the hardware at the lower interface. The common upper interface is compatible with all of the target operating systems and presents a consistent Applications Programming Interface (API) for the telemetry application developer. The lower interface is specific for each platform but contains minimal device specific functionality. A simple register I/O driver is easily implemented using all of the target operating systems. The layered architecture and register based interface to the hardware results in a multiple operating system code set which differs only at the lowest layer.
6

On the construction of reliable device drivers

Ryzhyk, Leonid, Computer Science & Engineering, Faculty of Engineering, UNSW January 2009 (has links)
This dissertation is dedicated to the problem of device driver reliability. Software defects in device drivers constitute the biggest source of failure in operating systems, causing significant damage through downtime and data loss. Previous research on driver reliability has concentrated on detecting and mitigating defects in existing drivers using static analysis or runtime isolation. In contrast, this dissertation presents an approach to reducing the number of defects through an improved device driver architecture and development process. In analysing factors that contribute to driver complexity and induce errors, I show that a large proportion of errors are due to two key shortcomings in the device-driver architecture enforced by current operating systems: poorly-defined communication protocols between drivers and the operating system, which confuse developers and lead to protocol violations, and a multithreaded model of computation, which leads to numerous race conditions and deadlocks. To address the first shortcoming, I propose to describe driver protocols using a formal, state-machine based, language, which avoids confusion and ambiguity and helps driver writers implement correct behaviour. The second issue is addressed by abandoning multithreading in drivers in favour of a more disciplined event-driven model of computation, which eliminates most concurrency-related faults. These improvements reduce the number of defects without radically changing the way drivers are developed. In order to further reduce the impact of human error on driver reliability, I propose to automate the driver development process by synthesising the implementation of a driver from the combination of three formal specifications: a device-class specification that describes common properties of a class of similar devices, a device specification that describes a concrete representative of the class, and an operating system interface specification that describes the communication protocol between the driver and the operating system. This approach allows those with the most appropriate skills and knowledge to develop specifications: device specifications are developed by device manufacturers, operating system specifications by the operating system designers. The device-class specification is the only one that requires understanding of both hardware and software-related issues. However writing such a specification is a one-off task that only needs to be completed once for a class of devices. This approach also facilitates the reuse of specifications: a single operating-system specification can be combined with many device specifications to synthesise drivers for multiple devices. Likewise, since device specifications are independent of any operating system, drivers for different systems can be synthesised from a single device specification. As a result, the likelihood of errors due to incorrect specifications is reduced because these specifications are shared by many drivers. I demonstrate that the proposed techniques can be incorporated into existing operating systems without sacrificing performance or functionality by presenting their implementation in Linux. This implementation allows drivers developed using these techniques to coexist with conventional Linux drivers, providing a gradual migration path to more reliable drivers.
7

Improving the reliability of commodity operating systems /

Swift, Michael M. January 2005 (has links)
Thesis (Ph. D.)--University of Washington, 2005. / Vita. Includes bibliographical references (p. 137-154).
8

Aquarius II Uma plataforma para desenvolvimento de sistemas dinamicamente reconfiguráveis baseada no sistema operacional uCLinux

Wanderley Costa de Medeiros, Victor January 2007 (has links)
Made available in DSpace on 2014-06-12T16:00:24Z (GMT). No. of bitstreams: 2 arquivo6554_1.pdf: 3066452 bytes, checksum: 91820a83661287c92ba4438dd8c7a4d7 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2007 / Os dispositivos lógicos programáveis, FPGAs (Field Programmable Gate Arrays) há algum tempo têm sido uma tecnologia interessante para prototipação de circuitos digitais. Porém, esta realidade tem mudado à medida que a capacidade computacional destes dispositivos tem aumentado e o custo diminuído. Além disso, os FPGAs atuais podem utilizar menos energia que uma CPU convencional utilizaria para realizar a mesma computação. Outra característica, que traz grandes possibilidades, é a capacidade de reconfiguração em tempo de execução (reconfiguração dinâmica). Todos estes avanços permitiram a utilização dos FPGAs não só em aplicações típicas como sistemas embarcados mas também em sistemas de alto desempenho, que realizam processamento massivo de dados. Contudo, apesar das diversas vantagens apresentadas, esta tecnologia ainda não é largamente utilizada para realizar computação. Várias são as razões para isso, entre elas a exigência de um mínimo conhecimento em eletrônica digital para possibilitar o desenvolvimento dos IP-Cores; a complexidade do processo de desenvolvimento destes sistemas; os custos elevados com licenças das ferramentas e com as plataformas de desenvolvimento e a pouca portabilidade das aplicações desenvolvidas. O objetivo deste trabalho é prover uma plataforma reconfigurável que seja capaz, através de um sistema operacional e de maneira eficiente, gerenciar os recursos oferecidos pelos FPGAs. A plataforma proposta recebeu o nome de Aquarius II e foi baseada na plataforma Aquarius desenvolvida no CIn-UFPE. A arquitetura desta plataforma é híbrida e consiste de um FPGA Stratix-II da Altera responsável pelo controle da reconfiguração e tráfego dos dados e de um FPGA Virtex-II da Xilinx que é o elemento reconfigurável propriamente dito. Foram incorporados a esta plataforma um módulo de comunicação (IPCommCore) que é responsável pelo tráfego de dados do sistema operacional para a memória do dispositivo reconfigurável, um device driver para que o sistema operacional uCLinux possa controlar a comunicação através deste módulo e também foi definida uma interface de comunicação padrão para os cores reconfiguráveis que vierem a ser implementados. Para validar esta interface foi implementado e validado um core multiplicador para o Virtex-II utilizado como estudo de caso. Esta plataforma permitirá que sejam realizadas pesquisas em áreas que buscam se beneficiar desta tecnologia, como desenvolvimento de sistemas embarcados e sistemas de alta performance. O desenvolvimento de sistemas computacionais que utilizam hardware reconfigurável em sua arquitetura ainda é pouco comum e complexo. No entanto, propostas como a apresentada neste trabalho procuram solucionar ou atenuar os problemas citados e mudar sensivelmente esta realidade tornando viáveis e mais populares soluções que utilizam esta tecnologia
9

A comparative study of the Linux and windows device driver architecture with a focus on IEEE1394 (high speed serial bus) drivers

Tsegaye, Melekam Asrat January 2004 (has links)
New hardware devices are continually being released to the public by hardware manufactures around the world. For these new devices to be usable under a PC operating system, device drivers that extend the functionality of the target operating system have to be constructed. This work examines and compares the device driver architectures currently in use by two of the most widely used operating systems, Microsoft’s Windows and Linux. The IEEE1394 (high speed serial bus) device driver stacks on each operating system are examined and compared as an example of a major device driver stack implementation, including driver requirements for the upcoming IEEE1394.1 bridging standard.
10

Virtuelle Absicherung von Steuergeräte-Software mit hardwareabhängigen Komponenten / Virtual Verification of ECU Software with hardware-dependent Components

Deicke, Markus 02 February 2018 (has links) (PDF)
Der stetig steigende Funktionsumfang im Automobil und die zunehmende Vernetzung von Steuergeräten erfordern neue Methoden zur Beherrschung der Komplexität in der Validierung und Verifikation. Die virtuelle Absicherung ermöglicht die Integration der Software in einem PC-System, unabhängig von der Ziel-Hardware, zur frühzeitigen Gewährleistung der Softwarequalität im Entwicklungsprozess. Ebenso kann die Wiederverwendbarkeit vorhandener Komponenten in zukünftigen Mikrocontrollern sichergestellt werden. Die Grundlage dafür liefert der AUTOSAR-Standard durch einheitliche Schnittstellenbeschreibungen, welche die Abstraktion von Hardware und Software ermöglichen. Allerdings enthält der Standard hardwareabhängige Software-Komponenten, die als Complex-Device-Drivers (CDDs) bezeichnet werden. Aufgrund ihrer Hardwareabhängigkeit sind CDDs nicht direkt in eine virtuelle Absicherungsplattform integrierbar, da die spezifischen Hardware-Module nicht verfügbar sind. Die Treiber sind dennoch Teil der Steuergeräte-Software und somit bei einem ganzheitlichen Absicherungsansatz mit zu betrachten. Diese Dissertation beschreibt sieben unterschiedliche Konzepte zur Berücksichtigung von CDDs in der virtuellen Absicherung. Aus der Evaluierung der Praxistauglichkeit aller Ansätze wird eine Auswahlmethodik für die optimale Lösung bei sämtlichen Anwendungsfällen von CDDs in der Steuergeräte-Software entwickelt. Daraus abgeleitet, eignen sich zwei der Konzepte für die häufigsten Anwendungsfälle, die im Weiteren detailliert beschrieben und realisiert werden. Das erste Konzept erlaubt die vollständige Simulation eines CDD. Dies ist notwendig, um die Integration der Funktions-Software selbst ohne den Treiber zu ermöglichen und alle Schnittstellen abzusichern, auch wenn der CDD noch nicht verfügbar ist. Durch eine vollständige Automatisierung ist die Erstellung der Simulation nur mit geringem Arbeitsaufwand verbunden. Das zweite Konzept ermöglicht die vollständige Integration eines CDD, wobei die Hardware-Schnittstellen über einen zusätzlichen Hardware-Abstraction-Layer an die verfügbare Hardware des Systems zur virtuellen Absicherung angebunden werden. So ist der Treiber in der Lage, reale Hardware-Komponenten anzusteuern und kann funktional abgesichert werden. Eine flexible Konfiguration der Abstraktionsschicht erlaubt den Einsatz für eine große Bandbreite von CDDs. Im Rahmen der Arbeit werden beide Konzepte anhand von industrierelevanten Projekten aus der Serienentwicklung erprobt und detailliert evaluiert. / The constantly increasing amount of functions in modern automobiles and the growing degree of cross-linking between electronic control units (ECU) require new methods to master the complexity in the validation and verification process. The virtual validation and verification enables the integration of the software on a PC system, which is independent from the target hardware, to guarantee the required software quality in the early development stages. Furthermore, the software reuse in future microcontrollers can be verified. All this is enabled by the AUTOSAR standard which provides consistent interface descriptions to allow the abstraction of hardware and software. However, the standard contains hardware-dependent components, called complex device drivers (CDD). Those CDDs cannot be directly integrated into a platform for virtual verification, because they require a specific hardware which is not generally available on such a platform. Regardless, CDDs are an essential part of the ECU software and therefore need to be considered in an holistic approach for validation and verification. This thesis describes seven different concepts to include CDDs in the virtual verification process. A method to always choose the optimal solution for all use cases of CDDs in ECU software is developed using an evaluation of the suitably for daily use of all concepts. As a result from this method, the two concepts suited for the most frequent use cases are detailed and developed as prototypes in this thesis. The first concept enables the full simulation of a CDD. This is necessary to allow the integration of the functional software itself without the driver. This way all interfaces can be tested even if the CDD is not available. The complete automation of the generation of the simulation makes the process very efficient. With the second concept a CDD can be entirely integrated into a platform for virtual verification, using an hardware abstraction layer to connect the hardware interfaces to the available hardware of the platform. This way, the driver is able to control real hardware components and can be tested completely. A flexible configuration of the abstraction layer allows the application of the concept for a wide variety of CDDs. In this thesis both concepts are tested and evaluated using genuine projects from series development.

Page generated in 0.0563 seconds