20-24 September 2021
US/Pacific timezone

Accepted Microconferences

LPC 2021  Microconferences


Containers and Checkpoint/Restore MC

CFP Ends: Aug 15, 2021

The Containers and Checkpoint/Restore Microconference focuses on both userspace and kernel related work. The micro-conference targets the wider container ecosystem ideally with participants from all major container runtimes as well as init system developers.

Contributions to the micro-conference are expected to be problem statements, new use-cases, and feature proposals both in kernel- and userspace.

Suggested Topics:

  • How to best use CAP_CHECKPOINT_RESTORE in CRIU to make it possible to run checkpoint/restore as non-root (with CAP_CHECKPOINT_RESTORE)
  • Extending the idmapped mount feature to unprivileged containers, i.e. agreeing on a sane and safe delegation mechanism with clean semantics.
  • Porting more filesystems to support idmapped mounts.
  • Making it possible for unprivileged containers and unprivileged users in general to install fanotify subtree watches.
  • Discussing and agreeing on a concept of delegated mounts, i.e. the ability for a privileged process to create a mount context that can be handed of to a lesser privileged process which it can interact with safely.
  • Fixing outstanding problems in the seccomp notifier to handle syscall preemption cleanly. A patchset for this is already out but we need a more thorough understanding of the problem and its proposed solution.
  • With more container engines and orchestrators supporting checkpoint/restore there has come up the idea to provide an optional interface with which applications can be notified that they are about to be checkpointed. Possible example is a JVM that could do cleanups which do not need to be part of a checkpoint.
  • Discussing an extension of the seccomp API to make it possible to  ideally attach a seccomp filter to a task, i.e. the inverse of the current model instead of caller-based seccomp sandboxing enabling full supervisor-based sandboxing.
  • Integration of the new Landlock LSM into container runtimes.
  • Although checkpoint/restore can handle cgroupv1 correctly the cgroupv2 support is very limited and there is a need to figure out what is still missing to have v2 supported just as good as v1.
  • Isolated user namespaces (each with full 32bit uid/gid range) and easier way for users to create and manage them.
  • Figure out what is missing on the checkpoint/restore level and maybe the container runtime level to support optimal checkpoint/restore integration on the orchestration level. Especially the pod concept of Kubernetes introduces new challenges which have not been part of checkpoint/restore before (containers sharing namespaces for example).

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "Containers and Checkpoint/Restore MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads

  • Stéphane Graber <stgraber@stgraber.org>, Mike Rapoport <mike.rapoport@gmail.com>, Adrian Reber <areber@redhat.com>, and Christian Brauner <christian.brauner@ubuntu.com>

Confidential Computing MC

CFP Ends: Sept 1, 2021

The Confidential Computing microconference focuses on solutions to the development of using the state of the art encyption technologies for live encryption of data, and how to utilize the technologies from AMD (SEV), Intel (TDX),  s390 and ARM Secure Virtualization for secure computation of VMs, containers and more.

Suggested Topics:

For more references, see:

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "Confidential Computing MC" for the "Track". More topics will be added based on CfP for this microconference.

MC lead:

  • Joerg Roedel <joro@8bytes.org>

Scheduler MC

CFP Ends: Aug 31, 2021

The Scheduler microconference focuses on deciding what process gets to run when and for how long. With different topologies and workloads, it is no easy task to give the user the best experience possible.  Schedulers are one of the most discussed topics at the Linux Kernel Mailing List, but many of these topics need further discussion in a conference format.  Indeed, the scheduler microconference is responsible for many topics to make progress.

Suggested Topics:

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "Scheduler MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Dhaval Giani <dhaval.giani@oracle.com>
  • Daniel Bristot de Oliveira <bristot@redhat.com>
  • Chris Hyser <chris.hyser@oracle.com>
  • Juri Lelli <juri.lelli@redhat.com>
  • Vincent Guittot <vincent.guittot@linaro.org>

