After having run a standalone BPF microconference for the first time in last year's    Linux Plumbers conference, we've been overwhelmed with throughout positive feedback. We received more submissions than we could have accommodated for the one-day slot, and the room at the conference venue was fully packed despite the fact that the networking track had about half of their submissions with BPF related topics as well.
We would like to continue on this success by organizing a BPF micro conference also for 2019. The microconference is aiming to catch BPF related kernel topics mainly in BPF core area as well as having focused discussions in specific subsystems (tracing, security,
networking) with short 1-2 slides in order to get BPF developers together in a face to face working meetup for tackling and hashing out unresolved issues and discussing new ideas.
Folks knowledgeable with BPF that work in core areas or in subsystems making use of BPF.
- libbpf, loader unification
- Standardized BPF ELF format
- Multi-object semantics and linker-style logic for BPF loaders
- Improving verifier scalability to 1 million instructions
- Sleep-able bpf programs
- State on BPF loop support
- Proper String support in BPF
- Indirect calls in BPF
- BPF timers
- BPF type format (BTF)
- Unprivileged BPF
- BTF of vmlinux
- BTF annotated raw_tracepoints
- BPF (k)litmus support
- LLVM BPF backend
- JITs and BPF offloading
- More to be added based on CfP for this microconference
The Linux Plumbers 2019 RISC-V MC will continue the trend established in 2018  to address different relevant problems in RISC-V Linux land.
The overall progress in RISC-V software ecosystem since last year has been really impressive. To continue the similar growth, RISC-V track at Plumbers will focus on finding solutions and discussing ideas that require kernel changes. This will also result in a significant increase in active developer participation in code review/patch submissions which will definitely lead to a better and more stable kernel for RISC-V.
- RISC-V Platform Specification Progress, including some extensions such as power management - Palmer Dabbelt
- Fixing the Linux boot process in RISC-V (RISC-V now has better support for open source boot loaders like U-Boot and coreboot compared to last year. As a result of this developers can use the same boot loaders to boot Linux on RISC-V as they do in other architectures, but there's more work to be done) - Atish Patra
- RISC-V hypervisor emulation  - Alistair Francis
- RISC-V hypervisor implementation - Anup Patel
- NOMMU Linux for RISC-V - Damien Le Moal
- More to be added based on CfP for this microconference
- Atish Patra <email@example.com> or Palmer Dabbelt <firstname.lastname@example.org>
The Linux Plumbers 2019 is pleased to welcome the Tracing microconference again this year. Tracing is once again picking up in activity. New and exciting topics are emerging.
There is a broad list of ways to perform Tracing in Linux. From the original mainline Linux tracer, Ftrace, to profiling tools like perf, more complex customized tracing like BPF and out of tree tracers like LTTng, systemtap and Dtrace. Come and join us and not only learn but help direct the future progress of tracing inside the Linux kernel and beyond!
- bpf tracing – Anything to do with BPF and tracing combined
- libtrace – Making libraries from our tools
- Packaging – Packaging these libraries
- babeltrace – Anything that we need to do to get all tracers talking to each other
- Those pesky tracepoints – How to get what we want from places where trace events are taboo
- Changing tracepoints – Without breaking userspace
- Function tracing – Modification of current implementation
- Rewriting of the Function Graph tracer – Can kretprobes and function graph tracer merge as one
- Histogram and synthetic tracepoints – Making a better interface that is more intuitive to use
- More to be added based on CfP for this microconference
- Steven Rostedt (email@example.com)
The upstream kernel community is where active kernel development happens but the majority of kernels deployed do not come directly from upstream but distributions. "Distribution" here can refer to a traditional Linux distribution such as Debian or Gentoo but also Android or a custom cloud distribution. The goal of this Microconference is to discuss common problems that arise when trying to maintain a kernel.
- Backporting kernel patches and how to make it easier
- Consuming the stable kernel trees
- Automated testing for distributions
- Managing ABIs
- Distribution packaging/infrastructure
- Cross distribution bug reporting and tracking
- Common distribution kconfig
- Distribution default settings
- Which patch sets are distributions carrying?
- More to be added based on CfP for this microconference
"Distribution kernel" is used in a very broad manner. If you maintain a kernel tree for use by others, we welcome you to come and share your experiences.
- Laura Abbott <firstname.lastname@example.org>
The Containers and Checkpoint/Restore MC at Linux Plumbers is the opportunity for runtime maintainers, kernel developers and others involved with containers on Linux to talk about what they are up to and agree on the next major changes to kernel and userspace.
Last year's edition covered a range of subjects and a lot of progress has been made on all of them. There is a working prototype for an id shifting filesystem some distributions already choose to include, proper support for running Android in containers via binderfs, seccomp-based syscall interception and improved container migration through the userfaultfd patchsets.
Last year's success has prompted us to reprise the microconference this year. Topics we would like to cover include:
- Android containers
- Agree on an upstreamable approach to shiftfs
- Securing containres by rethinking parts of ptrace access permissions, restricting or removing the ability to re-open file descriptors through procfs with higher permissions than they were originally created with, and in general how to make procfs more secure or restricted.
- Adoption and transition of cgroup v2 in container workloads
- Upstreaming the time namespace patchset
- Adding a new clone syscall
- Adoption and improvement of the new mount and pidfd APIs
- Improving the state of userfaultfd and its adoption in container runtimes
- Speeding up container live migration
- Address space separation for containers
- More to be added based on CfP for this microconference
- Stéphane Graber <email@example.com>, Christian Brauner <firstname.lastname@example.org>, and Mike Rapoport <email@example.com>
The Internet of Things (IoT) has been growing at an incredible pace as of late.
Some IoT application frameworks expose a model-based view of endpoints, such as
- on-off switches
- dimmable switches
- temperature controls
- door and window sensors
Other IoT application frameworks provide direct device access, by creating real and virtual device pairs that communicate over the network. In those cases, writing to the virtual /dev node on a client affects the real /dev node on the server. Examples are
- GPIO (/dev/gpiochipN)
- I2C (/dev/i2cN)
- SPI (/dev/spiN)
- UART (/dev/ttySN)
Interoperability (e.g. ZigBee to Thread) has been a large focus of many vendors due to the surge in popularity of voice-recognition in smart devices and the markets that they are driving. Corporate heavyweights are in full force in those economies. OpenHAB, on the other hand, has become relatively mature as a technology and vendor agnostic open-source front-end for interacting with multiple different IoT frameworks.
The Linux Foundation has made excellent progress bringing together the business community around the Zephyr RTOS, although there are also plenty of other open-source RTOS solutions available. The linux-wpan developers have brought 6LowPan to the community, which works over 802.15.4 and Bluetooth, and that has paved the way for Thread, LoRa, and others. However, some closed or quasi-closed standards must rely on bridging techniques mainly due to license incompatibility. For that reason, it is helpful for the kernel community to preemptively start working on application layer frameworks and bridges, both community-driven and business-driven.
For completely open-source implementations, experimental results have shown results with Greybus, with a significant amount of code already in staging. The immediate benefits to the community in that case are clear. There are a variety of key subjects below the application layer that come into play for Greybus and other frameworks that are actively under development, such as
- Device Management
- are devices abstracted through an API or is a virtual /dev node provided?
- unique ID / management of possibly many virtual /dev nodes and connection info
- Network Management
- standards are nice (e.g. 802.15.4) and help to streamline in-tree support
- non-standard tech best to keep out of tree?
- userspace utilities beyond command-line (e.g. NetworkManager, NetLink extensions)
- Network Authentication
- re-use machinery for e.g. 802.11 / 802.15.4 ?
- generic approach for other MAC layers ?
- in userspace via e.g. SSL, /dev/crypto
- Firmware Updates
- generally different protocol for each IoT framework / application layer
- Linux solutions should re-use components e.g. SWUpdate
This Microconference will be a meeting ground for industry and hobbyist contributors alike and promises to shed some light on the what is yet to come. There might even be a sneak peak at some new OSHW IoT developer kits.
The hope is that some of the more experienced maintainers in linux-wpan, LoRa and OpenHAB can provide feedback and suggestions for those who are actively developing open-source IoT frameworks, protocols, and hardware.
Christopher Friedt <firstname.lastname@example.org>, Jason Kridner <email@example.com>, and Drew Fustini <firstname.lastname@example.org>
The main purpose of the Linux Plumbers 2019 Live Patching microconference is to involve all stakeholders in open discussion about remaining issues that need to be solved in order to make live patching of the Linux kernel and the Linux userspace live patching feature complete.
The intention is to mainly focus on the features that have been proposed (some even with a preliminary implementation), but not yet finished, with the ultimate goal of sorting out the remaining issues.
This proposal follows up on the history of past LPC live patching microconferences that have been very useful and pushed the development forward a lot.
Currently proposed discussion/presentation topic proposals (we've not gone through "internal selection process yet") with tentatively confirmed attendance:
- 5 min Intro - What happened in kernel live patching over the last year
- API for state changes made by callbacks 
- source-based livepatch creation tooling 
- klp-convert 
- livepatch developers guide
- userspace live patching
Jiri Kosina <email@example.com> and Josh Poimboeuf <firstname.lastname@example.org>
The Open Printing (OP) organisation works on the development of new printing architectures, technologies, printing infrastructure, and interface standards for Linux and Unix-style operating systems. OP collaborates with the IEEE-ISTO Printer Working Group (PWG) on IPP projects.
We maintain cups-filters which allows CUPS to be used on any Unix-based (non-macOS) system. Open Printing also maintains the Foomatic database which is a database-driven system for integrating free software printer drivers with CUPS under Unix. It supports every free software printer driver known to us and every printer known to work with these drivers.
Today it is very hard to think about printing in UNIX based OSs without the involvement of Open Printing. Open Printing has been successful in implementing driverless printing following the IPP standards proposed by the PWG as well.
- Working with SANE to make IPP scanning a reality. We need to make scanning work without device drivers similar to driverless printing.
- Common Print Dialog Backends.
- Printer/Scanner Applications - The new format for printer and scanner drivers. A simple daemon emulating a driverless IPP printer and/or scanner.
- The Future of Printer Setup Tools - IPP Driverless Printing and IPP System Service. Controlling tools like cups-browsed (or perhaps also the print dialog backends?) to make the user's print dialogs only showing the relevant ones or to create printer clusters.
- 3D Printing without the use of any slicer. A filter that can convert a stl code to a gcode.
Till Kamppeter <email@example.com> or Aveek Basu <firstname.lastname@example.org>
The goal of the Toolchains Microconference is to focus on specific topics related to the GNU Toolchain and Clang/LLVM that have a direct impact in the development of the Linux kernel.
The intention is to have a very practical MC, where toolchain and kernel hackers can engage and, together:
- Identify problems, needs and challenges.
- Propose, discuss and agree on solutions for these specific problems.
- Coordinate on how to implement the solutions, in terms of interfaces, patches submissions, etc in both kernel and toolchain component.
Consequently, we will discourage vague and general "presentations" in favor of concreteness and to-the-point discussions, encouraging the participation of everyone present.
Examples of topics to cover:
- Header harmonization between kernel and glibc.
- Wrapping syscalls in glibc.
- eBPF support in toolchains.
- Potential impact/benefit/detriment of recently developed GCC optimizations on the kernel.
- Kernel hot-patching and GCC.
- Online debugging information: CTF and BTF
Jose E. Marchesi <email@example.com> and Elena Zannoni <firstname.lastname@example.org>
The Linux Plumbers 2019 Testing and Fuzzing track focuses on advancing the current state of testing of the Linux Kernel.
- Defragmentation of testing infrastructure: how can we combine testing infrastructure to avoid duplication.
- Better sanitizers: Tag-based KASAN, making KTSAN usable, etc.
- Better hardware testing, hardware sanitizers.
- Are fuzzers "solved"?
- Improving real-time testing.
- Using Clang for better testing coverage.
- Unit test framework. Content will most likely depend on the state of the patch series closer to the event.
- Future improvement for KernelCI. Bringing in functional tests? Improving the underlying infrastructure?
- Making KMSAN/KTSAN more usable.
- KASAN work in progress
- Syzkaller (+ fuzzing hardware interfaces)
- Stable tree (functional) testing
- KernelCI (autobisect + new testing suites + functional testing)
- Kernel selftests
Our objective is to gather leading developers of the kernel and it’s related testing infrastructure and utilities in an attempt to advance the state of the various utilities in use (and possibly unify some of them), and the overall testing infrastructure of the kernel. We are hopeful that we could build on the experience of the participants of this MC to create solid plans for the upcoming year.
Sasha Levin <email@example.com> and Dhaval Giani <firstname.lastname@example.org>
Since 2004 a project has improved the Real-time and low-latency features for Linux. This project has become know as PREEMPT_RT, formally the real-time patch. Over the past decade, many parts of the PREEMPT RT became part of the official Linux code base. Examples of what came from PREEMPT_RT include: Real-time mutexes, high-resolution timers, lockdep, ftrace, RT scheduling, SCHED_DEADLINE, RCU_PREEMPT, generic interrupts, priority inheritance futexes, threaded interrupt handlers and more. The number of patches that need integration has been reduced from previous years, and the pieces left are now mature enough to make their way into mainline Linux. This year could possibly be the year PREEMPT_RT is merged (tm)!
In the final lap of this race, the last patches are on the way to be merged, but there are still some pieces missing. When the merge occurs, PREEMPT_RT will start to follow a new pace: the Linus one. So, it is possible to raise the following discussions:
- The status of the merge, and how can we resolve the last issues that block the merge;
- How can we improve the testing of the -rt, to follow the problems raised as Linus's tree advances;
- What's next?
- Real-time Containers
- Proxy execution discussion
- Merge - what is missing and who can help?
- Rework of softirq - what is need for the -rt merge
- An in-kernel view of Latency
- Ongoing work on RCU that impacts per-cpu threads
- How BPF can influence the PREEMPT_RT kernel latency
- Core-schedule and the RT schedulers
- Stable maintainers tools discussion & improvements.
- Improvements on full CPU isolation
- What tools can we add into tools/ that other kernel developers can use to test and learn about PREEMPT_RT?
- What tests can we add to tools/testing/selftests?
- New tools for timing regression test, e.g. locking, overheads...
- What kernel boot self-tests can be added?
- Discuss various types of failures that can happen with PREEMPT_RT that normally would not happen in the vanilla kernel, e.g, with lockdep, preemption model.
The continuation of the discussion of topics from last year's microconference, including the development done during this (almost) year, are also welcome!
Daniel Bristot de Oliveira <email@example.com>
Databases utilize and depend on a variety of kernel interfaces and are critically dependent on their specification, conformance to specification, and performance. Failure in any of these results in data loss, loss in revenue, or degraded experience or if discovered early, software debt. Specific interfaces can also remove small or large parts of user space code creating greater efficiencies.
This microconference will get a group of database developers together to talk about how their databases work, along with kernel developers currently developing a particular database-focused technology to talk about its interfaces and intended use.
Database developers are expected to cover:
- The architecture of their database;
- The kernel interfaces utilized, particularly those critical to performance and integrity
- What is a general performance profile of their database with respect to kernel interfaces;
- What kernel difficulties they have experienced;
- What kernel interfaces are particularly useful;
- What kernel interfaces would have been nice to use, but were discounted for a particular reason;
- Particular pieces of their codebase that have convoluted implementations due to missing syscalls; and
- The direction of database development and what interfaces to newer hardware, like NVDIMM, atomic write storage, would be desirable.
The aim for kernel developers attending is to:
- Gain a relationship with database developers;
- Understand where in development kernel code they will need additional input by database developers;
- Gain an understanding on how to run database performance tests (or at least who to ask);
- Gain appreciation for previous work that has been useful; and
- Gain an understanding of what would be useful aspects to improve.
The aim for database developers attending is to:
- Gain an understanding of who is implementing the functionality they need;
- Gain an understanding of kernel development;
- Learn about kernel features that exist, and how they can be incorporated into their implementation; and
- Learn how to run a test on a new kernel feature.
Daniel Black <firstname.lastname@example.org>
Following the success of the past 3 years at LPC, we would like to see a 4th RDMA (Remote Direct Memory Access networking) microconference this year. The meetings in the last conferences have seen significant improvements to the RDMA subsystem merged over the years: new user API, container support, testability/syzkaller, system bootup, Soft iWarp, etc.
In Vancouver, the RDMA track hosted some core kernel discussions on get_user_pages that is starting to see its solution merged. We expect that again RDMA will be the natural microconf to hold these quasi-mm discussions at LPC.
This year there remain difficult open issues that need resolution:
- RDMA and PCI peer to peer for GPU and NVMe applications, including HMM and DMABUF topics
- RDMA and DAX (carry over from LSF/MM)
- Final pieces to complete the container work
- Contiguous system memory allocations for userspace (unresolved from 2017)
- Shared protection domains and memory registrations
- NVMe offload
- Integration of HMM and ODP
And several new developing areas of interest:
- Multi-vendor virtualized 'virtio' RDMA
- Non-standard driver features and their impact on the design of the subsystem
- Encrypted RDMA traffic
- Rework and simplification of the driver API
Leon Romanovsky <email@example.com>, Jason Gunthorpe <firstname.lastname@example.org>
The Linux Plumbers 2019 Scheduler Microconference is meant to cover any scheduler topics other than real-time scheduling.
- Load Balancer Rework - prototype
- Idle Balance optimizations
- Flattening the group scheduling hierarchy
- Core scheduling
- Proxy Execution for CFS
- Improving scheduling latency with SCHED_IDLE task
- Scheduler tunables - Mobile vs Server
- Remove the tick (NO_HZ and NO_HZ_FULL)
- Linux Integrated System Analysis (LISA) for scheduler verification
We plan to continue the discussions that started at OSPM in May 2019 and get a wider audience outside of the core scheduler developers at LPC.
Juri Lelli <email@example.com>, Vincent Guittot <firstname.lastname@example.org>, Daniel Bristot de Oliveira <email@example.com>, Subhra Mazumdar <firstname.lastname@example.org>, and Dhaval Giani <email@example.com>
The PCI interconnect specification and the devices implementing it are incorporating more and more features aimed at high performance systems (eg RDMA, peer-to-peer, CCIX, PCI ATS (Address Translation Service)/PRI(Page Request Interface), enabling Shared Virtual Addressing (SVA) between devices and CPUs), that require the kernel to coordinate the PCI devices, the IOMMUs they are connected to and the VFIO layer used to managed them (for userspace access and device passthrough) with related kernel interfaces that have to be designed in-sync for all three subsystems.
The kernel code that enables these new system features requires coordination between VFIO/IOMMU/PCI subsystems, so that kernel interfaces and userspace APIs can be designed in a clean way.
Following up the successful LPC 2017 VFIO/IOMMU/PCI microconference, the Linux Plumbers 2019 VFIO/IOMMU/PCI track will therefore focus on promoting discussions on the current kernel patches aimed at VFIO/IOMMU/PCI subsystems with specific sessions targeting discussion for kernel patches that enable technology (eg device/sub-device assignment, peer-to-peer PCI, IOMMU enhancements) requiring the three subsystems coordination; the microconference will also cover VFIO/IOMMU/PCI subsystem specific tracks to debate patches status for the respective subsystems plumbing.
Tentative topics for discussion:
- Shared Virtual Addressing (SVA) interface
- SRIOV/PASID integration
- Device assignment/sub-assignment
- IOMMU drivers SVA interface consolidation
- IOMMUs virtualization
- IOMMU-API enhancements for mediated devices/SVA
- Possible IOMMU core changes (like splitting up iommu_ops, better integration with device-driver core)
- DMA-API layer interactions and how to get towards generic dma-ops for IOMMU drivers
- Resources claiming/assignment consolidation
- PCI error management
- PCI endpoint subsystem
- prefetchable vs non-prefetchable BAR address mappings (cacheability)
- Kernel NoSnoop TLP attribute handling
- CCIX and accelerators management
Bjorn Helgaas <firstname.lastname@example.org>, Lorenzo Pieralisi <email@example.com>, Joerg Roedel <firstname.lastname@example.org>, and Alex Williamson <email@example.com>
Building on the Treble and Generic System Image work, Android is
further pushing the boundaries of upgradibility and modularization with
a fairly ambitious goal: Generic Kernel Image (GKI). With GKI, Android
enablement by silicon vendors would become independent of the Linux
kernel running on a device. As such, kernels could easily be upgraded
without requiring any rework of the initial hardware porting efforts.
Accomplishing this requires several important changes and some of the
major topics of this year's Android MC at LPC will cover the work
involved. The Android MC will also cover other topics that had been the
subject of ongoing conversations in past MCs such as: memory, graphics,
storage and virtualization.
Proposed topics include:
- Generic Kernel Image
- ABI Testing Tools
- Android usage of memory pressure signals in userspace low memory killer
- Testing: general issues, frameworks, devices, power, performance, etc.
- DRM/KMS for Android, adoption and upstreaming dmabuf heaps upstreaming
- dmabuf cache managment optimizations
- kernel graphics buffer (dmabuf based)
- uid stats
- vma naming
- vitualization/virtio devices (camera/drm)
- libcamera unification
These talks build on the continuation of the work done last year as reported on the Android MC 2018 Progress report. Specifically:
- Symbol namespaces have gone ahead
- There is continued work on using memory pressure signals for uerspace low memory killing
- Userfs checkpointing has gone ahead with an Android-specific solution
- The work continues on common graphics infrastructure
Karim Yaghmour <firstname.lastname@example.org>, Todd Kjos <email@example.com>, Sandeep Patil <firstname.lastname@example.org>, and John Stultz <email@example.com>
The focus of this MC will be on power-management and thermal-control frameworks, task scheduling in relation to power/energy optimizations and thermal control, platform power-management mechanisms, and thermal-control methods. The goal is to facilitate cross-framework and cross-platform discussions that can help improve power and energy-awareness and thermal control in Linux.
- CPU idle-time management improvements
- Device power management based on platform firmware
- DVFS in Linux
- Energy-aware and thermal-aware scheduling
- Consumer-producer workloads, power distribution
- Thermal-control methods
- Thermal-control frameworks
Rafael J. Wysocki (firstname.lastname@example.org) and Eduardo Valentin (email@example.com)
The security of computer systems is a very important topic for many years. It has been taken into the account in the OSes and applications for a long time. However, security of the firmware and boot process has not been taken so seriously until recently. Now that is changing. Firmware is more often being designed with security in mind. Boot processes are also evolving. There are many security solutions available there and even some that are now becoming common. However, they are often not complete solutions and solve problems only partially. So, it is good time to integrate various approaches and build full top-down solutions. There is a lot happening in that area right now. New projects arise, e.g. TrenchBoot, and they meet various design, implementation, validation, etc. obstacles. The goal of this microconference is to foster a discussion of the various approaches and hammer out, if possible, the best solutions for the future. Perfect sessions should discuss various designs and/or the issues and limitations of the available security technologies and solutions that were encountered during the development process. Below is the list of topics that would be nice to cover. This is not exhaustive and can be extended if needed.
- SRTM and DRTM
- Intel TXT
- AMD SKINIT
- UEFI secure boot
- Intel SGX
- boot loaders
Daniel Kiper <firstname.lastname@example.org>, Joel Stanley <email@example.com>, and Matthew Garrett <firstname.lastname@example.org>