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

Openwashing: Zenko (Dual), Kong (Mere API) and Blackboard (Proprietary and Malicious)

Games: Descenders, War Thunder’s “The Valkyries”

Kernel: Virtme, 2018 Linux Audio Miniconference and Linux Foundation Articles

  • Virtme: The kernel developers' best friend
    When working on the Linux Kernel, testing via QEMU is pretty common. Many virtual drivers have been recently merged, useful either to test the kernel core code, or your application. These virtual drivers make QEMU even more attractive.
  • 2018 Linux Audio Miniconference
    As in previous years we’re trying to organize an audio miniconference so we can get together and talk through issues, especially design decisons, face to face. This year’s event will be held on Sunday October 21st in Edinburgh, the day before ELC Europe starts there.
  • How Writing Can Expand Your Skills and Grow Your Career [Ed: Linux Foundation article]
    At the recent Open Source Summit in Vancouver, I participated in a panel discussion called How Writing can Change Your Career for the Better (Even if You don't Identify as a Writer. The panel was moderated by Rikki Endsley, Community Manager and Editor for Opensource.com, and it included VM (Vicky) Brasseur, Open Source Strategy Consultant; Alex Williams, Founder, Editor in Chief, The New Stack; and Dawn Foster, Consultant, The Scale Factory.
  • At the Crossroads of Open Source and Open Standards [Ed: Another Linux Foundation article]
    A new crop of high-value open source software projects stands ready to make a big impact in enterprise production, but structural issues like governance, IPR, and long-term maintenance plague OSS communities at every turn. Meanwhile, facing significant pressures from open source software and the industry groups that support them, standards development organizations are fighting harder than ever to retain members and publish innovative standards. What can these two vastly different philosophies learn from each other, and can they do it in time to ensure they remain relevant for the next 10 years?

Red Hat: PodCTL, Security Embargos at Red Hat and Energy Sector

  • [Podcast] PodCTL #50 – Listener Mailbag Questions
    As the community around PodCTL has grown (~8000 weekly listeners) we’ve constantly asked them to give us feedback on topics to discuss and areas where they want to learn. This week we discussed and answered a number of questions about big data and analytics, application deployments, routing security, and storage deployment models.
  • Security Embargos at Red Hat
    The software security industry uses the term Embargo to describe the period of time that a security flaw is known privately, prior to a deadline, after which time the details become known to the public. There are no concrete rules for handling embargoed security flaws, but Red Hat uses some industry standard guidelines on how we handle them. When an issue is under embargo, Red Hat cannot share information about that issue prior to it becoming public after an agreed upon deadline. It is likely that any software project will have to deal with an embargoed security flaw at some point, and this is often the case for Red Hat.
  • Transforming oil & gas: Exploration and production will reap the rewards
    Through advanced technologies based on open standards, Red Hat deliver solutions that can support oil and gas companies as they modernize their IT infrastructures and build a framework to meet market and technology challenges. Taking advantage of modern, open architectures can help oil and gas providers attract new customers and provide entry into markets where these kinds of services were technologically impossible a decade ago.