Performance and Scalability MC

CFP Ends: Aug 31, 2021

The Performance and Scalability microconference focuses on enhancing performance and scalability in both the Linux kernel and userspace projects.  In fact, one of the purposes of this microconference is for developers from different projects to meet and collaborate – not only kernel developers but also researchers doing more experimental work.  After all, for the user to see good performance and scalability, all relevant projects must perform and scale well.

Because performance and scalability are very generic topics, this track is aimed at issues that may not be addressed in other, more specific sessions. The structure will be similar to what was followed in previous years, including topics such as synchronization primitives, bottlenecks in memory management, testing/validation, lockless algorithms and RCU, among others.

Suggested topics:

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "Performance and Scalability MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Davidlohr Bueso <dave.bueso@gmail.com>
  • Daniel Jordan <daniel.m.jordan@oracle.com>
  • Pavel Tatashin <pasha.tatashin@soleen.com>

IoThree's Company MC

CFP Ends: Aug 24, 2021

The IoThree's Company microconference is moving into its third year at Plumbers.  Talks cover everything from the real-time operating systems in wireless microcontrollers, to products and protocols, to Linux kernel and tooling integration, userspace, and then all the way up to backing cloud services. The common ground we all share is an interest in improving the developer experience within the Linux ecosystem.

Suggested topics:

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "IoT's Company MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Christopher Friedt <chris@friedt.co>
  • Jason Kridner  <jkridner@beagleboard.org>
  • Drew Fustini <drew@beagleboard.org>

Tracing MC

CFP Ends: Sept 10, 2021

The Tracing microconference focuses on improvements of the Linux kernel tracing infrastructure. Ways to make it more robust, faster and easier to use. Also focus on the tooling around the tracing infrastructure will be discussed. What interfaces can be used, how to share features between the different toolkits and how to make it easier for users to see what they need from their systems.

Suggested topics:

  • Tracepoints that allow faults. It may be necessary to read user space address, but currently because tracepoints disable preemption, it can not sleep, nor fault. And then there's the possibilities of causing locking issues.

  • Function parameter parsing. Now that on x86 function tracing has full access to the arguments of a function, it is possible to record them as they are being traced. But knowing how to read the parameters may be difficult, because it is necessary to know the prototype of the function to do so. Having some kind of mapping between functions and how to read their parameters would be useful. Using BTF is a likely candidate.

  • Consolidating tracing of return of a function. Currently there's three use cases that hook to the return of a function, and they all do it differently. kretprobes, function graph tracer, and eBPF.

  • User space libraries. Now that libtraceevent, libtracefs, and libtracecmd have been released, what tooling can be built around them. Also, improving the libtraceevent API to be more intuitive.

  • Improving the libtracefs API to handle kprobes and uprobes easier.

  • Python interface. Working on getting the libraries a python interface to allow full tracing from within python scripts.

  • Tracing containers. What would be useful to expose on creating and running containers.

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "Tracing MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Steven Rostedt <rostedt@goodmis.org>
  • Yordan Karadzhov <ykaradzhov@vmware.com>

