DOCSLIB.ORG

Proceedings of the Linux Symposium Volume

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Proceedings of the Linux Symposium Volume Proceedings of the Linux Symposium Volume One July 19th–22nd, 2006 Ottawa, Ontario Canada Contents Enabling Docking Station Support for the Linux Kernel 9 Kristen Carlson Accardi Open Source Graphic Drivers—They Don’t Kill Kittens 19 David M. Airlie kboot—A Boot Loader Based on Kexec 27 Werner Almesberger Ideas on improving Linux infrastructure for performance on multi-core platforms 39 Maxim Alt A Reliable and Portable Multimedia File System 57 J.-Y. Hwang, J.-K. Bae, A. Kirnasov, M.-S. Jang, & H.-Y. Kim Utilizing IOMMUs for Virtualization in Linux and Xen 71 M. Ben-Yehuda, J. Mason, J. Xenidis, O. Krieger, L. Van Doorn, J. Nakajima, A. Mallick, & E. Wahlig Towards a Highly Adaptable Filesystem Framework for Linux 87 S. Bhattacharya & D. Da Silva Multiple Instances of the Global Linux Namespaces 101 Eric W. Biederman Fully Automated Testing of the Linux Kernel 113 M. Bligh & A.P. Whitcroft Linux Laptop Battery Life 127 L. Brown, K.A. Karasyov, V.P. Lebedev, R.P. Stanley, & A.Y. Starikovskiy The Frysk Execution Analysis Architecture 147 Andrew Cagney Evaluating Linux Kernel Crash Dumping Mechanisms 153 Fernando Luis Vázquez Cao Exploring High Bandwidth Filesystems on Large Systems 177 Dave Chinner & Jeremy Higdon The Effects of Filesystem Fragmentation 193 Giel de Nijs, Ard Biesheuvel, Ad Denissen, Niek Lambert The LTTng tracer: A low impact performance and behavior monitor for GNU/Linux 209 M. Desnoyers & M.R. Dagenais Linux as a Hypervisor 225 Jeff Dike System Firmware Updates Utilizing Sofware Repositories 235 Matt Domsch & Michael Brown The Need for Asynchronous, Zero-Copy Network I/O 247 Ulrich Drepper Problem Solving With Systemtap 261 Frank Ch. Eigler Perfmon2: a flexible performance monitoring interface for Linux 269 Stéphane Eranian OCFS2: The Oracle Clustered File System, Version 2 289 Mark Fasheh tgt: Framework for Storage Target Drivers 303 Tomonori Fujita & Mike Christie More Linux for Less 313 Michael Hennerich & Robin Getz Hrtimers and Beyond: Transforming the Linux Time Subsystems 333 Thomas Gleixner and Douglas Niehaus Making Applications Mobile Under Linux 347 C. Le Goater, D. Lezcano, C. Calmels, D. Hansen, S.E. Hallyn, & H. Franke The What, The Why and the Where To of Anti-Fragmentation 369 Mel Gorman and Andy Whitcroft GIT—A Stupid Content Tracker 385 Junio C. Hamano Reducing fsck time for ext2 file systems 395 V. Henson, Z. Brown, T. T’so, & A. van de Ven Native POSIX Threads Library (NPTL) Support for uClibc. 409 Steven J. Hill Playing BlueZ on the D-Bus 421 Marcel Holtmann FS-Cache: A Network Filesystem Caching Facility 427 David Howells Why Userspace Sucks—Or 101 Really Dumb Things Your App Shouldn’t Do 441 Dave Jones Conference Organizers Andrew J. Hutton, Steamballoon, Inc. C. Craig Ross, Linux Symposium Review Committee Jeff Garzik, Red Hat Software Gerrit Huizenga, IBM Dave Jones, Red Hat Software Ben LaHaise, Intel Corporation Matt Mackall, Selenic Consulting Patrick Mochel, Intel Corporation C. Craig Ross, Linux Symposium Andrew Hutton, Steamballoon, Inc. Proceedings Formatting Team John W. Lockhart, Red Hat, Inc. David M. Fellows, Fellows and Carr, Inc. Kyle McMartin Authors retain copyright to all submitted papers, but have granted unlimited redistribution rights to all as a condition of submission. Enabling Docking Station Support for the Linux Kernel Is Harder Than You Would Think Kristen Carlson Accardi Open Source Technology Center, Intel Corporation [email protected] Abstract and lighter, more vendors are seeking to replace functionality that used to be built into the lap- top with a docking station. Commonly, docking Full docking station support has been a feature stations will provide additional USB ports, PCI long absent from the Linux kernel—for good slots, and sometimes extra features like built in reason. From ACPI to PCI, full docking sta- media card readers or Ethernet ports. Most ven- tion support required modifications to multiple dors seem to be marketing them as space saving subsystems in the kernel, building on code that devices, and as an improved user experience for was designed for server hot-plug features rather mobile users who do not wish to manage a lot than laptops with docking stations. This paper of peripheral devices. will present an overview of the work we have done to implement docking station support in the kernel as well as a summary of the techni- We embarked on the docking station project for cal challenges faced along the way. a few reasons. Firstly, we knew there were a few members of the Linux community out there We will first define what it means to dock and who actually did use docking stations. These undock. Then, we will discuss a few varia- people would hopefully post to the hotplug PCI tions of docking station implementations, both mailing lists every once in a while, wondering from a hardware and firmware perspective. Fi- if some round of I/O Hotplug patches would en- nally, we will delve into the guts of the soft- able hot docking to work. Secondly, there was ware implementation in Linux—and show how a need to be able to implement a couple sce- adding docking station support is really harder narios that dock stations provide a convenient than you would think. test case for. Many dock stations are actually Peer-to-peer bridges with a set of buses and de- vices located behind the bridge. Hot add with 1 Introduction and Motivation devices with P2P bridges on them had always been hard for us to test correctly due to lack of devices. Also, the ACPI _EJD method is com- It’s no secret that people have not been clam- monly used in AML code for docking stations, oring for docking station support. Most peo- but this method can also be applied to any hot- ple do not consider docking stations essential, pluggable tree of devices. Finally, we felt that and indeed some feel they are completely un- with the expanding product offerings for dock necessary. However, as laptops become thinner stations, filling this feature gap would eventu- 10 • Enabling Docking Station Support for the Linux Kernel ally become important. Device (DOCK1) { Name(_ADR, . ) Method(_EJ0, 0) {. } Method(_DCK, 1) {. } 2 Docking Basics } There are three types of docking that are de- Figure 1: Example DSDT that defines a Dock fined. Device When the user places their system into the • Cold Docking/Undocking Laptop is docking station, the OS will be notified with an booted attached to the dock station. interrupt, and the platform will send a Device Laptop is powered off prior to removal Check notify. The notify will be sent to a no- from the dock station. This has always tify handler and then that handler is responsible been supported by Linux. The devices on for calling the _DCK control method with the the dock station are enumerated as if they proper arguments to engage the dock connec- are part of the laptop. tor. • Warm Docking/Undocking Laptop is _DCK as defined in the ACPI specification booted either docked or undocked. Sys- is shown in Figure 2. Assuming that _DCK tem is placed into a suspend state, and then returned successfully, the OS must now re- either docked or undocked. This may be enumerate all enumerable buses (PCI) and also supported by Linux, assuming that your all the other devices that may not be on enumer- laptop actually suspends. It depends really able buses that are on the dock. on whether a driver’s resume routine will rescan for new devices or not. Undocking is just like docking, only in reverse. When the user hits the release button on the • Hot Docking/Undocking Laptop is docking station, the OS is notified with an eject booted outside the dock station. Laptop is request. The notify handler must first execute then inserted into the dock station while _DCK(0) to release the docking connector, and completely powered and operating. This then should execute the _EJ0 method after re- has recently had limited support, but only moving all the devices that are on the docking with a platform specific ACPI driver. station from the OS. Hotplugging new devices on the dock station has never been supported. The _DCK method is not only responsible for engaging the dock connector, it seems to also be a convenient place for system manufacturers Docking is controlled by ACPI. ACPI defines to do device initialization. This is all imple- a dock as an object containing a method called mentation dependent. I have seen _DCK meth- _DCK. An example dock device definition is ods that do things such as programming a USB shown in Figure 1. host controller to detect the USB hub on the dock station, issuing resets for PCI devices, and _DCK is what ACPI calls a "control method". even attempting to modify PCI config space to Not only does it tell the OS that this ACPI ob- assign new bus numbers1 to the dock bridge. ject is a dock, it also is used to control the iso- lation logic on the dock connector. 1Highly unacceptable behavior 2006 Linux Symposium, Volume One • 11 This control method is located in the device object that represents the docking station (that is, the device object with all the _EJx control methods for the docking station). The presence of _DCK indicates to the OS that the device is really a docking station. _DCK also controls the isolation logic on the docking connector. This allows an OS to prepare for docking before the bus is activated and devices appear on the bus [1]. Arguments: Arg0 1 Dock (that is, remove isolation from connector) 0 Undock (isolate from connector) Return Code: 1 if successful, 0 if failed.
Load more

