Language Selection

English French German Italian Portuguese Spanish

LWN Kernel Articles: 4.20/5.0 Merge, Jiri Kosina, Arnd Bergmann and Greg Kroah-Hartman

Filed under
Linux
  • 4.20/5.0 Merge window part 1

    Linus Torvalds has returned as the keeper of the mainline kernel repository, and the merge window for the next release which, depending on his mood, could be called either 4.20 or 5.0, is well underway. As of this writing, 5,735 non-merge changesets have been pulled for this release; experience suggests that we are thus at roughly the halfway point.

  • Improving the handling of embargoed hardware-security bugs

    Jiri Kosina kicked off a session on hardware vulnerabilities at the 2018 Kernel Maintainers Summit by noting that there are few complaints about how the kernel community deals with security issues in general. That does not hold for Meltdown and Spectre which, he said, had been "completely mishandled". The subsequent handling of the L1TF vulnerability suggests that some lessons have been learned, but there is still plenty of room for improvement in how hardware vulnerabilities are handled in general.

    There are a number of reasons why the handling of Meltdown and Spectre went bad, he said, starting with the fact that the hardware vendors simply did not know how to do it right. They didn't think that the normal security contact (security@kernel.org) could be used, since there was no non-disclosure agreement (NDA) in place there. Perhaps what is needed is the creation of such an agreement or, as was discussed in September, a "gentleman's agreement" that would serve the same role.

  • Removing support for old hardware from the kernel

    The kernel supports a wide range of hardware. Or, at least, the kernel contains drivers for a lot of hardware, but the hardware for which many of those drivers was written is old and, perhaps, no longer in actual use. Some of those drivers would certainly no longer work even if the hardware could be found. These drivers provide no value, but they are still an ongoing maintenance burden; it would be better to simply remove them from the kernel. But identifying which drivers can go is not as easy as one might think. Arnd Bergmann led an inconclusive session on this topic at the 2018 Kernel Maintainers Summit.

    Bergmann started by noting (to applause) that he recently removed support for eight processor architectures from the kernel. It was, he said, a lot of work to track down the right people to talk to before removing that code. In almost every case, the outgoing architectures were replaced — by their creators — by Arm-based systems. There probably are not any more architectures that can go anytime soon; Thomas Gleixner's suggestion that x86 should be next failed to win the support of the group.

  • The proper use of EXPORT_SYMBOL_GPL()

    The kernel, in theory, puts strict limits on which functions and data structures are available to loadable kernel modules; only those that have been explicitly exported with EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() are accessible. In the case of EXPORT_SYMBOL_GPL(), only modules that declare a GPL-compatible license will be able to see the symbol. There have been questions about when EXPORT_SYMBOL_GPL() should be used for almost as long as it has existed. The latest attempt to answer those questions was a session run by Greg Kroah-Hartman at the 2018 Kernel Maintainers Summit; that session offered little in the way of general guidance, but it did address one specific case.

More in Tux Machines

Variscite unveils two i.MX8 QuadMax modules

Variscite announced Linux-powered “VAR-SOM-MX8” and “SPEAR-MX8” modules with an up to an i.MX8 QuadMax SoC plus up to 8GB LPDDR4 and 64GB eMMC. It also previewed a VAR-SOM-6UL COM. At Embedded World next week in Nuremberg, Germany, Variscite will showcase its Linux and Android driven i.MX8-family computer-on-modules, including new VAR-SOM-MX8 and SPEAR-MX8 modules that feature NXP’s highest-end i.MX8 SoC up to a QuadMax model (see farther below). We have already covered most of the other showcased products, including the 14nm fabricated, quad -A53 i.MX8M Mini based DART-MX8M-Mini. When we covered the DART-MX8M-Mini in September, Variscite didn’t have an image or product page, but both are now available here Read more

Android Leftovers

Programming: Developer Happiness, Rblpapi 0.3.8 and Python

  • Developer happiness: What you need to know
    A person needs the right tools for the job. There's nothing as frustrating as getting halfway through a car repair, for instance, only to discover you don't have the specialized tool you need to complete the job. The same concept applies to developers: you need the tools to do what you are best at, without disrupting your workflow with compliance and security needs, so you can produce code faster. Over half—51%, to be specific—of developers spend only one to four hours each day programming, according to ActiveState's recent Developer Survey 2018: Open Source Runtime Pains. In other words, the majority of developers spend less than half of their time coding. According to the survey, 50% of developers say security is one of their biggest concerns, but 67% of developers choose not to add a new language when coding because of the difficulties related to corporate policies.
  • Rblpapi 0.3.8: Keeping CRAN happy
    A minimal maintenance release of Rblpapi, now at version 0.3.9, arrived on CRAN earlier today. Rblpapi provides a direct interface between R and the Bloomberg Terminal via the C++ API provided by Bloomberg (but note that a valid Bloomberg license and installation is required). This is the ninth release since the package first appeared on CRAN in 2016. It accomodates a request by CRAN / R Core to cope with staged installs which will be a new feature of R 3.6.0. No other changes were made (besides updating a now-stale URL at Bloomberg in a few spots and other miniscule maintenance). However, a few other changes have been piling up at the GitHub repo so feel free to try that version too.
  • Episode #200: Escaping Excel Hell with Python and Pandas
  • Testing native ES modules using Mocha and esm.

Games: Steam, Devil Engine, City Game Studio and More