DOCSLIB.ORG

Autotest Documentation Release 0.16.3-44-G0d527f

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Autotest Documentation Release 0.16.3-44-G0d527f autotest Documentation Release 0.16.3-44-g0d527f Autotest Team May 31, 2018 Contents 1 Autotest Documentation 3 1.1 General Information...........................................3 1.2 Local (Former Client).......................................... 20 1.3 Remote (Former Server)......................................... 41 1.4 Frontend................................................. 70 1.5 System Administration.......................................... 125 1.6 Scheduler................................................. 146 1.7 Developer................................................. 154 2 client Package 195 2.1 autotest_local Module...................................... 195 2.2 base_sysinfo Module........................................ 195 2.3 base_utils Module.......................................... 196 2.4 bkr_proxy Module.......................................... 200 2.5 bkr_xml Module............................................ 202 2.6 client_logging_config Module................................. 203 2.7 cmdparser Module.......................................... 203 2.8 common Module............................................. 204 2.9 config Module............................................. 204 2.10 cpuset Module............................................. 204 2.11 fsdev_disks Module......................................... 206 2.12 fsdev_mgr Module.......................................... 208 2.13 fsinfo Module............................................. 208 2.14 harness Module............................................ 209 2.15 harness_autoserv Module..................................... 210 2.16 harness_beaker Module...................................... 210 2.17 harness_simple Module...................................... 212 2.18 harness_standalone Module................................... 212 2.19 job Module............................................... 212 2.20 kernel Module............................................. 216 2.21 kernel_config Module....................................... 218 2.22 kernel_versions Module...................................... 219 2.23 kernelexpand Module........................................ 219 2.24 kvm_control Module......................................... 220 2.25 local_host Module.......................................... 220 2.26 lv_utils Module........................................... 221 i 2.27 optparser Module.......................................... 222 2.28 os_dep Module............................................. 222 2.29 parallel Module........................................... 225 2.30 partition Module.......................................... 226 2.31 profiler Module........................................... 230 2.32 setup Module.............................................. 230 2.33 setup_job Module.......................................... 230 2.34 setup_modules Module....................................... 231 2.35 sysinfo Module............................................ 232 2.36 test Module.............................................. 232 2.37 test_config Module......................................... 232 2.38 utils Module.............................................. 233 2.39 xen Module............................................... 233 2.40 Subpackages............................................... 234 3 frontend Package 369 3.1 Subpackages............................................... 369 4 Indices and tables 371 Python Module Index 373 ii autotest Documentation, Release 0.16.3-44-g0d527f Autotest is a framework for fully automated testing. It is designed primarily to test the Linux kernel, though it is useful for many other purposes such as qualifying new hardware, virtualization testing and other general user space program testing under linux platforms. It’s an open-source project under the GPL and is used and developed by a number of organizations, including Google, IBM, Red Hat, and many others. Please check Avocado, a next generation test automation framework being developed by several of the original Autotest team members: http://avocado-framework.github.io/ Contents 1 autotest Documentation, Release 0.16.3-44-g0d527f 2 Contents CHAPTER 1 Autotest Documentation 1.1 General Information 1.1.1 Contact information • Autotest mailing list • Autotest IRC channel: irc.oftc.net #autotest 1.1.2 Who uses autotest? An active community of users is fundamental to sustain an open source project. Currently, there are quite a few projects that use autotest as their main test automation platform: • Fedora’s AutoQA • Chrome OS • KVM kernel based virtual machine • Goobuntu (internal customized version of ubuntu for google) Besides these projects, other people from several different companies/affiliations use autotest for their test automation needs. 1.1.3 Autotest structure overview This document intends to be a high level overview of the autotest project structure. We try to be brief and show the high level diagrams. Simplified block diagram For the sake of clarity, some things are simplified here, but it gives you a good idea of the overall layout. 3 autotest Documentation, Release 0.16.3-44-g0d527f Web interface and command line interface The web interface and the command line interface are complementary ways to interact with autotest and create jobs. Both were designed to have the same functionality, to add to the user’s convenience. The interfaces allows you to: • Manage jobs? - create, monitor, abort, etc. • Manage client hosts • Look at results. The frontends will inject jobs into the server by creating records in a mysql database. Server The server consists of three main parts: • A mysql database that holds information on all jobs, clients (test machines), users and tests. • The dispatcher (monitor_db) - chooses the jobs from the database to run. It’s input is the database, pretty much all it does is start autoserv processes to service requests. – There is normally one dispatcher process per machine – Client side jobs are run asyncronously (as client machines become available) – Server side jobs are run syncronously (ie we wait for all clients before commencing) • Autoserv: the server manages clients via autoserv processes - there will be one autoserv process per running job?. Each autoserv process: – controls and monitors one or more clients – verifies clients are working properly, and if it fails verification, attempts to repair it – manages the execution of a job? – updates the autotest software on each client before commencing work. 4 Chapter 1. Autotest Documentation autotest Documentation, Release 0.16.3-44-g0d527f The mysql database can live on a different machine than the dispatcher. There can be multiple dispatchers to spread the workload, though each can service a few thousand clients, so this is not normally necessary. Client The client does most of the work of running a job?; this can be invoked: • manually - from client/autotest-local <control_file_name> • via the server A typical job workflow is as follows: Results repository A directory tree of all the results. Each job has a well formatted directory structure Results MySQL DB A simple mysql database containing the jobs, test results, and performance metrics for each test 1.1. General Information 5 autotest Documentation, Release 0.16.3-44-g0d527f Overall structure With all the parts of the code briefly commented, it’s easier to understand the overall structure diagram: 1.1.4 Autotest White Paper Abstract This paper describes the motivation for, and design goals of, the autotest and test.kernel.org projects. Autotest is a framework for fully automated testing, that is designed primarily to test the Linux kernel, though is useful for many other functions too. Test.kernel.org is a framework for communicating, sharing, and analysing test results. In a traditional corporate systems software development environment, there is normally a large test team responsible for assuring the quality of the final product. Open source projects do not have that luxury, and we need to find another way to run testing. We feel that the only realistic way to achieve the goal is to fully automate the test process, and drastically reduce the need for human staffing. It turns out that this also solves several other critical problems with testing. • Consistency - it’s much easier to guarantee the tests are run the same way as last time. • Knowledge capture - the knowledge of how to run testing is not held in one person, but within a system. • Sharing - you can easily share tests with vendors, partners, and across a wide community. • Reproducibility - they say 90% of fixing a bug is to get an easily reproducible test case. Testing is not about running tests . testing is about finding and fixing bugs. We have to: • Run the tests • Find a bug • Classify the bug 6 Chapter 1. Autotest Documentation autotest Documentation, Release 0.16.3-44-g0d527f • Hand the bugs off to a developer • Developer investigates bug (cyclical) • Developer tests some proposed fix (cyclical) • Fix checked in • New release issued to test team. So many test systems I see are oriented only around the first two (or even one!) steps. This is massively inefficient - so often I see developers writing a simple testcase to reproduce what happens in a more complex test, or proprietary application, and then these are thrown away. If we started with open tests that we could freely and easily share, much effort and time would be saved. This is not just about the cost of the people’s time, salaries and machine resources. It’s about the opportunity cost of stalling
Load more