Recommended publications
  • Linux: Kernel Release Number, Part II
    Linux: Kernel Release Number, Part II Posted by jeremy on Friday, March 4, 2005 - 07:05 In the continued discussion on release numbering for the Linux kernel [story], Linux creator Linus Torvalds decided against trying to add meaning to the odd/even least significant number. Instead, the new plan is to go from the current 2.6.x numbering to a finer-grained 2.6.x.y. Linus will continue to maintain only the 2.6.x releases, and the -rc releases in between. Others will add trivial patches to create the 2.6.x.y releases. Linus cautions that the task of maintaining a 2.6.x.y tree is not going to be enjoyable: "I'll tell you what the problem is: I don't think you'll find anybody to do the parallell 'only trivial patches' tree. They'll go crazy in a couple of weeks. Why? Because it's a _damn_ hard problem. Where do you draw the line? What's an acceptable patch? And if you get it wrong, people will complain _very_ loudly, since by now you've 'promised' them a kernel that is better than the mainline. In other words: there's almost zero glory, there are no interesting problems, and there will absolutely be people who claim that you're a dick-head and worse, probably on a weekly basis." He went on to add, "that said, I think in theory it's a great idea. It might even be technically feasible if there was some hard technical criteria for each patch that gets accepted, so that you don't have the burn-out problem." His suggested criteria included limiting the patch to being 100 lines or less, and requiring that it fix an oops, a hang, or an exploitable security hole.
    [Show full text]
  • Open Source Software Notice
    OPEN SOURCE SOFTWARE NOTICE DCS Touch Display Software V2.00.XXX Schüco International KG Karolinenstraße 1-15 33609 Bielefeld OPEN SOURCE SOFTWARE NOTICE Seite 1 von 32 10000507685_02_EN OPEN SOURCE SOFTWARE NOTICE This document contains information about open source software for this product. The rights granted under open source software licenses are granted by the respective right holders. In the event of conflicts between SCHÜCO’S license conditions and the applicable open source licenses, the open source license conditions take precedence over SCHÜCO’S license conditions with regard to the respective open source software. You are allowed to modify SCHÜCO’S proprietary programs and to conduct reverse engineering for the purpose of debugging such modifications, to the extent such programs are linked to libraries licensed under the GNU Lesser General Public License. You are not allowed to distribute information resulting from such reverse engineering or to distribute the modified proprietary programs. The rightholders of the open source software require to refer to the following disclaimer, which shall apply with regard to those rightholders: Warranty Disclaimer THE OPEN SOURCE SOFTWARE IN THIS PRODUCT IS DISTRIBUTED ON AN "AS IS" BASIS AND IN THE HOPE THAT IT WILL BE USEFUL, BUT WITHOUT ANY WARRANTY OF ANY KIND, WITHOUT EVEN THE IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SEE THE APPLICABLE LICENSES FOR MORE DETAILS. OPEN SOURCE SOFTWARE NOTICE Seite 2 von 32 10000507685_02_EN Copyright Notices and License Texts (please see the source code for all details) Software: iptables Copyright notice: Copyright (C) 1989, 1991 Free Software Foundation, Inc. Copyright Google, Inc.
    [Show full text]
  • Hardware-Driven Evolution in Storage Software by Zev Weiss A
    Hardware-Driven Evolution in Storage Software by Zev Weiss A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Computer Sciences) at the UNIVERSITY OF WISCONSIN–MADISON 2018 Date of final oral examination: June 8, 2018 ii The dissertation is approved by the following members of the Final Oral Committee: Andrea C. Arpaci-Dusseau, Professor, Computer Sciences Remzi H. Arpaci-Dusseau, Professor, Computer Sciences Michael M. Swift, Professor, Computer Sciences Karthikeyan Sankaralingam, Professor, Computer Sciences Johannes Wallmann, Associate Professor, Mead Witter School of Music i © Copyright by Zev Weiss 2018 All Rights Reserved ii To my parents, for their endless support, and my cousin Charlie, one of the kindest people I’ve ever known. iii Acknowledgments I have taken what might be politely called a “scenic route” of sorts through grad school. While Ph.D. students more focused on a rapid graduation turnaround time might find this regrettable, I am glad to have done so, in part because it has afforded me the opportunities to meet and work with so many excellent people along the way. I owe debts of gratitude to a large cast of characters: To my advisors, Andrea and Remzi Arpaci-Dusseau. It is one of the most common pieces of wisdom imparted on incoming grad students that one’s relationship with one’s advisor (or advisors) is perhaps the single most important factor in whether these years of your life will be pleasant or unpleasant, and I feel exceptionally fortunate to have ended up iv with the advisors that I’ve had.
    [Show full text]
  • Linuxové Noviny
    03–04/99Linuxove´noviny U´ vodem Mı´t svuj˚ vlastnı´sen... ehm, firewall Pavel Janı´k ml., 10. dubna 1998 Jisteˇ jste se dostali nebo tˇreba dostanete do situace, kdy Dva mesı´ceˇ ubehlyˇ jako voda a opetˇ je tu dalsˇı´ cı´sloˇ Linuxo- va´s nekdoˇ vyzve, abyste vyrobili z Linuxu zabezpeceny´po-ˇ vy´ch novin, ktere´va´m pˇrina´sˇejı´ty nejzajı´mavejsˇı´informaceˇ cı´taˇ cˇ — firewall. Na´stroje i podpora pˇrı´mo v kernelu na to ze svetaˇ Linuxu a vubec˚ denı´kolemˇ nej.ˇ To vsˇenezanese- existujı´, ale nejvetsˇı´proble´mˇ je s definova´nı´m vsˇechpo- ne´komercnı´miˇ dezinformacemi a novina´ˇrsky´m hyenismem tˇrebny´ch pra´v pro vstup/vy´stup do vnitˇrnı´sı´te,ˇ ktera´je po- (© DusˇanKory´tko:-) — pouhe´ ciste´informace.ˇ tˇreba hlı´dat. Pro ˇresˇenı´tohoto u´kolu ma´te nynı´pomocnı´- Co va´m tedy pˇrina´sˇı´toto cı´slo?ˇ Pˇredevsˇı´m je nutno kon- ka, skript jme´nem Mason (1), ktery´doka´zˇe ˇresˇitvsˇepo- statovat, zˇe je zameˇˇreno na prakticke´ota´zky dnesˇnı´ho li- tˇrebne´. Skript vyuzˇı´va´logu˚ od programu˚ ipchains a ip- nuxove´ho zˇivota, tedy na programova´nı´webovy´ch aplikacı´, fwadm, sleduje provoz na sı´ti, ma´podporu pro PPP spojenı´ bezpecnost,ˇ framebuffer a dalsˇı´. Ale postupne:ˇ a spoustu dalsˇı´ch uzˇitecny´chˇ vlastnostı´. S jeho pomocı´lze Jako v kazˇde´m cı´sleˇ na´m Radek Vybı´ral pˇredstavı´nej- snadno sestavit potˇrebna´pravidla pro provoz firewallu. novejsˇı´programyˇ pro Linux v rubrice Cerstve´masoˇ pro Li- nux.
    [Show full text]
  • Building Embedded Linux Systems ,Roadmap.18084 Page Ii Wednesday, August 6, 2008 9:05 AM
    Building Embedded Linux Systems ,roadmap.18084 Page ii Wednesday, August 6, 2008 9:05 AM Other Linux resources from O’Reilly Related titles Designing Embedded Programming Embedded Hardware Systems Linux Device Drivers Running Linux Linux in a Nutshell Understanding the Linux Linux Network Adminis- Kernel trator’s Guide Linux Books linux.oreilly.com is a complete catalog of O’Reilly’s books on Resource Center Linux and Unix and related technologies, including sample chapters and code examples. ONLamp.com is the premier site for the open source web plat- form: Linux, Apache, MySQL, and either Perl, Python, or PHP. Conferences O’Reilly brings diverse innovators together to nurture the ideas that spark revolutionary industries. We specialize in document- ing the latest tools and systems, translating the innovator’s knowledge into useful skills for those in the trenches. Visit con- ferences.oreilly.com for our upcoming events. Safari Bookshelf (safari.oreilly.com) is the premier online refer- ence library for programmers and IT professionals. Conduct searches across more than 1,000 books. Subscribers can zero in on answers to time-critical questions in a matter of seconds. Read the books on your Bookshelf from cover to cover or sim- ply flip to the page you need. Try it today for free. main.title Page iii Monday, May 19, 2008 11:21 AM SECOND EDITION Building Embedded Linux SystemsTomcat ™ The Definitive Guide Karim Yaghmour, JonJason Masters, Brittain Gilad and Ben-Yossef, Ian F. Darwin and Philippe Gerum Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo Building Embedded Linux Systems, Second Edition by Karim Yaghmour, Jon Masters, Gilad Ben-Yossef, and Philippe Gerum Copyright © 2008 Karim Yaghmour and Jon Masters.
    [Show full text]
  • Proceedings of the Linux Symposium Volume
    Proceedings of the Linux Symposium Volume Two July 19th–22nd, 2006 Ottawa, Ontario Canada Contents Evolution in Kernel Debugging using Hardware Virtualization With Xen 1 Nitin A. Kamble Improving Linux Startup Time Using Software Resume (and other techniques) 17 Hiroki Kaminaga Automated Regression Hunting 27 A. Bowen, P. Fox, J. Kenefick, A. Romney, J. Ruesch, J. Wilde, & J. Wilson Hacking the Linux Automounter—Current Limitations and Future Directions 37 Ian Maxwell Kent & Jeff Moyer Why NFS Sucks 51 Olaf Kirch Efficient Use of the Page Cache with 64 KB Pages 65 Dave Kleikamp and Badari Pulavarty Startup Time in the 21st Century: Filesystem Hacks and Assorted Tweaks 71 Benjamin C.R. LaHaise Using Hugetlbfs for Mapping Application Text Regions 75 H.J. Lu, K. Doshi, R. Seth, & J. Tran Towards a Better SCM: Revlog and Mercurial 83 Matt Mackall Roadmap to a GL-based composited desktop for Linux 91 K.E. Martin and K. Packard Probing the Guts of Kprobes 101 A. Mavinakayanahalli, P. Panchamukhi, J. Keniston, A. Keshavamurthy, & M. Hiramatsu Shared Page Tables Redux 117 Dave McCracken Extending RCU for Realtime and Embedded Workloads 123 Paul E. McKenney OSTRA: Experiments With on-the-fly Source Patching 139 Arnaldo Carvalho de Melo Design and Implementation to Support Multiple Key Exchange Protocols for IPsec 143 K. Miyazawa, S. Sakane, K. Kamada, M. Kanda, & A. Fukumoto The State of Linux Power Management 2006 151 Patrick Mochel I/O Workload Fingerprinting in the Genetic-Library 165 Jake Moilanen X86-64 XenLinux: Architecture, Implementation, and Optimizations 173 Jun Nakajima, Asit Mallick GCC—An Architectural Overview, Current Status, and Future Directions 185 Diego Novillo Shared-Subtree Concept, Implementation, and Applications in Linux 201 Al Viro & Ram Pai The Ondemand Governor 215 Venkatesh Pallipadi & Alexey Starikovskiy Linux Bootup Time Reduction for Digital Still Camera 231 Chan-Ju Park A Lockless Pagecache in Linux—Introduction, Progress, Performance 241 Nick Piggin The Ongoing Evolution of Xen 255 I.
    [Show full text]
  • The GNU General Public License (GPL) Does Govern All Other Use of the Material That Constitutes the Autoconf Macro
    Notice About this document The following copyright statements and licenses apply to software components that are distributed with various versions of the StorageGRID PreGRID Environment products. Your product does not necessarily use all the software components referred to below. Where required, source code is published at the following location: ftp://ftp.netapp.com/frm-ntap/opensource/ 215-10078_A0_ur001-Copyright 2015 NetApp, Inc. All rights reserved. 1 Notice Copyrights and licenses The following component is subject to the BSD 1.0 • Free BSD - 44_lite BSD 1.0 Copyright (c) 1982, 1986, 1990, 1991, 1993 The Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. • All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. • Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
    [Show full text]
  • View Article(3467)
    Problems of information technology, 2018, №1, 92–97 Kamran E. Jafarzade DOI: 10.25045/jpit.v09.i1.10 Institute of Information Technology of ANAS, Baku, Azerbaijan [email protected] COMPARATIVE ANALYSIS OF THE SOFTWARE USED IN SUPERCOMPUTER TECHNOLOGIES The article considers the classification of the types of supercomputer architectures, such as MPP, SMP and cluster, including software and application programming interfaces: MPI and PVM. It also offers a comparative analysis of software in the study of the dynamics of the distribution of operating systems (OS) for the last year of use in supercomputer technologies. In addition, the effectiveness of the use of CentOS software on the scientific network "AzScienceNet" is analyzed. Keywords: supercomputer, operating system, software, cluster, SMP-architecture, MPP-architecture, MPI, PVM, CentOS. Introduction Supercomputer is a computer with high computing performance compared to a regular computer. Supercomputers are often used for scientific and engineering applications that need to process very large databases or perform a large number of calculations. The performance of a supercomputer is measured in floating-point operations per second (FLOPS) instead of millions of instructions per second (MIPS). Since 2015, the supercomputers performing up to quadrillion FLOPS have started to be developed. Modern supercomputers represent a large number of high performance server computers, which are interconnected via a local high-speed backbone to achieve the highest performance [1]. Supercomputers were originally introduced in the 1960s and bearing the name or monogram of the companies such as Seymour Cray of Control Data Corporation (CDC), Cray Research over the next decades. By the end of the 20th century, massively parallel supercomputers with tens of thousands of available processors started to be manufactured.
    [Show full text]
  • 855400Cd46b6c9e7683b5ace58a55234.Pdf
    Ars TeAchrsn iTceachnica UK Register Log in ▼ ▼ Ars Technica has arrived in Europe. Check it out! × Encryption options are great, but Apple's attitude on checksums is still funky. by Adam H. Leventhal - Jun 26, 2016 1:00pm UTC KEEPING ON TRUCKING INDEPENDENCE, WHAT INDEPENDENCE? Two hours or so of WWDC keynoting and Tim Cook didn't mention a new file system once? Andrew Cunningham This article was originally published on Adam Leventhal's blog in multiple parts. Programmer Andrew Nõmm: "I had to be made Apple announced a new file system that will make its way into all of its OS variants (macOS, tvOS, iOS, an example of as a warning to all IT people." watchOS) in the coming years. Media coverage to this point has been mostly breathless elongations of Apple's developer documentation. With a dearth of detail I decided to attend the presentation and Q&A with the APFS team at WWDC. Dominic Giampaolo and Eric Tamura, two members of the APFS team, gave an overview to a packed room; along with other members of the team, they patiently answered questions later in the day. With those data points and some first-hand usage I wanted to provide an overview and analysis both as a user of Apple-ecosystem products and as a long-time operating system and file system developer. The overview is divided into several sections. I'd encourage you to jump around to topics of interest or skip right to the conclusion (or to the tweet summary). Highest praise goes to encryption; ire to data integrity.
    [Show full text]
  • Distributed-Operating-Systems.Pdf
    Distributed Operating Systems Overview Ye Olde Operating Systems OpenMOSIX OpenSSI Kerrighed Quick Preview Front Back Distributed Operating Systems vs Grid Computing Grid System User Space US US US US US US Operating System OS OS OS OS OS OS Nodes Nodes Amoeba, Plan9, OpenMosix, Xgrid, SGE, Condor, Distcc, OpenSSI, Kerrighed. Boinc, GpuGrid. Distributed Operating Systems vs Grid Computing Problems with the grid. Programs must utilize that library system. Usually requiring seperate programming. OS updates take place N times. Problems with dist OS Security issues – no SSL. Considered more complicated to setup. Important Note Each node, even with distributed operating systems, boots a kernel. This kernel can vary depending on the role of the node and overall architecture of the system. User Space Operating System OS OS OS OS OS OS Nodes Amoeba Andrew S. Tanenbaum Earliest documentation: 1986 What modern language was originally developed for use in Amoeba? Anyone heard of Orca? Sun4c, Sun4m, 386/486, 68030, Sun 3/50, Sun 3/60. Amoeba Plan9 Started development in the 1980's Released in 1992 (universities) and 1995 (general public). All devices are part of the filesystem. X86, MIPS, DEC Alpha, SPARC, PowerPC, ARM. Union Directories, basis of UnionFS. /proc first implemente d here. Plan9 Rio , the Plan9 window manager showing ”faces(1), stats(8), acme(1) ” and many more things. Plan9 Split nodes into 3 distinct groupings. Terminals File servers Computational servers Uses the ”9P” protocol. Low level, byte protocol, not block. Used from filesystems, to printer communication. Author: Ken Thompso n Plan9 / Amoeba Both Plan9 and Amoeba make User Space groupings of nodes, into specific categories.
    [Show full text]
  • Proceedings of the Linux Symposium
    Reprinted from the Proceedings of the Linux Symposium July 23rd–26th, 2008 Ottawa, Ontario Canada Conference Organizers Andrew J. Hutton, Steamballoon, Inc., Linux Symposium, Thin Lines Mountaineering C. Craig Ross, Linux Symposium Review Committee Andrew J. Hutton, Steamballoon, Inc., Linux Symposium, Thin Lines Mountaineering Dirk Hohndel, Intel Gerrit Huizenga, IBM Dave Jones, Red Hat, Inc. Matthew Wilson, rPath C. Craig Ross, Linux Symposium Proceedings Formatting Team John W. Lockhart, Red Hat, Inc. Gurhan Ozen, Red Hat, Inc. Eugene Teo, Red Hat, Inc. Kyle McMartin, Red Hat, Inc. Jake Edge, LWN.net Robyn Bergeron Dave Boutcher, IBM Mats Wichmann, Intel Authors retain copyright to all submitted papers, but have granted unlimited redistribution rights to all as a condition of submission. SELinux for Consumer Electronics Devices Yuichi Nakamura Yoshiki Sameshima Hitachi Software Engineering Hitachi Software Engineering [email protected] [email protected] Abstract without security updates, because the process of updating introduces several problems. Some CE As the number of network-connect Consumer Electron- devices do not have a network updater. To fix vul- ics (CE) devices has increased, the security of these de- nerabilities for such devices, manufacturers have to vices has become important. SELinux is widely used recall devices, and re-write flash ROM. Even if de- for PC servers to prevent attacks from a network. How- vices do have a network updater, security patches ever, there are problems in applying SELinux to CE de- tend to be delayed or not provided, because prepar- vices. SELinux kernel, userland, and policy consume ing updates is a heavy task for manufacturers. Up- hardware resources unacceptably.
    [Show full text]
  • Linux Kernel User Documentation V4.20.0
    usepackagefontspec setsansfontDejaVu Sans setromanfontDejaVu Serif setmonofontDejaVu Sans Mono Linux Kernel User Documentation v4.20.0 The kernel development community 1 16, 2019 Contents 1 Linux kernel release 4.x <http://kernel.org/> 3 2 The kernel’s command-line parameters 9 3 Linux allocated devices (4.x+ version) 109 4 L1TF - L1 Terminal Fault 171 5 Reporting bugs 181 6 Security bugs 185 7 Bug hunting 187 8 Bisecting a bug 193 9 Tainted kernels 195 10 Ramoops oops/panic logger 197 11 Dynamic debug 201 12 Explaining the dreaded “No init found.” boot hang message 207 13 Rules on how to access information in sysfs 209 14 Using the initial RAM disk (initrd) 213 15 Control Group v2 219 16 Linux Serial Console 245 17 Linux Braille Console 247 18 Parport 249 19 RAID arrays 253 20 Kernel module signing facility 263 21 Linux Magic System Request Key Hacks 267 i 22 Unicode support 273 23 Software cursor for VGA 277 24 Kernel Support for miscellaneous (your favourite) Binary Formats v1.1 279 25 Mono(tm) Binary Kernel Support for Linux 283 26 Java(tm) Binary Kernel Support for Linux v1.03 285 27 Reliability, Availability and Serviceability 293 28 A block layer cache (bcache) 309 29 ext4 General Information 319 30 Power Management 327 31 Thunderbolt 349 32 Linux Security Module Usage 353 33 Memory Management 369 ii Linux Kernel User Documentation, v4.20.0 The following is a collection of user-oriented documents that have been added to the kernel over time. There is, as yet, little overall order or organization here — this material was not written to be a single, coherent document! With luck things will improve quickly over time.
    [Show full text]