DOCSLIB.ORG

Unix to Linux Migration

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Unix to Linux Migration UNIX TO LINUX MIGRATION RICHARD KEECH ABSTRACT This paper aims to show the benefits of choosing Linux and migrating existing UNIX environments to the Linux platform. This applies in particular to migrations from RISC-based platforms. It also shows the extent to which Linux is now a trusted, mainstream platform and how any technical risks associated with migrations can be mitigated. This paper addresses a technical audience. www.redhat.com UNIX to Linux migration | Richard Keech TABLE OF CONTENTS AIMS Page 3 INTRODUCTION TO LINUX Page 3 OpEN SOURCE AND LINUX Page 4 RED HAT ENTErprISE LINUX Page 5 UNIX VS LINUX Page 8 TrENDS Page 9 Server Virtualization Page 9 Clustering Page 10 Rapid provisioning and appliance OS Page 10 Instrumentation and debugging Page 10 MIGRATION CONSIDERATIONS Page 11 Qualify the stack Page 11 Porting Page 12 Training Page 12 Prepare a Linux standard build Page 12 Pilot deployment Page 13 CONCLUSIONS Page 13 REFERENCES Page 14 2 www.redhat.com UNIX to Linux migration | Richard Keech AIMS This paper aims to give an introduction to Linux for the technically inclined and educated reader at a level that can allow proper comparisons with UNIX. The paper provides an outline of the key considerations in selecting Linux and migrating from UNIX to Red Hat Enterprise Linux. The intended audience of this paper is enterprise infrastructure architects. INTRODUCTION TO LINUX Benefits. The Linux platform offers a low-risk, robust, and value-for-money alternative to traditional UNIX. Linux is now sufficiently mature enough to handle the most demanding workloads at a much lower cost than proprietary UNIX offerings. At the same time, Linux leverages the open source development and subscription model, which guarantees a constant stream of innovation fueled by a healthy multi- dimensional community of users and developers. This is an important aspect, as not only does it truly prevent proprietary lock-in, but also enables a level of access to skills, documentation, on-line forums, and so on, to a level unheard of before with any other operating system.[20] Maturity. Large-scale commercial deployments of Linux became noticeable in 1998. With the benefit of another decade’s rapid development, Linux has reached a degree of maturity that meets or exceeds commercial UNIX. According to IDC,[1] “Linux ... early adoption patterns have given way to mainstream deployment.” Scalability. As an example of Linux’s capacity to scale up, in June 2008 the US Department of Energy announced the world’s fastest supercomputer known as Roadrunner[2] based on Red Hat Enterprise Linux.[3] Another recent example is the New York Stock Exchange Euronext (NYSE Euronext) runs its entire trading operations on Red Hat Enterprise Linux and replaced every popular flavor of UNIX to achieve the scalability and reliability they require. Feature-rich. Linux now more than holds its own for features compared to UNIX offerings. For some time Linux has included journaling file systems, logical volume management (LVM), advanced multipath IO capabilities, clustering, as well as services for modular provisioning, management, and patching. Today Linux comes standard with server virtualization and world-leading enhanced security such as SELinux. Solutions. There is a great breadth of solutions and software available on Linux today. Many customers have found that the bundled open source offerings, often referred to as the application stack, meets their needs. If not, then there is a large ecosystem of ISVs to choose from who now fully support Linux. This number continues to grow as more and more customers demand Linux support from their ISVs. www.redhat.com 3 UNIX to Linux migration | Richard Keech OPEN SOURCE AND LINUX The open source method. Organizations adopting Linux can be confident in the underlying open source method. According to the Open Source Initiative, “Open source is a development method for software that harnesses the power of distributed peer review and transparency of process. The promise of open source is better quality, higher reliability, more flexibility, lower cost, and an end to vendor lock-in.”[29] Open source maturity. Open source has emerged and matured to the point where it is now broadly accepted. Gartner has stated, “By 2012, more than 90 percent of enterprises will use open source in direct or embedded forms.”[4] Red Hat engineering. Linux distributors such as Red Hat start with the Linux kernel and many other pieces of open source software. Subsequent engineering processes create a coherent, tested, and enterprise-grade product. A key aspect of this process is creating a product life cycle and support services that match that of what businesses require. Specifically for Red Hat Enterprise Linux, this means turning a fast-moving, rapidly changing, innovating code base into something that has a life cycle spanning seven years. In a commercial setting the use of open source has been shown to be safe and free from licensing complications. Open standards. Open source development has a strong track record in following the most important open standards. Increasingly open source development is at the forefront of setting open standards, as has been seen with the emergence of the Open Doc (ODF) standards. Single vendor standards will never be Open Standards. That’s why open source is such a huge contributor to open standards: at the heart of each viable open source initiative or project is a thriving multi-vendor ecosystem. Accordingly, open source development generally has strong imperatives for interoperability. Access to source code. Openly available source code is a very important strategic factor that mitigates risk because it provides: • Verifiability. It is possible to verify that code does what it purports to do, and no more. This is relevant, for example, to confirm that a program does not have back doors or other unexpected ‘features.’ • Assurance of maintenance. Although Red Hat’s support and maintenance is first-class, access to source code means that an organization using Linux always has an alternative, independent of Red Hat. This is a kind of strategic insurance that proprietary software simply cannot provide. Not even through complicated escrow arrangements. • Local derivatives. Occasionally organizations might find that they need critical new features or capabilities in their software. Often such requirements can be met by working with Red Hat directly. However, access to code gives organizations the ultimate choice about how and when capabilities might be added to their software. 4 www.redhat.com UNIX to Linux migration | Richard Keech RED HAT ENTERPRISE LINUX Red Hat Enterprise Linux is the most successful commercially supported Linux distribution.[30] The current release is version 5, released in March 2007. Like its predecessors, Red Hat Enterprise Linux 5 entirely open source and offered commercially via a comprehensive annual support subscription. This subscription model is the basis for Red Hat’s successful and sustainable business model. Red Hat Enterprise Linux major releases, for example version 4 to version 5, occur about every two to two and a half years. Platforms. Red Hat Enterprise Linux is released on the industry’s broadest set of architectures: x86, x86_64, ia64, PowerPC (P- and I-Series), and (s390) Z-Series.[31] This breadth gives a wide range of migration options for organizations using multiple CPU architectures. Support. Red Hat supports Red Hat Enterprise Linux for seven years from the date of initial release.[5] Since Red Hat has no proprietary lock-in, quality support is paramount. One data point showing that Red Hat has been able to give high quality support is the CIO Insight Vendor Value study, which has ranked Red Hat number one enterprise software vendor for four years running.[6] Red Hat takes a highly conservative approach to issuing updates to Red Hat Enterprise Linux so as to reduce the risk of regressions and assure software compatibility[32] across minor releases.[9] Simply put, the stability that users of UNIX are accustomed to is made available for Linux through Red Hat Enterprise Linux. This has been a key enabler for enterprises around the world to reliably switch from proprietary UNIX to Red Hat Enterprise Linux. Capabilities and features. The core technical capabilities of Red Hat Enterprise Linux are available for review at www.redhat.com/rhel/compare/. The table shown here summarizes some of the key supported extremes for a single node running on the commonly used Intel X86_64 architecture using Red Hat Enterprise Linux 5. ITEM VALUE Max RAM 512 GB Max physical/logical CPUs 64/255 Max filesystem sizes 16 TB Max file size 2 TB Software packaging. Red Hat uses a modular software packaging technology called RPM.[12] All Red Hat software is issued as RPM packages, regardless of whether it is core operating system or add on software. The use of RPM underlies Red Hat’s ability to install and manage software efficiently. The RPM standard has been adopted by nearly all commercial Linux vendors. www.redhat.com 5 UNIX to Linux migration | Richard Keech ISVs. Increasingly organizations considering Linux migrations will find that their current software stack is already supported on Red Hat Enterprise Linux. Some compatible software can be seen at www.redhat.com/rhel/compatibility/software/. In many cases, support for Red Hat Enterprise Linux is long-standing. For example, in 1998 all the major commercial database vendors announced support within in the space of a few months.[7] Best practice software packaging by ISVs is to use RPM packages. Variants. Red Hat Enterprise Linux 5 is available in a number of variants. Red Hat Enterprise Linux Server and Red Hat Enterprise Linux Advanced Platform are the server variants. There is also Red Hat Enterprise Linux 5 Desktop. Advanced Platform offers clustering as well as support for unlimited number of virtual machine instances through the integrated virtualization (see Server Virtualization, below).
Load more

