Language Selection

English French German Italian Portuguese Spanish

Linux and Linux Foundation: LWN Articles and Tungsten Fabric (Juniper Openwashing)

Filed under
  • A ring buffer for epoll

    The set of system calls known collectively as epoll was designed to make polling for I/O events more scalable. To that end, it minimizes the amount of setup that must be done for each system call and returns multiple events so that the number of calls can also be minimized. But that turns out to still not be scalable enough for some users. The response to this problem, in the form of this patch series from Roman Penyaev, takes a familiar form: add yet another ring-buffer interface to the kernel.
    The poll() and select() system calls can be used to wait until at least one of a set of file descriptors is ready for I/O. Each call, though, requires the kernel to set up an internal data structure so that it can be notified when any given descriptor changes state. Epoll gets around this by separating the setup and waiting phases, and keeping the internal data structure around for as long as it is needed.

  • Yet another try for fs-verity

    The fs‑verity mechanism has its origins in the Android project; its purpose is to make individual files read-only and enable the kernel to detect any modifications that might have been made, even if those changes happen offline. Previous fs‑verity implementations have run into criticism in the development community, and none have been merged. A new version of the patch set was posted on May 23; it features a changed user-space API and may have a better chance of getting into the mainline.
    Fs‑verity works by associating a set of hashes with a file; the hash values can be used to check that the contents of the file have not been changed. In current implementations, the hashes are stored in a Merkle tree, which allows for quick verification when the file is accessed. The tree itself is hashed and signed, so modifications to the hash values can also be detected (and access to the file blocked). The intended use case is to protect critical Android packages even when an attacker is able to make changes to the local storage device.

    Previous versions of the fs‑verity patches ran aground over objections to how the API worked. To protect a file, user space would need to generate and sign a Merkle tree, then append that tree to the file itself, aligned to the beginning of a filesystem block. After an ioctl() call, the kernel would hide the tree, making the file appear to be shorter than it really was, while using the tree to verify the file's contents. This mechanism was seen as being incompatible with how some filesystems manage space at the end of files; developers also complained that it exposed too much about how fs‑verity was implemented internally. In the end, an attempt to merge this code for 5.0 was not acted upon, and fs‑verity remained outside of the mainline.

  • How many kernel test frameworks?

    The kernel self-test framework (kselftest) has been a part of the kernel for some time now; a relatively recent proposal for a kernel unit-testing framework, called KUnit, has left some wondering why both exist. In a lengthy discussion thread about KUnit, the justification for adding another testing framework to the kernel was debated. While there are different use cases for kselftest and KUnit, there was concern about fragmenting the kernel-testing landscape.

    In early May, Brendan Higgins posted v2 of the KUnit patch set with an eye toward getting it into Linux 5.2. That was deemed a bit of an overaggressive schedule by Greg Kroah-Hartman and Shuah Khan given that the merge window would be opening a week later or so. But Khan did agree that the patches could come in via her kselftest tree. There were some technical objections to some of the patches, which is no surprise, but overall the patches were met with approval—and some Reviewed-by tags.

    There were some sticking points, however. Several, including Kroah-Hartman and Logan Gunthorpe complained about the reliance on user-mode Linux (UML) to run the tests. Higgins said that he had "mostly fixed that". The KUnit tests will now run on any architecture, though the Python wrapper scripts are still expecting to run the tests in UML. He said that he should probably document that, which is something that he has subsequently done.

  • SIGnals from KubeCon

    The basic organizational construct within the Kubernetes project is a set of Special Interest Groups (SIGs), each of which represents a different area of responsibility within the project. Introductions to what the various SIGs do, as well as more detailed sessions, were a core part of KubeCon + CloudNativeCon Europe 2019, as the different groups explained what they're doing now and their plans for the future. Two sessions, in particular, covered the work of the Release and Architecture SIGs, both of which have a key role in driving the project forward.

  • Introducing Tungsten Fabric 5.1: Security, Feature, and Performance Enhancements for Network Operators & Developers

    The Tungsten Fabric (TF) community is excited and proud to announce our latest release, 5.1. The TF community has been hard at work on both community and technical challenges to ensure a rich and vibrant community to solve the toughest networking challenges regardless of public cloud, orchestrator, or workload. The 5.1 release reflects that effort. It is an excellent time to take a look at Tungsten Fabric as a developer or an operator for your networking needs in this multi-cloud world. Here is a quick summary of the TF 5.1 release highlights.

More in Tux Machines

Annual Report 2018: LibreOffice development

Throughout the second half of 2018, the developer community worked on a new major release: LibreOffice 6.2. Details about the end-user-facing new features are provided on this page, and in the following video – so in the rest of this blog post, we’ll focus on developer-related changes. Read more

Programming Leftovers

Linux Kernel: Chrome OS, Direct Rendering Manger (DRM) and Char/Misc

  • Various Chrome OS Hardware Support Improvements Make It Into Linux 5.3 Mainline

    Various Chrome OS hardware platform support improvements have made it into the Linux 5.3 kernel for those after running other Linux distributions on Chromebooks and the like as well as reducing Google's maintenance burden with traditionally carrying so much material out-of-tree.

  • The Massive DRM Pull Request With AMDGPU Navi Support Sent In For Linux 5.3

    At 479,818 lines of new code and just 36,145 lines of code removed while touching nearly two thousand files, the Direct Rendering Manger (DRM) driver updates for Linux 5.3 are huge. But a big portion of that line count is the addition of AMD Radeon RX 5000 "Navi" support and a good portion of that in turn being auto-generated header files. Navi support is ready for the mainline Linux kernel!

  • Char/Misc Has A Bit Of Changes All Over For Linux 5.3

    The char/misc changes with each succeeding kernel release seem to have less changes to the character device subsystem itself and more just a random collection of changes not fitting in other subsystems / pull requests. With Linux 5.3 comes another smothering of different changes.

today's howtos