Language Selection

English French German Italian Portuguese Spanish

Linux Plumbers Conference 2018 Coverage by LWN

Filed under
Linux
  • Bringing the Android kernel back to the mainline

    Android devices are based on the Linux kernel but, since the beginning, those devices have not run mainline kernels. The amount of out-of-tree code shipped on those devices has been seen as a problem for most of this time, and significant resources have been dedicated to reducing it. At the 2018 Linux Plumbers Conference, Sandeep Patil talked about this problem and what is being done to address it. The dream of running mainline kernels on Android devices has not yet been achieved, but it may be closer than many people think.

    Android kernels, he said, start their life as a long-term stable (LTS) release from the mainline; those releases are combined with core Android-specific code to make the Android Common Kernel releases. Vendors will pick a common kernel and add a bunch more out-of-tree code to create a kernel specific to a system-on-chip (SoC) and ship that to device manufacturers. Eventually one of those SoC kernels is frozen, perhaps with yet another pile of out-of-tree code tossed in, and used as the kernel for a specific device model. It now only takes a few weeks to merge an LTS release into the Android Common Kernel, but it's still a couple of years before that kernel shows up as a device kernel. That is why Android devices are always running ancient kernels.

  • A panel discussion on the kernel's code of conduct

    There has been a great deal of discussion around the kernel project's recently adopted code of conduct (CoC), but little of that has happened in an open setting. That changed to an extent when a panel discussion was held during the Kernel Summit track at the 2018 Linux Plumbers Conference. Panelists Mishi Choudhary, Olof Johansson, Greg Kroah-Hartman, and Chris Mason took on a number of issues surrounding the CoC in a generally calm and informative session.

    Kroah-Hartman began by apologizing for the process by which the code was adopted. Linus Torvalds wanted something quickly, Kroah-Hartman said, so the process was rushed and a lot of political capital was burned to get the code into the kernel. He has since been trying to make up for things by talking to a lot of people; while he apologized for how things happened, he also insisted that it was necessary to take that path. The "code of conflict" that preceded the current code was also pushed into the kernel over a period of about three weeks; "we have been here before", he said.

  • The kernel developer panel at LPC

    The closing event at the 2018 Linux Plumbers Conference (LPC) was a panel of kernel developers. The participants were Laura Abbott, Anna-Maria Gleixner, Shuah Khan, Julia Lawall, and Anna Schumaker; moderation was provided by Kate Stewart. This fast-moving discussion covered the challenges of kernel development, hardware vulnerabilities, scaling the kernel, and more.

    The initial topic was entry into kernel development, and the panelists' experience in particular. Khan, who got started around seven years ago, said that her early experience was quite positive; she named Tim Bird as a developer who gave her a lot of good advice at the beginning. Abbott started by tracking down a bug that was causing trouble internally; after getting some feedback, she was able to get that work merged into the mainline — an exciting event. Schumaker started with a relatively easy project at work. Lawall, instead, started by creating the Coccinelle project back around 2004. Her experience was initially somewhat painful, since the patches she was creating had to go through a lot of different maintainers.

    It had been a busy week at LPC, Stewart said, asking the panelists what stood out for them. Khan called out the networking track as a place where she learned a lot, but also said that the conference helped her to catch up with what is going on with the kernel as a whole, which is not an easy thing to do. She mentioned the sessions on the kernel's code of conduct and the creation of a maintainer's handbook.

  • Toward a kernel maintainer's guide

    "Who's on Team Xmas Tree?" asked Dan Williams at the beginning of his talk in the Kernel Summit track of the 2018 Linux Plumbers Conference. He was referring to a rule for the ordering of local variable declarations within functions that is enforced by a minority of kernel subsystem maintainers — one of many examples of "local customs" that can surprise developers when they submit patches to subsystems where they are not accustomed to working. Documenting these varying practices is a small part of Williams's project to create a kernel maintainer's manual, but it seems to be where the effort is likely to start.

    In theory, Williams said, kernel maintenance is a straightforward task. All it takes is accumulating patches and sending a pull request or two to Linus Torvalds during the merge window. In this ideal world, subsystems are the same and there is plenty of backup to provide continuity when a maintainer takes a vacation. In the real world, though, the merge window is a stressful time for maintainers. It involves a lot of work juggling topic branches, a lot of talking to people (which is an annoying distraction), and the fact that Torvalds can instinctively smell a patch that is not yet fully cooked. Maintenance practices vary between subsystems, and there is no backup for the maintainers in many of them. It is hard for a maintainer to take a break.

  • Updates on the KernelCI project

    The kernelci.org project develops and operates a distributed testing infrastructure for the kernel. It continuously builds, boots, and tests multiple kernel trees on various types of boards. Kevin Hilman and Gustavo Padovan led a session in the Testing & Fuzzing microconference at the 2018 Linux Plumbers Conference (LPC) to describe the project, its goals, and its future.

    KernelCI is a testing framework that is focused on actual hardware. Hilman is one of the developers of the project and he showed a picture of his shed where he has 80 different embedded boards all wired up as part of the framework. KernelCI came out of the embedded space and the Arm community; there are so many different hardware platforms, it became clear there was a need to ensure that the code being merged would actually work on all of them. Since then, it has expanded to more architectures.

  • Filesystems and case-insensitivity

    A recurring topic in filesystem-developer circles is on handling case-insensitive file names. Filesystems for other operating systems do so but, by and large, Linux filesystems do not. In the Kernel Summit track of the 2018 Linux Plumbers Conference (LPC), Gabriel Krisman Bertazi described his plans for making Linux filesystems encoding-aware as part of an effort to make ext4, and possibly other filesystems, interoperable with case-insensitivity in Android, Windows, and macOS.

    Case-insensitive file names for Linux have been discussed for a long time. The oldest reference he could find was from 2002, but it has come up at several Linux Storage, Filesystem, and Memory-Management Summits (LSFMM), including in 2016 and in Krisman's presentation this year. It has languished so long without a real solution because the problem has many corner cases and it is "tricky to get it right".