Tracing MC Summary

  • DTrace based on BPF and tracing facilities: challenges [video][slides]

    • DTrace scripts are compiled into BPF functions. There are pre-compiled functions in C to BPF. BPF is still "Bleeding edge" but production kernels usually prefer "stability" over "bleeding edge". BPF was missing "bounding values" from loading and reading from the stack (but it was stated that this was fixed on 7/13/2021 - v5.14-rc4), but this is still not in production systems. Although it was backported, there are other issues (not specified) that are not.
    • Current solution uses BPF maps, but this has limitations, such as verifier cannot validate anything stored or loaded on the maps, and the values are pointers.
    • Possible suggested solutions:
      • Allow BPF maps to have a larger size

      • Use multiple map values (but is cumbersome)

      • New per-cpu memory resource. Does not need to be visible to user space.

      • Preallocated with bpf_malloc/free helpers.

    • Complex scripts and function loops. Perhaps a BPF helper for loops can be added that is safe to use.

    • No way to currently save pt_regs from tracepoints. But as tracepoints are jumps and not break points they are similar to calling a function. How would one save registers from a function call?

    • Issues with the verifier where GCC/LLVM can produce "verified" code but the fails the kernel verifier.

  • Enabling user mode programs to emit into trace_event / dyn_event [video][slides]

    • Want a way to allow user mode applications to send data to a user mode defined trace event. Currently possible with uprobes, but is hard for C#, Java, etc to be attached to uprobes.

    • Problem: Many processes running in cgroups using different languages (Python, Rust, Go, C/C++, C#, Java), but want a single monitoring agent in the root namespace. There could be multiple tooling to trace (LTTng, uprobes, perf, etc) Need a way to have consistent data across the tools. Do not want daemons or agents running in the container name spaces.

    • Proposed Solution:

      • Have the user applications create / open a "user_events_data" file in tracefs. Get an event_id from this file by passing in an event name via an ioctl(). (Similar to the "inject" file for tracepoints).

      • Use a mmapped page shared between the kernel and user space, where the bits of a byte lets you know what is attached (bit 0-6 for ftrace, perf, etc). Bit 7 reserved for "others". Zero mean nothing in consuming / tracing that event. The user application will check this byte, and if it is set, it will then write the trace event data into a file which will be passed to the connected consumers (the tracers).

      • trace_markers was mentioned, but they do not have all the features that a trace event has (attaching triggers, histograms, synthetic events, etc).

      • Discussion over field argument formats were made.

      • Issues with it being a binary blob. Should be easily parsable.

      • Needs to be accessible from non root. Can change permissions of files in tracefs.

  • Container tracing: [video][slides]

    • First, how do we define a container? As containers are just a bunch of user tasks. Yordan Karadzhov said it is trivial to figure out what tasks are part of a container if you start tracing it during its creation. But finding out what is part of a container after the fact is more difficult. Christian Brauner said most of the time the PID name space defines the container, but that is not always the case. He suggested using a "tagging" method, where one could tag the process creating a container, or adding tasks to a container, and all the children will maintain this "tag". Then to define the container the tag will be used.

    • Mathieu said that LTTng traces by inode numbers. But is missing the "user given" name of the container, and tagging would solve this too.

    • Mathieu also said that we need to be concerned about "nested containers".

    • Masami asked about tracing from within the container, but Steven shot it down due to the fact that once you can see the events of the kernel, you are no longer inside the container. Although, it should be fine for privileged containers.

    • Christian said there's some ways to get by that with eBPF from inside a container.

    • Mathieu suggested having "safe" tracepoints that the container is allowed to use.

    • Yordan asked about other use cases for container tracing, like for security, network activity across nodes, etc, but the conversation still went back to what is a container.

    • Christian mentioned that there is mechanisms in core scheduling that could be used as well.

  • Tracepoints that allow faults [video][slides]

    • Tracing of system calls happen at the start of the system call. If there's a pointer to user space, and that address is not yet mapped in, then it can not be retrieved because tracepoints are protected by preemption disabled and retrieving user space memory requires scheduling.

    • Suggested extending the tracepoint and tracepoint APIs to include callbacks with preemption enabled, but the tracers will need to know this, as they currently expect preemption disabled. Will require updating to use task trace RCU mechanisms.

    • Steven mentioned that the use of synthetic events connecting the entry and exit of a system call to trigger the event on the exit of the system call where the user space addresses would be resolved. Mathieu asked about exec, as the old addresses would be discarded. Although, the exec system call usually doesn't suffer not having the address loaded, as the path is usually loaded as one of the exec system call parameters.

    • Mathieu suggested that we could just have preemption disabled before calling the perf and ftrace tracers.

    • Peter Zijlstra noticed that the rcu task trace sends IPIs to CPUs that are running NO HZ user space tasks, which must be fixed first.

  • LTTng as a fast system call tracer [video][slides]

    • How to get at least part of LTTng into mainline.

    • Need to break it up and find a minimal set for upstreaming. Could look at the systemcall with page faults first.

    • Steven wants more kernel developers to be interested in having LTTng upstreamed, or at least users that are pushing for it. Having a demand is needed, instead of just Steven and Mathieu deciding it.

    • Need a way to pass argument types "user" and "kernel" to the tracers.

    • Masami suggested using ioctl() as they have lots of data structures.

    • Steven suggested using BTF for defining arguments for system calls.

  • Eventfs based upon VFS to reduce memory footprint [video][slides]

    • The tracefs memory footprint is large due to the events directory. Every event system has a directory dentry, as well as an enable and filter file.

    • The events themselves each have their own directory as well as several files to enabled the events and to enable triggers, filters, and to read the event formats. The event directory was measured to be around 9 MB. When an instance is created (for more than one trace buffer) it duplicates the events directory allocating a new 9 MB of memory. There needs to be a way to have just one copy of the meta data, and dynamically create the directories and files as they are referenced. Ideally, this will remove 75% from the 9MB.

    • Ted Tso mentioned that sysfs has the same complaints about the size of the files for the objects and it could use this too.

    • There was a lot of acceptance that this would be good to achieve, not only for the proposed eventfs, but for the other pseudo file systems as well.

  • Function tracing with arguments [video][slides]

    • Currently function tracing only traces the function name (being traced) and the parent. As of 5.11 the function trace (on x86_64) gets access to the registers and stack that is needed to retrieve the parameters for every function by default. Now all that is needed is to implement a way to do so. Needed is the way to know what is needed for the arguments on a function by function basis. BTF currently is in the kernel with that information, but there isn't a fast way to retrieve it (needed at time the functions are being traced).

    • Masami mentioned that BTF describes the arguments for each function but does not describe the registers to retrieve those arguments. That is different on each arch. It was mentioned to record the raw data (just having knowing what regs and stack is needed to save into the trace buffer, then post process the names and parsing at the time of reading the trace.

    • BTF information may be tricky as finding data for modules may be different than for the core kernel. The split BTF base for modules is may not be global unique.

  • Merging the return caller infrastructures [video][slides]

    • There are currently three subsystems that do tricks to add a callback to the return of a function: kretprobes, function graph tracer, and BPF direct trampolines. Kretprobes and function graph tracer "hijack" the return pointer and insert a return to a trampoline that does the callback and then returns to the original return address that was saved on a shadow stack. BPF has the trampoline call the function being traced and simply has the return side on the trampoline do the callback and return normally itself. But this has issues if there are parameters on the stack, as those need to be copied again when calling the traced function.

    • Peter stated that having one infrastructure would be helpful for the CFI "shadow stack" verification code.

    • Steven stated that function_graph tracer is simplest because it is fixed in what it does (record return and timestamp). The kretprobe calls generic code that may expect more (need to know more about the state of the system at the return, regs, etc).

    • Masami wants to make a single "shadow stack" that both function graph tracer and kretprobes can use. Having multiple users of the shadow stack can probably work the same way tail calls work. The first caller "hijacks" the return address and places the address of its return trampoline on the stack, then when the next user of the shadow stack does its replacement, it will "hijack" the stack in the same location and save the return to the previous return trampoline onto the shadow stack and replace it on the main stack with the address of its return trampoline. When its return trampoline is called, it will put back the return to the previous trampoline and call that.

    • Masami mentioned that the kretprobes can be updated to use a generic shadow stack, as it currently uses a shadow stack per probe. Peter said that he had coded to do that somewhere, but doesn't think it went anywhere. Need to investigate that further. Steve said that he would rip out the logic of the function graph tracer's shadow stack and work on making a generic. On x86, Peter said that task stacks are now 16K each. Steven thinks that 4K for the shadow stack should work. But work needs to make sure that if there's no room on the stack, the tracer needs to test if it gets the stack and be able to safely fail if there's no room left on the stack.

    • BPF can't do it generically, because it only saves the necessary args per function.


Toolchains and Kernel MC

CFP Ends: Aug 14, 2021

The Toolchains and Kernel microconference focuses on topics of interest related to building the Linux kernel. The goal is to get kernel developers and toolchain developers together to discuss outstanding or upcoming issues, feature requests, and further collaboration.

Suggested topics:

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "Toolchains and Kernel MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Jose E. Marchesi <jose.marchesi@oracle.com>
  • Nick Desaulniers <ndesaulniers@google.com>

Real-time MC

CFP Ends: Sept 10, 2021

The Real-time microconference focuses on finishing the last lap of getting the PREEMPT_RT patch set into mainline. Many of these missing pieces, however, are not at the core of real-time features (like locking, and scheduling), but instead, on other subsystems that compose the kernel, like file systems and memory management. Making this Linux subsystems compatible with PREEMPT_RT requires finding a solution that is acceptable by subsystem maintainer, without having these subsystems suffer from performance or complexity issues.

Suggested topics:

  • New tools for PREEMPT_RT analysis.
  • How do we teach the rest of the kernel developers how not to break PREEMPT_RT?
  • Stable maintainers tools discussion & improvements.
  • The usage of PREEMPT_RT on safety-critical systems: what do we need to do?
  • Make NAPI and the kernel-rt working better together.
  • Migrate disable and the problems that they cause on rt tasks.
  • It is time to discuss the "BKL"-like style of our preempt/bh/irq_disable() synchronization functions.
  • How do we close the documentation gap
  • The status of the merge, and how can we resolve the last issues that block the merge.
  • Invite the developers of the areas where patches are still under discussion to help to find an agreement.
  • How can we improve the testing of the -rt, to follow the problems raised as Linus tree advances?
  • What’s next?

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "Real-time MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Daniel Bristot de Oliveira <bristot@redhat.com>
  • Clark Williams <williams@redhat.com>
  • Steven Rostedt <rostedt@goodmis.org>
  • Dhaval Giani <dhaval.giani@oracle.com>
  • Kate Stewart <stewart@linux.com>

Testing and Fuzzing MC

CFP Ends: Sept 10, 2021

The Testing and Fuzzing microconference focuses on advancing the current state of testing of the Linux kernel. We aim to create connections between folks working on similar projects, and help individual projects make progress.

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

Suggested topics:

  • KernelCI: Extending coverage and improving user experience.
  • Growing KCIDB, integrating more sources.
  • Better sanitizers: KFENCE, improving KCSAN.
  • Using Clang for better testing coverage: Now that the kernel fully supports building with clang, how can all that work be leveraged into using clang's features?
  • How to spread KUnit throughout the kernel?
  • Testing in-kernel Rust code.

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "Testing and Fuzzing MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Sasha Levin <sashal@kernel.org>
  • Guillaume Tucker <guillaume.tucker@collabora.com>

File System MC

CFP Ends: Sept 15, 2021

The File system microconference focuses on a variety of file system related topics in the Linux ecosystem. Interesting topics about enabling new features in the file system ecosystem as a whole, interface improvements, interesting work being done, really anything related to file systems and their use in general. Often times file system people create interfaces that are slow to be used, or get used in new and interesting ways that we did not think about initially. Having these discussions with the larger community will help us work towards more complete solutions and happier developers and users overall.

Suggested topics:

  • DAX - are we finally ready for prime time?
  • Optimizing for cloud block devices. How do we deal with unstable transport? Do we need to rethink our IO path?
  • Atomic writes, and FIEXCHANGE_RANGE
  • Writeback throttling - we have a lot of different solutions, are we happy with the current state of affairs?
  • Page Folios
  • RWF_ENCODED
  • Performance testing

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "File System MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Josef Bacik <josef@toxicpanda.com>
  • Amir Goldstein <amir73il@gmail.com>
  • Ted Ts'o <theodore.tso@gmail.com>
  • Jan Kara <jack@suse.cz>

File System MC Summary

  • Efficient buffered I/O (Page folios) [video]

    • Matthew Wilcox talked about the work that filesystem developers need to do in order to convert disk or network filesystems to use Folios

    • Josef Bacik and Ted Ts’o offered to help with performance testing

    • Covered better by https://lwn.net/Articles/869942/

  • Idmapped mounts [video][slides]

    • Christian Brauner gave a quick overview about the idmapped mounts feature that was merged for v5.12, what they are used for and how they are implemented in the VFS.

    • More background can be found at https://lwn.net/Articles/837566/

    • At the moment, only privileged users (typically systemd or container runtime) are allowed to create idmapped mounts for the use by processes running inside a user namespace

    • In a followup session, Jan Kara talked about Project ids and what their semantics should be w.r.t idmapped mounts use cases

    • The existing project id semantics are quite old, so the community may propose new semantics to meet modern use cases, but first, a proper specification for the new semantics needs to be drafted

  • Atomic file writes [video]

    • Darrick Wong talked about a proposal for implementing filesystem level atomic writes using FIEXCHANGE_RANGE ioctl (https://lwn.net/Articles/851392/)

    • The proposed API is a lot more flexible and predictable than the hardware atomic write capability that is available on some storage arrays, that is very hard to use in portable applications

  • Filesystem shrink [video][slides]

    • Allison Henderson talked about the technical challenges of shrinking the logical size of a filesystem, in cases where thin provisioning is not provided by the underlying block layer.

    • Ted Ts'o explained that the requirement is driven by the fact that Cloud vendors charge customers by the logical size of the provisioned block device and not by the actual Cloud backend storage usage -  if we could get Cloud vendors to change their pricing model, there would probably be no need to shrink filesystem logical size

  • Bad Storage vs. File Systems [video][slides]

    • Ted Ts’o and Darrick Wong talked about lessons learned from running filesystems on top of unreliable Cloud backend storage.

    • Different use cases vary greatly in what is the best thing to do when I/O error occurs when writing data or metadata blocks

    • Josef Bacik held a strong opinion that error handling should be delegated to applications and that it should not be a filesystem decision

    • Ted Ts’o argued that some mechanisms, such as forcing a kernel panic, makes sense to do in the kernel without involving userspace.   Another mechanism to delegate the decision to system administrators might involve using eBPF.

  • Development Roadmaps [video]

    • Darrick Wong talked about some of the XFS work done in 2021 and what is planned for 2022

    • Josef Bacik talked about some of the btrfs work done in 2021 and what is planned for 2022

    • Matthew Wilcox talked about some more plans for improvements of page cache after Folios

    • Josef Bacik, Ted T’so and Darrick Wong talked about their regression test setups and how to better collaborate the regression tracking efforts


VFIO/IOMMU/PCI MC

CFP Ends: Sept 10, 2021

The VFIO/IOMMU/PCI micro-conference focuses on coordination between the PCI devices, the IOMMUs they are connected to and the VFIO layer used to manage them (for userspace access and device passthrough) with related kernel interfaces and userspace APIs to be designed in-sync and in a clean way for all three sub-systems, and on the kernel code that enables these new system features that often require coordination between the VFIO, IOMMU and PCI sub-systems.

Suggested topics:

  • VFIO

    • Write-combine on non-x86 architectures

    • I/O Page Fault (IOPF) for passthrough devices

    • Shared Virtual Addressing (SVA) interface

    • Single-root I/O Virtualization(SRIOV)/Process Address Space ID (PASID) integration

    • PASID in SRIOV virtual functions

    • Device assignment/sub-assignment

  • IOMMU

    • IOMMU virtualization

    • IOMMU drivers SVA interface

    • I/O Address Space ID Allocator (IOASID) and /dev/ioasid userspace API (uAPI) proposal

    • Possible IOMMU core changes (e.g., better integration with device-driver core, etc.)

  • PCI

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "VFIO/IOMMU/PCI MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Alex Williamson <alex.williamson@redhat.com>
  • Bjorn Helgaas <bjorn@helgaas.com>
  • Joerg Roedel <joro@8bytes.org>
  • Krzysztof Wilczyński <kw@linux.com>
  • Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Open Printing MC

CFP Ends: Sept 10, 2021

The Open Printing microconference focuses on improving and modernizing the way we print in Linux.

Suggested topics:

  • Changes in CUPS 2.4.x
    • Print sharing changes for mobile
    • OAauth support to replace Kerberos
    • Printer drivers replaced with Printer Applications
    • TLS/X.509 changes
  • CUPS in containers
    • CUPS 3.0
    • Future CUPS development
    • Identify support platforms
    • Key printing system components
    • Discuss integration with Printer Applications and application stores like Snap Store
  • Print Management GUI
    • Migrating from working with CUPS queues to IPP services
    • Handling legacy devices that do not handle IPP services
  • Common Print Dialog Backends
    • CPDB, CUPS backend.
    • Separating GUI toolkits and the print technology support to be independent from each other.
  • Printer/Scanner Driver Design and Development

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "Open Printing MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Aveek Basu <basu.aveek@gmail.com>
  • Till Kamppeter <till.kamppeter@gmail.com>
  • Michael Sweet <msweet+lpc@msweet.org>
  • Ira McDonald <blueroofmusic@gmail.com>

RISC-V MC

CFP Ends: Sept 10, 2021

The RISC-V microconference focuses on the development of RISC-V.

Suggested topics:

  • Platform specification progress, including SBI-0.3 and the future plans for SBI-0.4. There has been significant progress on the platform specifications, including a server profile, that needs discussion.
  • Privileged specification progress, possible 1.12 (which is a work in progress at the foundation).
  • Support for the V and B specifications, along with questions about the drafts. The V extension is of particular interest, as there are implementation of the draft extensions that are likely to be incompatible with what will eventually be ratified so we need to discuss what exactly user ABI compatibility means.
  • H extension / KVM discussion, which is probably part of the drafts.  The KVM port has been hung up on the H extension ratification process, which is unlikely to proceed any time soon. We should discuss other options for a KVM port that avoid waiting for the H extension.
  • Support for the batch of SOCs currently landing (JH7100, D1)
  • Support for non-coherent systems
  • How to handle compliance.

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "RISC-V MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Palmer Dabbelt <palmer@dabbelt.com>
  • ATISH PATRA <atish.patra@wdc.com>

Kernel Dependability and Assurance MC

CFP Ends: Sept 10, 2021

The Kernel Dependability and Assurance Microconference focuses on infrastructure to be able to assure software quality and that the Linux kernel is dependable in applications that require predictability and trust.

Suggested topics:

  • Identify missing features that will provide assurance in safety critical systems.
  • Which test coverage infrastructures are most effective to provide evidence for kernel quality assurance? How should it be measured?
  • Explore ways to improve testing framework and tests in the kernel with a specific goal to increase traceability and code coverage.
  • Regression Testing for safety: Prioritize configurations and tests critical and important for quality and dependability

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "Kernel Dependability and Assurance MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Shuah Khan <skhan@linuxfoundation.org>
  • Gabriele Paoloni <paoloni.gabriele@gmail.com>

System Boot and Security MC

CFP Ends: Sept 15, 2021

The System Boot and Security microconference focuses on the firmware, bootloaders, system boot and security around the Linux system. It also welcomes discussions around legal and organizational issues that hinder cooperation between companies and organizations to bring together a secure system.

Suggested topics:

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "System Boot and Security MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Daniel Kiper <dkiper@net-space.pl>
  • Piotr Król  <piotr.krol@3mdeb.com>
  • Matthew Garrett <mjg59-plumbers@srcf.ucam.org>

Android MC

CFP Ends: Sept 7, 2021

The Android microconference focuses on cooperation between the Android and Linux communities.

Suggested topics:

  • Alignment issues between Android and Cgroups v2: Issues in refactoring Android's use of cgroups to utilize cgroups v2
  • Thermal: Issues around performance and thermal handling between the kernel and Android's HAL
  • Fuse/device-mapper/other storage: Discuss out-of-tree dm/storage drivers and how they might go upstream or better align with upstream efforts
  • In kernel memory tracking: Tracking/account GPU (and other multi-device shared) memory and how it might fit with cgroups
  • fw_devlink: Remaining fw_devlink issues to resolve, now that its enabled by default.
  • Hermetic builds/Kbuild
  • GKI updates: Whats new this year in GKI and where its going next year
  • Rust in AOSP / Kernel / Binder: How Android is adopting rust for userland and potentially for kernel drivers
  • Android Automotive OS Reference Platform: Details on recent Android Automotive work
  • Community devboard/device Collaboration: Ways to better collaborate on enabling various devboard against AOSP, without needing close interlock with Google

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "Android MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Karim Yaghmour <karim.yaghmour@opersys.com>
  • Todd Kjos  <tkjos@google.com>
  • John Stultz <john.stultz@linaro.org>
  • Amit Pundir  <amit.pundir@linaro.org>
  • Sumit Semwal <sumit.semwal@linaro.org>
  • Sandeep Patil <sspatil@google.com>
  • Ric Wheeler <ricwheeler@fb.com>

GPU/media/AI buffer management and interop MC

CFP Ends: Sept 10, 2021

The GPU/media/AI buffer management and interop microconference focuses on Linux kernel support for new graphics hardware that is coming out in the near future.  Most vendors are also moving to firmware control of job scheduling, additionally complicating the DRM subsystem's model of open user space for all drivers and API. This has been a lively topic with neural-network accelerators in particular, which were accepted into an alternate subsystem to avoid the open-user space requirement, something which was later regretted.

As all of these changes impact both media and neural-network accelerators, this Linux Plumbers Conference microconference allows us to open the discussion past the graphics community and into the wider kernel community. Much of the graphics-specific integration will be discussed at XDC the prior week, but particularly with cgroup integration of memory and job scheduling being a topic, plus the already-complicated integration into the memory-management subsystem, input from core kernel developers would be much appreciated.

Suggested topics:

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "GPU/media/AI buffer management and interop MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Daniel Stone <daniel@fooishbar.org>

Diversity, Equity and Inclusion MC

CFP Ends: Sept 10, 2021

The Diversity, Equity and Inclusion microconference focuses on identifying how we can improve the diversity of new contributors and retain existing developers and maintainers in the kernel community.  As Linux kernel community turns 30 this year, we need to understand what is working and where we can improve (and how).  Experts from the DEI research community will share their perspectives, together with the perspectives from the Linux community members to help determine some next steps.

Suggested topics:

  • What are the challenges in attracting and retaining a diverse group of developers that are worth focusing on.
  • Does the Code of Conduct and Inclusive naming efforts help people of diverse groups feel at home? What else is missing?
  • How effective have the kernel mentoring initiatives been? Are there best practices emerging that help the limited pool of mentors be more effective?
  • What will be the most effective next steps for advancing Diversity, Equity and Inclusion that will improve the trends, and help us scale?

If you are interested in participating in this microconference and have topics to propose, please use the CfP process, and select "Diversity

Equity and Inclusion MC" for the "Track". More topics will be added based on CfP for this microconference.

MC leads:

  • Shuah Khan <shuah@kernel.org>
  • Kate Stewart <stewart@linux.com>