Ariel D'Alessandro
May 04, 2021
Share this post:
Reading time:
While the kernel community has kept an always accelerating pace of development with no slowdown in sight, the release process has reached such maturity that a new release might sound a bit uneventful. But, when we are talking about one of the pieces of software used to fly that helicopter on Mars earlier this year, uneventful is exactly what you want.
In fact, as the resilience of the release process is proven over and over, more and more companies have been able to drop their vendor trees based on decade old Linux versions, and base their work on the bleeding edge technologies available in the latest versions.
At Collabora, we are more than ever dedicated to help vendors achieve this goal by closing the gap between hardware support on vendor trees and the mainline tree. In this release we have expanded that effort with our customary contributions all around the kernel, in particular we have paid attention to the Video4Linux APIs and hardware enablement.
One fact of life is that file systems do fail. Detecting errors over a fleet of servers is actually a tricky effort since there is no generic way to monitor different filesystems without peeking at dmesg and filtering through thousands of messages of each machine in the fleet, a process that is both cumbersome and prone to missing messages in high traffic situations. Nevertheless, Gabriel Krisman Bertazi has been on a quest to find the right API to report file system errors in a generic way, but still providing detailed enough information that it can be used by online monitoring recovery tools.
The current approach, which is being discussed on the mailing list, is a push interface based on fanotify, in which monitoring applications register themselves as the recipient of error messages from a specific file system and get notified by the kernel when an error event occurs. Each message carries a generic header indicating that an error occurred but also optionally includes a filesystem specific message with (hopefully) enough debug data that a monitoring tool can figure out what went wrong and recover from it. In the current cycle, the interface is still under discussion to decide what information needs to be provided, but small fixes to watch_queue and fanotify already started to flow into the mainline kernel.
In 2020, Collabora contributed more than 200 patches to the media subsystem. Our main areas of work have been codecs and Image Signal Processors (i.e. Cameras) which resulted in two big milestones for the previous release v5.11: the destaging of the stateless H.264 V4L2 API and the RKISP1 driver.
Big changes are being prepared for v5.13 and v5.14, some of which we've already blogged about, some of which are still under discussion.
For this v5.12 release, a relatively small changeset was merged which improved the V4L2 Async notifier API. This API needed some love, and being a hot summer in Argentina, Ezequiel had plenty API-love to give. As a result, the V4L2 Async notifier API is now consistent, easier to use and more importantly, "harder to get wrong". Hope you are proud, Rusty!
Finally, a nice side-effect of this work is the removal of a legacy V4L2-internal API for clocks. It turned out there was a small number of users, so the conversion to the Common Clock Framework API was quick and easy.
Open source is about community, it's about contributing and sharing code, allowing everyone to use, modify and extend the software without having to reinvent the wheel, even if it wasn't completed yet.
This is the case of Collaboran Sebastian Reichel's patchset, which started as an RFC more than a year ago and was finally merged into mainline with release v5.12.
Thanks to omapdrm maintainer Tomi Valkeinen, who brought this up again and completed the upstream, the 84 patches in this series have made omapdrm's DSI code cleaner than ever (1000+ lines of code removed) in favour of becoming a generic drm_panel. It's worth mentioning that "No features were harmed in the hacking of this driver".
As part of Collabora's efforts to improve the mainline Linux kernel support on Chromebook devices, a new TPM 2.0 driver was added to handle communication with the Google CR50 chip firmware which uses a customized I2C-based protocol. TPM chip support is important for improving user data and device security. Having this driver upstream is a good step forward for various open-source projects besides the kernel, like ChromiumOS and the general development community, as well as end-users.
Contributing is not only about sending patches. Reviewing and testing source code, along with discussions and reporting to the kernel community, are important tasks that Collaborans carry on every release and v5.12 is not an exception!
Collabora's Kernel team, which includes some subsystem maintainers, have been contributing to ChromeOS EC platform support, power/supply and reset/shutdown subsystems, Mediatek SoC support and much, much more.
Yet again, KernelCI is showing its benefits. Guillaume Tucker reported and tested Page Fault errors on Tegra platform thanks to a KernelCI automated bisection. Want to know more about KernelCI? Check out our recent blog post!
Alyssa Rosenzweig (1):
André Almeida (2):
Boris Brezillon (1):
Dafna Hirschfeld (3):
Enric Balletbo i Serra (3):
Ezequiel Garcia (26):
Gabriel Krisman Bertazi (1):
Helen Koike (3):
Sebastian Reichel (53):
Enric Balletbo i Serra (7):
Sebastian Reichel (51):
Adrian Ratiu (1):
Ezequiel Garcia (1):
Fabien Lahoudere (1):
Sebastian Reichel (28):
Andreas Kemnade (1):
Arthur Demchenkov (4):
Cristian Ciocaltea (1):
Dmitry Osipenko (1):
Duncan Laurie (2):
Hermes Zhang (1):
Jian Dong (1):
Junlin Yang (1):
Laurent Pinchart (1):
Linus Walleij (2):
Pavel Machek (2):
Randy Dunlap (1):
Ricardo Rivera-Matos (2):
Timon Baetz (1):
Tony Lindgren (9):
Zheng Yongjun (1):
Boris Brezillon (1):
Emil Velikov (1):
Enric Balletbo i Serra (8):
Gabriel Krisman Bertazi (1):
Helen Koike (13):
Pekka Paalanen (2):
Sebastian Reichel (35):
Alyssa Rosenzweig (1):
Dafna Hirschfeld (1):
Daniel Stone (1):
Enric Balletbo i Serra (4):
Helen Koike (1):
Pekka Paalanen (3):
Adrian Ratiu (1):
Enric Balletbo i Serra (1):
Ezequiel Garcia (1):
Gabriel Krisman Bertazi (1):
Guillaume Tucker (2):
Emil Velikov (1):
Guillaume Tucker (1):
20/12/2024
The Rockchip RK3588 upstream support has progressed a lot over the last few years. As 2024 comes to a close, it is a great time to have…
09/12/2024
Collabora will be at NeurIPs this week to dive into the latest academic findings in machine learning and research advancements that are…
05/12/2024
Now based on Debian Bookworm, Apertis is a collaborative OS platform that includes an operating system, but also tools and cloud services…
Whether writing a line of code or shaping a longer-term strategic software development plan, we'll help you navigate the ever-evolving world of Open Source.
한국어 버전의 Collabora.com 보기
Acesse Collabora.com em Português
Comments (0)
Add a Comment