Recommended publications
  • Redhawk Linux User's Guide
    Linux® User’s Guide 0898004-520 May 2007 Copyright 2007 by Concurrent Computer Corporation. All rights reserved. This publication or any part thereof is intended for use with Concurrent products by Concurrent personnel, customers, and end–users. It may not be reproduced in any form without the written permission of the publisher. The information contained in this document is believed to be correct at the time of publication. It is subject to change without notice. Concurrent makes no warranties, expressed or implied, concerning the information contained in this document. To report an error or comment on a specific portion of the manual, photocopy the page in question and mark the correction or comment on the copy. Mail the copy (and any additional comments) to Concurrent Computer Corporation, 2881 Gateway Drive, Pompano Beach, Florida, 33069. Mark the envelope “Attention: Publications Department.” This publication may not be reproduced for any other reason in any form without written permission of the publisher. Concurrent Computer Corporation and its logo are registered trademarks of Concurrent Computer Corporation. All other Concurrent product names are trademarks of Concurrent while all other product names are trademarks or registered trademarks of their respective owners. Linux® is used pursuant to a sublicense from the Linux Mark Institute. Printed in U. S. A. Revision History: Date Level Effective With August 2002 000 RedHawk Linux Release 1.1 September 2002 100 RedHawk Linux Release 1.1 December 2002 200 RedHawk Linux Release 1.2 April 2003 300 RedHawk Linux Release 1.3, 1.4 December 2003 400 RedHawk Linux Release 2.0 March 2004 410 RedHawk Linux Release 2.1 July 2004 420 RedHawk Linux Release 2.2 May 2005 430 RedHawk Linux Release 2.3 March 2006 500 RedHawk Linux Release 4.1 May 2006 510 RedHawk Linux Release 4.1 May 2007 520 RedHawk Linux Release 4.2 Preface Scope of Manual This manual consists of three parts.
    [Show full text]
  • Projects on the Move
    Free Software Projects COMMUNITY An up-to-date look at free software and its makers PROJECTS ON THE MOVE Although a couple of scratches are visible, you can read from the backup CD. The question is, for how long? Cdck measures the sector access times to give you an idea. Have you overwritten the bootloader on your disk? Super Grub Disk to the rescue! BY PETER KREUSSEL AND MARTIN LOSCHWITZ Ds and DVDs use optical struc- If you have a big collection of CDs, Depending on the quantity of data de- tures of approximately 100 nano- like the program’s author, Alexey Seme- stroyed by the scratch, the drive has to Cmeters to store data. Even tiny noff, and do not want to create backups read farther ahead to reconstruct the scratches can destroy large numbers of of all your CDs and DVDs but still want data. It takes longer to retrieve the data data bits, without the user even noticing to avoid losing critical data, you need a for a block, even in the case of modern at first. Data redundancy and error-cor- tool that can check the state of your drives with cache memory. Semenoff’s recting techniques, such as cross-inter- disks for you. statistical observations provide empirical leaved Reed-Solomon code, support Semenoff’s program, cdck [1], does a evidence that read errors typically occur error-free data reading, despite damage low-level read of the media and mea- in sectors for which access times were to parts of the disk. Even newly burned sures how long it takes to get the data, high in previous measurements.
    [Show full text]
  • Kshot: Live Kernel Patching with SMM and SGX
    KShot: Live Kernel Patching with SMM and SGX Lei Zhou∗y, Fengwei Zhang∗, Jinghui Liaoz, Zhengyu Ning∗, Jidong Xiaox Kevin Leach{, Westley Weimer{ and Guojun Wangk ∗Department of Computer Science and Engineering, Southern University of Science and Technology, Shenzhen, China, zhoul2019,zhangfw,ningzy2019 @sustech.edu.cn f g ySchool of Computer Science and Engineering, Central South University, Changsha, China zDepartment of Computer Science, Wayne State University, Detroit, USA, [email protected] xDepartment of Computer Science, Boise State University, Boise, USA, [email protected] Department of Computer Science and Engineering, University of Michigan, Ann Arbor, USA, kjleach,weimerw @umich.edu { f g kSchool of Computer Science and Cyber Engineering, Guangzhou University, Guangzhou, China, [email protected] Abstract—Live kernel patching is an increasingly common kernel vulnerabilities also merit patching. Organizations often trend in operating system distributions, enabling dynamic up- use rolling upgrades [3], [6], in which patches are designed dates to include new features or to fix vulnerabilities without to affect small subsystems that minimize unplanned whole- having to reboot the system. Patching the kernel at runtime lowers downtime and reduces the loss of useful state from running system downtime, to update and patch whole server systems. applications. However, existing kernel live patching techniques However, rolling upgrades do not altogether obviate the need (1) rely on specific support from the target operating system, to restart software or reboot systems; instead, dynamic hot and (2) admit patch failures resulting from kernel faults. We patching (live patching) approaches [7]–[9] aim to apply present KSHOT, a kernel live patching mechanism based on patches to running software without having to restart it.
    [Show full text]
  • Red Hat Enterprise Linux 7 Kernel Administration Guide
    Red Hat Enterprise Linux 7 Kernel Administration Guide Examples of Tasks for Managing the Kernel Last Updated: 2018-05-21 Red Hat Enterprise Linux 7 Kernel Administration Guide Examples of Tasks for Managing the Kernel Marie Dolezelova Red Hat Customer Content Services [email protected] Mark Flitter Red Hat Customer Content Services Douglas Silas Red Hat Customer Content Services Eliska Slobodova Red Hat Customer Content Services Jaromir Hradilek Red Hat Customer Content Services Maxim Svistunov Red Hat Customer Content Services Robert Krátký Red Hat Customer Content Services Stephen Wadeley Red Hat Customer Content Services Florian Nadge Red Hat Customer Content Services Legal Notice Copyright © 2018 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates.
    [Show full text]
  • Open Source Used in Cisco Virtual Topology System 2.1
    Open Source Used In Cisco Virtual Topology System 2.1 Cisco Systems, Inc. www.cisco.com Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco website at www.cisco.com/go/offices. Text Part Number: 78EE117C99-112340008 Open Source Used In Cisco Virtual Topology System 2.1 1 This document contains licenses and notices for open source software used in this product. With respect to the free/open source software listed in this document, if you have any questions or wish to receive a copy of any source code to which you may be entitled under the applicable free/open source license(s) (such as the GNU Lesser/General Public License), please contact us at [email protected]. In your requests please include the following reference number 78EE117C99-112340008 The product also uses the Linux operating system, Ubuntu 14.04.2 (Server Version) BUNDLE. CLONE for VTS1.5 1.0. Information on this distribution is available at http://software.cisco.com/download/release.html?i=!y&mdfid=286285090&softwareid=286 283930&release=1.5&os=. The full source code for this distribution, including copyright and license information, is available on request from opensource- [email protected]. Mention that you would like the Linux distribution source archive, and quote the following reference number for this distribution: 92795016- 112340008. The product also uses the Linux operating system, Ubuntu 14.04.3 Server 14.04.3. Information on this distribution is available at http://releases.ubuntu.com/14.04.3/. The full source code for this distribution, including copyright and license information, is available on request from [email protected].
    [Show full text]
  • Red Hat Enterprise Linux 8 Managing, Monitoring and Updating the Kernel
    Red Hat Enterprise Linux 8 Managing, monitoring and updating the kernel A guide to managing the Linux kernel on Red Hat Enterprise Linux 8 Last Updated: 2019-11-05 Red Hat Enterprise Linux 8 Managing, monitoring and updating the kernel A guide to managing the Linux kernel on Red Hat Enterprise Linux 8 Legal Notice Copyright © 2019 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
    [Show full text]
  • Fedora 7 Release Notes
    Fedora 7 Release Notes Fedora Documentation Project Copyright © 2007 Red Hat, Inc. and Others. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. For guidelines on the permitted uses of the Fedora trademarks, refer to https:// fedoraproject.org/wiki/Legal:Trademark_guidelines. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. Java® is a registered trademark of Oracle and/or its affiliates. XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. All other trademarks are the property of their respective owners. Abstract 1. Welcome to Fedora ................................................................................................................ 3 2. Release Highlights .................................................................................................................. 4 2.1. Fedora Tour ................................................................................................................. 4 2.2.
    [Show full text]
  • Understanding the Linux Virtual Memory Manager
    1 Understanding The Linux Virtual Memory Manager Mel Gorman 15th February 2004 Contents List of Figures 5 List of Tables 7 Acknowledgements 9 1 Introduction 12 1.1 General Kernel Literature . 13 1.2 Thesis Overview . 14 1.3 Typographic Conventions . 14 1.4 About this Document . 14 1.5 Companion CD . 15 2 Code Management 17 2.1 Managing the Source . 17 2.2 Getting Started . 23 2.3 Submitting Work . 24 3 Describing Physical Memory 26 3.1 Nodes . 27 3.2 Zones . 29 3.3 Pages . 31 3.4 High Memory . 33 4 Page Table Management 36 4.1 Describing the Page Directory . 37 4.2 Describing a Page Table Entry . 38 4.3 Using Page Table Entries . 39 4.4 Translating and Setting Page Table Entries . 42 4.5 Allocating and Freeing Page Tables . 42 4.6 Kernel Page Tables . 43 4.7 Mapping addresses to struct pages .................. 44 5 Process Address Space 47 5.1 Linear Address Space . 48 5.2 Managing the Address Space . 49 2 CONTENTS 3 5.3 Process Address Space Descriptor . 50 5.4 Memory Regions . 55 5.5 Exception Handling . 70 5.6 Page Faulting . 71 5.7 Copying To/From Userspace . 77 6 Boot Memory Allocator 80 6.1 Representing the Boot Map . 81 6.2 Initialising the Boot Memory Allocator . 81 6.3 Allocating Memory . 83 6.4 Freeing Memory . 85 6.5 Retiring the Boot Memory Allocator . 85 7 Physical Page Allocation 90 7.1 Managing Free Blocks . 90 7.2 Allocating Pages . 91 7.3 Free Pages .
    [Show full text]
  • 1. Why POCS.Key
    Symptoms of Complexity Prof. George Candea School of Computer & Communication Sciences Building Bridges A RTlClES A COMPUTER SCIENCE PERSPECTIVE OF BRIDGE DESIGN What kinds of lessonsdoes a classical engineering discipline like bridge design have for an emerging engineering discipline like computer systems Observation design?Case-study editors Alfred Spector and David Gifford consider the • insight and experienceof bridge designer Gerard Fox to find out how strong the parallels are. • bridges are normally on-time, on-budget, and don’t fall ALFRED SPECTORand DAVID GIFFORD • software projects rarely ship on-time, are often over- AS Gerry, let’s begin with an overview of THE DESIGN PROCESS bridges. AS What is the procedure for designing and con- GF In the United States, most highway bridges are budget, and rarely work exactly as specified structing a bridge? mandated by a government agency. The great major- GF It breaks down into three phases: the prelimi- ity are small bridges (with spans of less than 150 nay design phase, the main design phase, and the feet) and are part of the public highway system. construction phase. For larger bridges, several alter- There are fewer large bridges, having spans of 600 native designs are usually considered during the Blueprints for bridges must be approved... feet or more, that carry roads over bodies of water, preliminary design phase, whereas simple calcula- • gorges, or other large obstacles. There are also a tions or experience usually suffices in determining small number of superlarge bridges with spans ap- the appropriate design for small bridges. There are a proaching a mile, like the Verrazzano Narrows lot more factors to take into account with a large Bridge in New Yor:k.
    [Show full text]
  • Open Source Software License Information
    Open Source Software license information This document contains an open source software license information for the product VACUU·SELECT. The product VACUU·SELECT contains open source components which are licensed under the applicable open source licenses. The applicable open source licenses are listed below. The open source software licenses are granted by the respective right holders directly. The open source licenses prevail all other license information with regard to the respective open source software components contained in the product. Modifications of our programs which are linked to LGPL libraries are permitted for the customer's own use and reverse engineering for debugging such modifications. However, forwarding the information acquired during reverse engineering or debugging to third parties is prohibited. Furthermore, it is prohibited to distribute modified versions of our programs. In any case, the warranty for the product VACUU·SELECT will expire, as long as the customer cannot prove that the defect would also occur without these modification. WARRANTY DISCLAIMER THE OPEN SOURCE SOFTWARE IN THIS PRODUCT IS DISTRIBUTED IN THE HOPE THAT IT WILL BE USEFUL, BUT WITHOUT ANY WARRANTY, WITHOUT EVEN THE IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. See the applicable licenses for more details. Written offer This product VACUU·SELECT contains software components that are licensed by the holder of the rights as free software, or Open Source software, under GNU General Public License, Versions 2 and 3, or GNU Lesser General Public License, Versions 2.1, or GNU Library General Public License, Version 2, respectively. The source code for these software components can be obtained from us on a data carrier (e.g.
    [Show full text]
  • Controlling Tracepoints AMD Performance Counting Clearer
    PROgRAMMIng Kernel News zack’s kernel news m68k Revitalized Under git Controlling Tracepoints nilfs2 Headed For Inclusion Geert Uytterhoeven announced a new git Steven Rostedt has posted a patch to Ryusuke Konishi has submitted nilfs2 for repository for the m68k Linux port, replac- ftrace, providing a simple interface for inclusion in the main kernel tree. Up to ing a defunct CVS repository. He also users to enable and disable any trace- now, it has lived in Andrew Morton’s posted a patch to add a make install com- point that already exists in the kernel. -mm tree. As Andrew has said, Konishi’s pilation target for the m68k build and The new /debug/tracing/available_ efforts have been quite impressive, and posted several other m68k updates as well. events file lists all tracepoints available he’s offered him some advice for further for tracking, whereas the /debug/tracing/ development. Andrew strongly supports MSI HOWTO Rewrite set_event can be modified to list the the filesystem and plans to send the Matthew Wilcox has rewritten the MSI events you want to enable or disable. patches along to Linus Torvalds in the HOWTO, the first major rewrite since very near future, barring serious objec- 2004. MSI (or Message Signaled Inter- AMD Performance Counting tion from other kernel hackers. nilfs2 rupts) provide PCI devices with an alter- Jaswinder Singh Rajput posted some provides full versioning within the file- native to traditional interrupts that re- patches to implement performance system, including continuous snapshot- quire the existence of a hardware pin on counting for AMD K7 (and later) proces- ting and access to older snapshots.
    [Show full text]
  • Status and Direction of Kernel Development Andrew Morton
    Status and Direction of Kernel Development Andrew Morton <[email protected]> <[email protected]> Linux Foundation Japan Linux Symposium 2008 July 2008 Page 1 of 18 Overview ● Process – The linux-next tree – Embedded development – X86 – Realtime ● Technology – Filesystems – Memory management – Hardware virtualisation (Xen/vmware/KVM) – OS virtualisation (containers) – RAS – AIO – Tracing Page 2 of 18 The “linux-next” tree ● A GIT tree operated by Stephen Rothwell – Merges together 104 subsystem development trees – This represents 85% of the changes in Linux. The remaining 15% is in the -mm tree. ● I will soon feed most of the -mm tree into linux-next so we get close to 100% Page 3 of 18 Why “linux-next” exists ● To reduce the amount of breakage which occurs during the 2.6.x-rc1 merge window. – because it gets additional testing ● To provide an integration tree in which the various subsystem changes can be tested together ● To help persuade subsystem developers to not make conflicting changes – I was seeing a lot of this happening. The prominence of linux-next makes people more careful about what they merge. ● To take the "subsystem tree integration" function out of my hands – I wasn't doing it very well and it was getting harder and harder Page 4 of 18 “linux-next” status ● It is going well - perhaps better than I had expected ● It still isn't receiving as much testing as I would like. ● There is some testing by "testers" but few if any "developers" appear to be testing linux-next. ● This is bad because individual developers are now testing their changes in the 2.6.x environment, but that code is destined to be integrated into 2.6.x+1.
    [Show full text]