Once again The Kernel Testing & Dependability Micro-conference will be taking place at LPC 2023, to discuss testing and dependability related topics.

Please submit proposals for discussion via LPC submission system.

The Linux Plumbers 2023 Kernel Testing & Dependability track focuses on advancing the current state of testing of the Linux Kernel and its related infrastructure. The main purpose is to improve software quality and dependability for applications that require predictability and trust.

The goal of this micro-conference is making connections between folks working on similar projects, and help individual projects make progress.

This track is intended to promote collaboration between all the communities and people interested in the Kernel testing & dependability. This will help move the conversation forward from where we left off at the LPC 2022 Kernel Testing & Dependability MC.

We ask that any topic discussions focus on issues/problems they are facing and possible alternatives to resolving them. The Micro-conference is open to all topics related to testing on Linux, not necessarily in the kernel space.

Suggested topics:

• KernelCI: Topics on improvements and enhancements for test coverage
• Growing KCIDB, integrating more sources
• Sanitizers
• Using Clang for better testing coverage
• How to spread KUnit throughout the kernel?
• Building and testing in-kernel Rust code
• Explore ways to improve testing framework and tests in the kernelwith a specific goal to increase traceability and code coverage
• Explore how do SBOMs figure into dependability?

List of accomplishments this past year after LPC 2022:

• Developed a new, modern API for KernelCI with Pub/Sub interface
• Added Rust coverage in KernelCI
• KCIDB is continuing to gather results from many test systems: KernelCI, Red Hat’s CKI, syzbot, ARM, Gentoo, Linaro’s TuxSuite etc. The current focus is on generating common email reports based  on this data and dealing with known issues.
• KFENCE is continuing to aid in detecting Out-of-bound OOB accesses, use-after-free errors (UAF),  Double free and Invalid free and so on.
• Clang: CFI, weeding out issues upstream, etc.
• Kselftest continues to add coverage for new and existing features and subsystems.
• KUnit is continuing to act as the standard for some drivers and a de facto unit testing framework in the kernel
• The Runtime Verification (RV) interface from Daniel Bristot de Oliveira was merged.

Proposals can be submitted here, by August 20th:

MC leads can be reached for question and further information::
Shuah Khan (shuah@kernel.org)
Sasha Levin <sashal@kernel.org>
Guillaume Tucker <guillaume.tucker@collabora.com>

In the Linux ecosystems, there are many ways to build all the software used to put together a running system. Whether it’s building all the binary packages for a binary Linux distribution, using a source-based distribution, or building an embedded system from scratch, there are a lot of shared challenges which each system solves in its own way.

• Bootstrapping the build system
• Cross building software
• Make, autoconf, and other similar software build tools
• Package build systems, bitbake, emerge/portage, pacman, etc
• Packaging formats
• Managing software with language-specific package managers
• Patch sharing
• Building within a container
• Build systems for building containers
• License gathering and verification
• Security updates
• SBOMS
• Software chain-of-trust
• Repeatable builds
• Documentation and education
• Finding the next generation of maintainers
• Build-system visibility within the wider Plumbers attendeesThis is not a definitive list, and you are free to post abstracts for other related topics.

• Android
• Arch Linux
• Buildroot
• ChromeOS
• Gentoo
• OpenEmbedded
• OpenWRT/LEDE
• Yocto Project
• Other traditional Binary Packaged distributions

LPC 2023 will host the second edition of the Rust MC. This microconference intends to cover talks and discussions on both Rust for Linux as well as other non-kernel Rust topics. Proposals can be submitted via LPC submission system, selecting the Rust MC track.

Rust is a systems programming language that is making great strides in becoming the next big one in the domain. Rust for Linux is the project adding support for the Rust language to the Linux kernel.

Rust has a key property that makes it very interesting as the second language in the kernel: it guarantees no undefined behavior takes place (as long as unsafe code is sound). This includes no use-after-free mistakes, no double frees, no data races, etc. It also provides other important benefits, such as improved error handling, stricter typing, sum types, pattern matching, privacy, closures, generics, etc.

Possible Rust for Linux topics:

• Rust in the kernel (e.g. status update, next steps…).
• Use cases for Rust around the kernel (e.g. subsystems, drivers,
  other modules…).
• Discussions on how to abstract existing subsystems safely, on API design, on coding guidelines…
• Integration with kernel systems and other infrastructure (e.g. build system, documentation, testing and CIs, maintenance, unstable features, architecture support, stable/LTS releases, Rust versioning, third-party crates…).Updates on its subprojects (e.g. klint, pinned-init)

Possible Rust topics:

• Language and standard library (e.g. upcoming features, stabilization of the remaining features the kernel needs, memory model…).
• Compilers and codegen (e.g. rustc improvements, LLVM and Rust, rustc_codegen_gcc, Rust GCC…).
• Other tooling and new ideas (bindgen, Cargo, Miri, Clippy, Compiler Explorer, Coccinelle for Rust…).
• Educational material.
• Any other Rust topic within the Linux ecosystem.

Last year was the first edition of the Rust MC and the focus was on showing the ongoing efforts by different parties (compilers, Rust for Linux, CI, eBPF…). Shortly after the Rust MC, Rust got merged into the Linux kernel. Abstractions are getting upstreamed, with the first major drivers looking to be merged soon: Android Binder, the Asahi GPU driver and the NVMe driver (presented in that MC).

We are pleased to announce the first ever Linux Kernel Debugging Microconference, and we are now accepting proposals and problem statements.

Kernel debugging can be done in many ways with many purpose-built tools, from printk to Crash, Drgn, KDB/KGDB, and more. These tools are built on layers of standards, formats, implicit standards, and undocumented assumptions that make everything tick. When things work well, the tools stay out of your way and help you resolve your bug. But when things don’t work so well, you’re left debugging your debugger.

The Linux Kernel Debugging Microconference aims to bring together the developers and users of these tools to discuss the shared problems we face. We hope to discuss ongoing work that will improve the state of kernel debuggers, as well as new ideas that will require coordinated development across projects. Some possible topics might include:

• Alternative sources of debuginfo beyond DWARF (kallsyms, BTF, etc)
• Problems related to core debugging tools & utilities (`/proc/vmcore`,  `/proc/kcore`, kexec, kdump, makedumpfile, libkdumpfile, and many more).
• Strategies to handle the interpretation of core kernel subsystems across versions (e.g. slab & vfs).
• Core dump formats and ways they can break & be repaired

Topics outside this narrow list are welcomed: we welcome any topic that would improve the debugging experience, or merits the attention of the developers of these tools & kernel subsystems. The best submissions will describe active work or open problems, and they will welcome debate, discussion, and community consensus.

Submissions can be made via the LPC Call for Proposals, by selecting Linux Kernel Debugging MC for your track.