Recommended publications
  • Increasing Automation in the Backporting of Linux Drivers Using Coccinelle
    Increasing Automation in the Backporting of Linux Drivers Using Coccinelle Luis R. Rodriguez Julia Lawall Rutgers University/SUSE Labs Sorbonne Universites/Inria/UPMC/LIP6´ [email protected] [email protected] [email protected], [email protected] Abstract—Software is continually evolving, to fix bugs and to a kernel upgrade. Upgrading a kernel may also require add new features. Industry users, however, often value stability, experience to understand what features to enable, disable, or and thus may not be able to update their code base to the tune to meet existing deployment criteria. In the worst case, latest versions. This raises the need to selectively backport new some systems may rely on components that have not yet been features to older software versions. Traditionally, backporting has merged into the mainline Linux kernel, potentially making it been done by cluttering the backported code with preprocessor impossible to upgrade the kernel without cooperation from the directives, to replace behaviors that are unsupported in an earlier version by appropriate workarounds. This approach however component vendor or a slew of partners that need to collaborate involves writing a lot of error-prone backporting code, and results on developing a new productized image for a system. As an in implementations that are hard to read and maintain. We example, development for 802.11n AR9003 chipset support consider this issue in the context of the Linux kernel, for which on the mainline ath9k device driver started on March 20, older versions are in wide use. We present a new backporting 2010 with an early version of the silicon, at which point the strategy that relies on the use of a backporting compatability most recent major release of the Linux kernel was v2.6.32.
    [Show full text]
  • Contributor's Guidelines
    Contributor’s Guidelines Release 17.11.10 Feb 27, 2020 CONTENTS 1 DPDK Coding Style1 1.1 Description.......................................1 1.2 General Guidelines..................................1 1.3 C Comment Style...................................1 1.4 C Preprocessor Directives..............................2 1.5 C Types.........................................4 1.6 C Indentation......................................7 1.7 C Function Definition, Declaration and Use.....................9 1.8 C Statement Style and Conventions......................... 11 1.9 Python Code...................................... 13 2 Design 14 2.1 Environment or Architecture-specific Sources.................... 14 2.2 Library Statistics.................................... 15 2.3 PF and VF Considerations.............................. 16 3 Managing ABI updates 18 3.1 Description....................................... 18 3.2 General Guidelines.................................. 18 3.3 What is an ABI..................................... 18 3.4 The DPDK ABI policy................................. 19 3.5 Examples of Deprecation Notices.......................... 20 3.6 Versioning Macros................................... 20 3.7 Setting a Major ABI version.............................. 21 3.8 Examples of ABI Macro use............................. 21 3.9 Running the ABI Validator............................... 25 4 DPDK Documentation Guidelines 27 4.1 Structure of the Documentation........................... 27 4.2 Role of the Documentation.............................
    [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]
  • Introducting Innovations in Open Source Projects
    Introducing Innovations into Open Source Projects Dissertation zur Erlangung des Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) am Fachbereich Mathematik und Informatik der Freien Universität Berlin von Sinan Christopher Özbek Berlin August 2010 2 Gutachter: Professor Dr. Lutz Prechelt, Freie Universität Berlin Professor Kevin Crowston, Syracuse University Datum der Disputation: 17.12.2010 4 Abstract This thesis presents a qualitative study using Grounded Theory Methodology on the question of how to change development processes in Open Source projects. The mailing list communication of thirteen medium-sized Open Source projects over the year 2007 was analyzed to answer this question. It resulted in eight main concepts revolving around the introduction of innovation, i.e. new processes, services, and tools, into the projects including topics such as the migration to new systems, the question on where to host services, how radical Open Source projects can change their ways, and how compliance to processes and conventions is enforced. These are complemented with (1) the result of five case studies in which innovation introductions were conducted with Open Source projects, and with (2) a theoretical comparison of the results of this thesis to four theories and scientific perspectives from the organizational and social sciences such as Path Dependence, the Garbage Can model, Social-Network analysis, and Actor-Network theory. The results show that innovation introduction is a multifaceted phenomenon, of which this thesis discusses the most salient conceptual aspects. The thesis concludes with practical advice for innovators and specialized hints for the most popular innovations. 5 6 Acknowledgements I want to thank the following individuals for contributing to the completion of this thesis: • Lutz Prechelt for advising me over these long five years.
    [Show full text]
  • Debian Packaging Tutorial
    Debian Packaging Tutorial Lucas Nussbaum [email protected] version 0.27 – 2021-01-08 Debian Packaging Tutorial 1 / 89 About this tutorial I Goal: tell you what you really need to know about Debian packaging I Modify existing packages I Create your own packages I Interact with the Debian community I Become a Debian power-user I Covers the most important points, but is not complete I You will need to read more documentation I Most of the content also applies to Debian derivative distributions I That includes Ubuntu Debian Packaging Tutorial 2 / 89 Outline 1 Introduction 2 Creating source packages 3 Building and testing packages 4 Practical session 1: modifying the grep package 5 Advanced packaging topics 6 Maintaining packages in Debian 7 Conclusions 8 Additional practical sessions 9 Answers to practical sessions Debian Packaging Tutorial 3 / 89 Outline 1 Introduction 2 Creating source packages 3 Building and testing packages 4 Practical session 1: modifying the grep package 5 Advanced packaging topics 6 Maintaining packages in Debian 7 Conclusions 8 Additional practical sessions 9 Answers to practical sessions Debian Packaging Tutorial 4 / 89 Debian I GNU/Linux distribution I 1st major distro developed “openly in the spirit of GNU” I Non-commercial, built collaboratively by over 1,000 volunteers I 3 main features: I Quality – culture of technical excellence We release when it’s ready I Freedom – devs and users bound by the Social Contract Promoting the culture of Free Software since 1993 I Independence – no (single)
    [Show full text]
  • Impacting the Bioscience Progress by Backporting Software for Bio-Linux
    Impacting the bioscience progress by backporting software for Bio-Linux Sasa Paporovic [email protected] v0.9 What is Bio-Linux and what is it good for - also its drawbacks: If someone says to use or to have a Linux this is correct as like it is imprecise. It does not exist a Linux as full functional operating system by itself. What was originally meant by the term Linux was the operating system core[1]. The so called kernel, or in a case of a Linux operating system the Linux kernel. It is originally designed and programmed by Linus Torvalds, who is also today the developer in chef or to say it with his words, he is the “alpha-male” of all developers[2]. Anyway, what we have today are Distributions[3]. It has become common to call them simply “a Linux”. This means that there are organizations out there, mostly private, some funded and some other commercial, which gather all what is needed to design around the Linux kernel a full functional operating system. This targets mostly Software, but also web and service infrastructure. Some of them have a history that is nearly as long as the Linux kernel is alive, like Debian. Some others are younger like Ubuntu and some more others are very young, like Bio-Linux[4]. The last Linux, the Bio-Linux, especially its latest version Bio-Linux 7 we are focusing here[5]. In year 2006 Bio-Linux with the work of Tim Booth[42] and team gives its rising[6] and provide an operating system that was and still specialized in providing a bioinformatic specific software environment for the working needs in this corner of bioscience.
    [Show full text]
  • Oracle Unbreakable Linux: an Overview
    Oracle Unbreakable Linux: An Overview An Oracle White Paper September 2010 Oracle Unbreakable Linux: An Overview INTRODUCTION Oracle Unbreakable Linux is a support program that provides enterprises with industry-leading global support for the Linux operating system at significantly lower costs. The support program, which is available for any customer whether or not they’re running Oracle Unbreakable Linux currently includes support for three architectures: x86; x86-64 (e.g. the latest Intel Xeon and AMD Opteron chips, as used by most Linux customers); and Linux Itanium (ia64). The program offers support for any existing Red Hat Enterprise Linux installations and for new installations of Oracle Linux, an open source Linux operating system that is fully compatible— both source and binary—with Red Hat Enterprise Linux. Complete Support for the Complete Software Stack Oracle’s industry-leading support organization offers expertise that looks at the entire application stack running on top of Linux; only Oracle delivers complete support for the complete software stack—database, middleware, applications, management tools, and the operating system itself. By delivering enterprise-class quality support for Linux, Oracle addresses a key enterprise requirement from customers. When problems occur in a large, complex enterprise environment, it’s often impossible to reproduce such occurrences with very simple test cases. Customers need a support vendor who understands their full environment, and has the expertise to diagnose and resolve the problem by drawing from their knowledge of and familiarity with their framework, as opposed to requesting a simple reproducible test case. Another customer demand is for bug fixes to happen in a timely manner, as customers cannot always afford to wait for months to get a fix delivered to them.
    [Show full text]
  • The 2007 European ICT Prize the 3 European ICT Grand Prize Winners
    CeBIT - Hanover, 16 March 2007 The 2007 European ICT Prize The 3 European ICT Grand Prize Winners Telepo (SE) for Telepo Business Communication solution Telepo's fixed-mobile convergence solution enables efficient business communication anytime, anywhere. [email protected] - www.telepo.com Transitive Corporation (UK) for QuickTransit® Virtualization product that eliminates the hardware-software dependency. [email protected] - www.transitive.com Treventus Mechatronics (AT) for ScanRobot High-speed (up to 2,400 pages/hour) book scanner with integrated fully automatic page-turning for bound documents. [email protected] - www.treventus.com www.ict-prize.org The 2007 European ICT Prize Winners A3M (DE) for A3M Tsunami Alarm System San Disk (IL) for mToken Global Tsunami Warning System for mobile Combines PKI-based two factor authentication, phones, protecting human lives and health. secure storage and smartcard-based applications www.tsunami-alarm-system.com inone USB device. www.m-systems.com/mtoken Byometric Systems (DE) for Large scale iden- T-VIPS (NO) for T-VIPS TVG Video Gateways tification Solution based on iris-recognition Provides professional video market with innovative Biometric access system based on iris-recognition IP transport solutions. www.t-vips.com identification in banking environment. www.byometric.com Telepo (SE) for Telepo Business Communication solution DIGIMIND (FR) for DIGIMIND FINDER Telepo's fixed-mobile convergence solution New vertical meta-search engine revolutionizing enables efficient business communication any- the professional web search experience. time, anywhere. www.telepo.com www.digimind.com TEMIS (FR) for Luxid® g.tec Guger Technologies (AT) Innovative information discovery solution serving for Brain-Computer Interface the information intelligence needs of business/ Interface for cursor control and writing by corporations.
    [Show full text]
  • Binary Translation Using Peephole Superoptimizers
    Binary Translation Using Peephole Superoptimizers Sorav Bansal Alex Aiken Computer Systems Lab Computer Systems Lab Stanford University Stanford University [email protected] [email protected] Abstract tecture performance for compute-intensive applica- We present a new scheme for performing binary trans- tions. lation that produces code comparable to or better than 2. Because the instruction sets of modern machines existing binary translators with much less engineering tend to be large and idiosyncratic, just writing the effort. Instead of hand-coding the translation from one translation rules from one architecture to another instruction set to another, our approach automatically is a significant engineering challenge, especially if learns translation rules using superoptimization tech- there are significant differences in the semantics of niques. We have implemented a PowerPC-x86 binary the two instruction sets. This problem is exacer- translator and report results on small and large compute- bated by the need to perform optimizations wher- intensive benchmarks. When compared to the native ever possible to minimize problem (1). compiler, our translated code achieves median perfor- mance of 67% on large benchmarks and in some small 3. Because high-performancetranslations must exploit stress tests actually outperforms the native compiler. We architecture-specific semantics to maximize perfor- also report comparisons with the open source binary mance, it is challenging to design a binary translator translator Qemu and a commercial tool, Apple's Rosetta. that can be quickly retargeted to new architectures. We consistently outperform the former and are compara- One popular approach is to design a common inter- ble to or faster than the latter on all but one benchmark.
    [Show full text]
  • A Guide to Kernel Exploitation Attacking the Core (2011
    A Guide to Kernel Exploitation This page intentionally left blank A Guide to Kernel Exploitation Attacking the Core Enrico Perla Massimiliano Oldani Technical Editor Graham Speake AMSTERDAM • BOSTON • HEIDELBERG • LONDON • • • NEW YORK OXFORD PARIS SAN DIEGO SYNGRESS SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO ® Syngress is an imprint of Elsevier Acquiring Editor: Rachel Roumeliotis Development Editor: Matthew Cater Project Manager: Julie Ochs Designer: Alisa Andreola Syngress is an imprint of Elsevier 30 Corporate Drive, Suite 400, Burlington, MA 01803, USA © 2011 Elsevier Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher. Details on how to seek permission, further information about the Publisher’s permissions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions. This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein). Notices Knowledge and best practice in this field are constantly changing. As new research and experience broaden our understanding, changes in research methods or professional practices, may become necessary. Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information or methods described herein. In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility.
    [Show full text]
  • BIND 9 Administrator Reference Manual
    BIND 9 Administrator Reference Manual BIND 9.11.31 (Extended Support Version) Copyright (C) 2000-2021 Internet Systems Consortium, Inc. ("ISC") This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/. Internet Systems Consortium, Inc. PO Box 360 Newmarket, NH 03857 USA https://www.isc.org/ Contents 1 Introduction 1 1.1 Scope of Document . .1 1.2 Organization of This Document . .1 1.3 Conventions Used in This Document . .1 1.4 The Domain Name System (DNS) . .2 DNS Fundamentals . .2 Domains and Domain Names . .2 Zones . .3 Authoritative Name Servers . .3 The Primary Server . .3 Secondary Servers . .4 Stealth Servers . .4 Caching Name Servers . .4 Forwarding . .5 Name Servers in Multiple Roles . .5 2 BIND Resource Requirements7 2.1 Hardware requirements . .7 2.2 CPU Requirements . .7 2.3 Memory Requirements . .7 2.4 Name Server-Intensive Environment Issues . .7 2.5 Supported Operating Systems . .8 iii BIND 9.11.31 CONTENTS CONTENTS 3 Name Server Configuration9 3.1 Sample Configurations . .9 A Caching-only Name Server . .9 An Authoritative-only Name Server . .9 3.2 Load Balancing . 10 3.3 Name Server Operations . 11 Tools for Use With the Name Server Daemon . 11 Diagnostic Tools . 11 Administrative Tools . 12 Signals . 13 4 Advanced DNS Features 15 4.1 Notify . 15 4.2 Dynamic Update . 15 The Journal File . 16 4.3 Incremental Zone Transfers (IXFR) . 16 4.4 Split DNS .
    [Show full text]
  • Low Overhead Dynamic Binary Translation for ARM
    Low Overhead Dynamic Binary Translation for ARM A THESIS SUBMITTED TO THE UNIVERSITY OF MANCHESTER FOR THE DEGREE OF DOCTOR OF PHILOSOPHY IN THE FACULTY OF SCIENCE AND ENGINEERING. 2016 Bernard Amanieu d’Antras School of Computer Science 2 Contents Abstract 11 Declaration 12 Copyright 13 Acknowledgments 14 1 Introduction 15 1.1 Binary translation . 16 1.2 Contributions . 19 2 Dynamic Binary Translation 23 2.1 Code caches . 24 2.2 Multi-threading . 27 2.3 Environment . 28 2.4 Transparency . 30 2.5 MAMBO-X64 . 32 2.5.1 Binary translator . 34 2.5.2 System emulator . 36 2.6 Summary . 39 3 3 Optimizing indirect branches in dynamic binary translators 40 3.1 Hardware-assisted function returns . 43 3.1.1 Software return address stack . 44 3.1.2 Hardware return address prediction . 45 3.1.3 Return address stack elision . 46 3.1.4 Overflow and underflow handling . 50 3.1.5 Misprediction handling . 51 3.1.6 Unlinking . 54 3.2 Branch table inference . 55 3.2.1 Detecting branch tables . 56 3.2.2 Translating branch tables . 58 3.3 Fast atomic hash tables . 60 3.3.1 Hash table operations . 60 3.3.2 SPC and TPC packing . 64 3.4 Evaluation . 65 3.4.1 Experimental setup . 65 3.4.2 MAMBO-X64 . 67 3.4.3 Hardware-assisted function returns . 68 3.4.4 Branch table inference . 72 3.4.5 Fast atomic hash tables . 72 3.5 Related work . 76 3.5.1 Indirect branch handling . 76 3.5.2 Function return handling .
    [Show full text]