Language Selection

English French German Italian Portuguese Spanish

Latest Open Access LWN: Fedora, Linux Kernel, and Graphics

Filed under
Graphics/Benchmarks
Linux
Red Hat
  • Fedora's foundations meet proprietary drivers

    The Fedora project's four "foundations" are named "Freedom", "Friends", "Features", and "First". Among other things, they commit the project to being firmly within the free-software camp ("we believe that advancing software and content freedom is a central goal for the Fedora Project, and that we should accomplish that goal through the use of the software and content we promote") and to providing leading-edge software, including current kernels. Given that the kernel project, too, is focused on free software, it is interesting to see a call within the Fedora community to hold back on kernel updates in order to be able to support a proprietary driver.

    On September 5, Fedora kernel maintainer Laura Abbott announced that the just-released 4.13 kernel would be built for the (in-development) Fedora 27 release, and that it would eventually find its way into the Fedora 25 and 26 releases as well. That is all in line with how Fedora generally operates; new kernels are pushed out to all supported releases in relatively short order. Running current kernels by default is clearly a feature that many Fedora users find useful.

    More recently, though, James Hogarth noted that the NVIDIA proprietary driver did not work with the 4.13 kernel. This kind of breakage is not all that unusual. While the user-space ABI must be preserved, the kernel project defends its right to change internal interfaces at any time. Any problems that out-of-tree code experiences as a result of such changes is deemed to be part of the cost of staying out of the mainline. There is little sympathy for those who have to deal with such issues, and none at all if the out-of-tree code in question is proprietary. Community-oriented projects like Fedora usually take a similar attitude, refusing to slow down for the sake of proprietary code.

  • Notes from the LPC tracing microconference

    The "tracing and BPF" microconference was held on the final day of the 2017 Linux Plumbers Conference; it covered a number of topics relevant to heavy users of kernel and user-space tracing. Read on for a summary of a number of those discussions on topics like BPF introspection, stack traces, kprobes, uprobes, and the Common Trace Format.

    Unfortunately, your editor had to leave the session before it reached its end, so this article does not reflect all of the topics discussed there. For those who are interested, this Etherpad instance contains notes taken by participants at the session.

  • An update on live kernel patching

    In the refereed track at the 2017 Linux Plumbers Conference (LPC), Jiri Kosina gave an update on the status and plans for the live kernel patching feature. It is a feature that has a long history—pre-dating Linux itself—and has had a multi-year path into the kernel. Kosina reviewed that history, while also looking at some of the limitations and missing features for live patching.

    The first question that gets asked about patching a running kernel is "why?", he said. That question gets asked in the comments on LWN articles and elsewhere. The main driver of the feature is the high cost of downtime in data centers. That leads data center operators to plan outages many months in advance to reduce the cost; but in the case of a zero-day vulnerability, that time is not available. Live kernel patching is targeted at making small security fixes as a stopgap measure until the kernel can be updated during a less-hurried, planned outage. It is not meant for replacing the kernel bit by bit over time, but as an emergency measure when the kernel is vulnerable.

  • Safety-critical realtime with Linux

    Doing realtime processing with a general-purpose operating-system like Linux can be a challenge by itself, but safety-critical realtime processing ups the ante considerably. During a session at Open Source Summit North America, Wolfgang Mauerer discussed the difficulties involved in this kind of work and what Linux has to offer.

    Realtime processing, as many have said, is not synonymous with "real fast". It is, instead, focused on deterministic response time and repeatable results. Getting there involves quantifying the worst-case scenario and being prepared to handle it — a 99% success rate is not good enough. The emphasis on worst-case performance is at the core of the difference with performance-oriented processing, which uses caches, lookahead algorithms, pipelines, and more to optimize the average case.

  • A memory allocation API for graphics devices

    At last year's X.Org Developers Conference (XDC), James Jones began the process of coming up with an API for allocating memory so that it is accessible to multiple different graphics devices in a system (e.g. GPUs, hardware compositors, video decoders, display hardware, cameras, etc.). At XDC 2017 in Mountain View, CA, he was back to update attendees on the progress that has been made. He has a prototype in progress, but there is plenty more to do, including working out some of the problems he has encountered along the way.

    Jones has been at NVIDIA for 13 years and has been working on this problem in various forms for most of that time, he said. Allocating buffers and passing them around between multiple drivers is a complicated problem. The allocator will sit in the same place as the Generic Buffer Management (GBM) component is today; it will be used both by applications and by various user-space driver components. The allocator will support both vendor-agnostic (e.g. Android ION) and vendor-specific back-ends, as well as combinations of the two.

More in Tux Machines

Unixstickers

Unixstickers

Awesome products, will definitely get another bunch of some more stickers soon :-)

Android Leftovers

DragonFlyBSD 5.2.2 Released To Fix The Lazy State Save/Restore Bug

DragonFlyBSD 5.2.2 is now available as the latest stable release to this popular BSD operating system. While there aren't usually two point releases per cycle for DragonFlyBSD, the v5.2.2 release is coming to address the recent "Lazy FPU" vulnerability affecting Intel CPUs due to Lazy State Save/Restore as the newest CPU speculation bug. DragonFlyBSD began patching their kernel earlier this month and now those fixes are available in stable form with the DragonFlyBSD 5.2.2 release. The OpenBSD folks have also been changing around their kernel and FreeBSD 11.2 RC3 is also mitigated. Read more

Canonical/Ubuntu: Canonical's Engineering Tech Lead, Field Product Manager, and Designers'/Developers' Updates

  • A Complete Look At Spectre V1/V2/V4 & Meltdown
    Canonical's Engineering Tech Lead, Gavin Guo, has passed along a big slide deck on a presentation he is preparing about the Spectre and Meltdown CPU vulnerabilities. Gavin's presentation is mostly focused on Spectre V2 since that is vulnerable to attacking the host system from a guest VM, but the other vulnerabilities are also covered in his 77-page slide deck with great detail.
  • A unified OpenStack for a scalable open infrastructure
    Stu Miniman and John Boyer of theCUBE interviewed Mark Baker, Field Product Manager, Canonical at the OpenStack Summit in Vancouver. Read on to to find out about OpenStack’s increasing maturity. The Kubernetes and OpenStack story isn’t simple. Challenges exist, and plenty of pathfinding still needs to take place when it comes to Kubernetes. Customers want to take different approaches with how they want to plug together OpenStack components in order to create a unified stack is complex. Some customers want Kubernetes running alongside OpenStack, or on top of OpenStack, or even OpenStack running on Kubernetes.
  • Design and Web team summary – 18 June 2018
    Welcome to the latest work and updates from the design and web team.
  • Ubuntu Weekly Newsletter Issue 532
    Welcome to the Ubuntu Weekly Newsletter, Issue 532 for the week of June 10 – 16, 2018.