More in Tux Machines

Ubuntu-Centric Full Circle Magazine and Debian on the Raspberryscape

  • Full Circle Magazine: Full Circle Weekly News #121
  • Debian on the Raspberryscape: Great news!
    I already mentioned here having adopted and updated the Raspberry Pi 3 Debian Buster Unofficial Preview image generation project. As you might know, the hardware differences between the three families are quite deep ? The original Raspberry Pi (models A and B), as well as the Zero and Zero W, are ARMv6 (which, in Debian-speak, belong to the armel architecture, a.k.a. EABI / Embedded ABI). Raspberry Pi 2 is an ARMv7 (so, we call it armhf or ARM hard-float, as it does support floating point instructions). Finally, the Raspberry Pi 3 is an ARMv8-A (in Debian it corresponds to the ARM64 architecture). [...] As for the little guy, the Zero that sits atop them, I only have to upload a new version of raspberry3-firmware built also for armel. I will add to it the needed devicetree files. I have to check with the release-team members if it would be possible to rename the package to simply raspberry-firmware (as it's no longer v3-specific). Why is this relevant? Well, the Raspberry Pi is by far the most popular ARM machine ever. It is a board people love playing with. It is the base for many, many, many projects. And now, finally, it can run with straight Debian! And, of course, if you don't trust me providing clean images, you can prepare them by yourself, trusting the same distribution you have come to trust and love over the years.

OSS: SVT-AV1, LibreOffice, FSF and Software Freedom Conservancy

  • SVT-AV1 Already Seeing Nice Performance Improvements Since Open-Sourcing
    It was just a few weeks ago that Intel open-sourced the SVT-AV1 project as a CPU-based AV1 video encoder. In the short time since publishing it, there's already been some significant performance improvements.  Since the start of the month, SVT-AV1 has added multi-threaded CDEF search, more AVX optimizations, and other improvements to this fast evolving AV1 encoder. With having updated the test profile against the latest state as of today, here's a quick look at the performance of this Intel open-source AV1 video encoder.
  • Find a LibreOffice community member near you!
    Hundreds of people around the world contribute to each new version of LibreOffice, and we’ve interviewed many of them on this blog. Now we’ve collected them together on a map (thanks to OpenStreetMap), so you can see who’s near you, and find out more!
  • What I learned during my internship with the FSF tech team
    Hello everyone, I am Hrishikesh, and this is my follow-up blog post concluding my experiences and the work I did during my 3.5 month remote internship with the FSF. During my internship, I worked with the tech team to research and propose replacements for their network monitoring infrastructure. A few things did not go quite as planned, but a lot of good things that I did not plan happened along the way. For example, I planned to work on GNU LibreJS, but never could find enough time for it. On the other hand, I gained a lot of system administration experience by reading IRC conversations, and by working on my project. I even got to have a brief conversation with RMS! My mentors, Ian, Andrew, and Ruben, were extremely helpful and understanding throughout my internship. As someone who previously had not worked with a team, I learned a lot about teamwork. Aside from IRC, we interacted weekly in a conference call via phone, and used the FSF's Etherpad instance for live collaborative editing, to take notes. The first two months were mostly spent studying the FSF's existing Nagios- and Munin-based monitoring and alert system, to understand how it works. The tech team provided two VMs for experimenting with Prometheus and Nagios, which I used throughout the internship. During this time, I also spent a lot of time reading about licenses, and other posts about free software published by the FSF.
  • We're Hiring: Techie Bookkeeper
    Software Freedom Conservancy is looking for a new employee to help us with important work that supports our basic operations. Conservancy is a nonprofit charity that promotes and improves free and open source software projects. We are home to almost 50 projects, including Git, Inkscape, Etherpad, phpMyAdmin, and Selenium (to name a few). Conservancy is the home of Outreachy, an award winning diversity intiative, and we also work hard to improve software freedom generally. We are a small but dedicated staff, handling a very large number of financial transactions per year for us and our member projects.

Security: Back Doors Running Amok, Container Runtime Flaw Patched, Cisco Ships Exploit Inside Products

  • Here We Go Again: 127 Million Accounts Stolen From 8 More Websites
    Several days ago, a hacker put 617 million accounts from 16 different websites for sale on the dark web. Now, the same hacker is offering 127 million more records from another eight websites.
  • Hacker who stole 620 million records strikes again, stealing 127 million more
    A hacker who stole close to 620 million user records from 16 websites has stolen another 127 million records from eight more websites, TechCrunch has learned. The hacker, whose listing was the previously disclosed data for about $20,000 in bitcoin on a dark web marketplace, stole the data last year from several major sites — some that had already been disclosed, like more than 151 million records from MyFitnessPal and 25 million records from Animoto. But several other hacked sites on the marketplace listing didn’t know or hadn’t disclosed yet — such as 500px and Coffee Meets Bagel. The Register, which first reported the story, said the data included names, email addresses and scrambled passwords, and in some cases other login and account data — though no financial data was included.
  • Vendors Issue Patches for Linux Container Runtime Flaw Enabling Host Attacks
  • How did the Dirty COW exploit get shipped in software?
    An exploit code for Dirty COW was accidentally shipped by Cisco with product software. Learn how this code ended up in a software release and what this vulnerability can do.

10 Cool Software to Try from CORP Repo in Fedora

In this article, we will share 10 cool software projects to try in Fedora distribution. All the apps or tools covered here can be found in COPR repository. However, before we move any further, let’s briefly explain COPR. Read more