paulmck

This is part of the Kernel Recipes 2025 blog series.

Build a Bridge

The act of communication is building a bridge from your audience to the place you want them to go, and then getting them to trust you enough to walk that bridge.  If you are presenting on Linux-kernel internals, your prior work might give the audience ample reason to trust you.

It does not help to build the bridge starting from where you are.  After all, if the audience already understood what you are trying to tell them, there would be little purpose in giving your technical talk. You must go to them in order to help them come to you.

To make this happen:

1. Don’t Just Tell It Like It Is
2. Know Your Audience
3. Handle Diverse Audiences In Warner-Brothers Style
4. A Picture Is Worth a Thousand Words
5. Involve Your Audience

The following sections cover these points.

Don’t Just Tell It Like It Is

It does not always help to “just tell it like it is”, no matter how popular that slogan was back in the 1960s.  Tell it like it is from whose viewpoint?  Ah, but suppose that you are just describing some aspect of objective reality?  Very well.  To the best of our knowledge, quantum mechanics is an aspect of objective reality.  Suppose a physicist “told quantum mechanics like it is” as follows:

For those of us without a firm grounding in the mathematics underlying Schroedinger’s equation, myself included, this physicist’s complete and accurate presentation would be completely useless.  The physicist would instead need to start with the audience’s understanding and build from there.  For many of us, a more helpful presentation would include analogies and descriptions of experiments instead of advanced mathematics.

At the other extreme, if you were trying to explain a rainbow to someone well-versed in optics, it might be productive to talk about water droplets and refraction.  If you were instead explaining a rainbow to two-year-olds, it would be much better to simply show them a rainbow.  Going even further, explaining a rainbow to a blind person is not necessarily impossible, but it would at the very least require some serious thought and preparation.

Bringing this back to the topic at hand, if you are presenting to an audience having little experience with Linux-kernel internals (a typical Kernel Recipes attendee, for example), you will need to move out of your comfort zone and into that of the audience members.  At least, you will have to do so if you would like your presentation to be of any use to that audience.

Know Your Audience

If you are explaining quantum mechanics, you need to know your audience’s familiarity with physics and mathematics. If you are explaining a rainbow, you need to understand the audience’s familiarity with optics, light, color, and of course whether or not they can see. Similarly, if you are explaining some aspect of the Linux kernel, you need to understand the audience’s familiarity with that aspect of the Linux kernel.

You also need to understand what motivates your audience. Let’s use Linux-kernel RCU as an example, and let’s consider the following audiences:

1. Developers who are interested in working on the RCU implementation itself might be willing to sit through a very detailed presentation of RCU’s internals, or at least that part of RCU’s internals that they expect to work on. A small audience, to be sure, but a very real one.
2. Developers who are using RCU might be willing to sit through a similarly detailed presentation of RCU’s API, common usage errors, and common diagnostics. But it is likely that a much larger fraction of them would be willing to sit through a shorter presentation on RCU semantics and use cases.
3. Systems administrators might be willing to sit through a detailed presentation of RCU’s Kconfig options and kernel-boot parameters, but most would even more likely prefer to rely on the defaults, instead investing their time and effort into other portions of the kernel.
4. People deploying and debugging Linux kernels might be willing to sit through a detailed presentation of RCU failure modes and diagnostics, especially if they had seen large numbers of RCU CPU stall warnings.
5. People new to the Linux kernel might (or might not) be interested in RCU semantics and use cases, but would likely have a much greater need for information on other aspects of Linux-kernel concurrency, to say nothing of the Linux kernel above and beyond concurrency.

Doing a dry run of your talk can be very helpful. This will help you to understand what an audience member understands, and you can then build on this understanding to more quickly and easily communicate to them. A common presenter mistake is to spend months learning about some aspect of the kernel, and then expect to be able to braindump all that information onto your audience during a 45-minute talk. Unless you have carefully made use of their existing knowledge and connected it tightly to the new information that they need, they will quickly exhaust their mental bandwidth and short-term memory. They will then tune out and you will have lost them. Dry runs can also help you avoid another common mistake, namely thinking of a conference talk as a classroom lecture. This is only natural, given the typical long experience as a classroom student. Classroom instruction often includes assigned reading, tests, laboratory sessions, and project assignments, which are not feasible in even a long-format 50-minute conference presentation. In addition, classroom instructors usually have the benefit of a long history of previous offerings of the class in question, which is not the case for the typical conference presentation.

Sometimes it is necessary to split your audience, for example, by presenting a high-level intuitive overview to the full group and diving deeper in small-group discussions in the “hallway track”.

But what if I am presenting on the internals of the RCU implementation to a mixed audience? Then I can at least provide general information and entertainment to those who are not ready to dive into the depths of Linux-kernel RCU, as discussed in the next section.

Handle Diverse Audiences In Warner-Brothers Style

Not all Kernel Recipes audience members will be Linux-kernel novices. Some will be long-time contributors and high-level maintainers. How can you build a bridge from so many different people?

It isn’t easy.

I learned how to do this from Warner Brothers. Back in my early 1960s youth, a small town (like the ones I grew up in) would have one movie theater, and that theater would show one movie.

Movies then as now tended to appeal to different audiences. So the dramas that appealed to the parents might not be so entertaining to the children, and the slapstick comedies that the children loved might not be so appealing to the parents. Just as with Kernel Recipes, there was a diverse audience.

Theaters handled their diverse audiences by running a short cartoon before the feature film. The cartoon was usually from Warner Brothers, though Disney was another popular choice. This cartoon had to appeal to everyone, so that a family member for whom the feature film was not so appealing would at least be entertained by the cartoon. Different parts of the audience would laugh at different points in the cartoon, as jokes aimed at adults were mixed in with hijinx for kids and with pratfalls for all. But use of humor is non-trivial, as described in Use Humor, But Carefully. Fortunately, the Warner Brothers approach does not necessarily require humor.

For example, the approach is to interleave easily understood high-level material with more challenging material. That way, the experts have material of interest to them, but the novices get something they can relate to easily every few slides. David S. Miller’s late-1990s presentations were famous for taking this approach, and are said to be what drew Rusty Russell into the Linux-kernel community.

About forty years after watching his first cartoon at a drive-in movie theater, Paul realized that he needed to apply this method to his technical talks. There always needs to be something that will appeal to all audience members, regardless of their background or level of technical skill on the topic at hand. Paul spent the ensuing 20+ years learning a great and abiding respect for Warner Brothers. They made it look easy.

A Picture Is Worth a Thousand Words

The cliché in this section heading might have started as an early 20th-century marketing campaign, but there is much truth in it. Most people can much more easily absorb information in graphical form than in a “wall of text”. But producing good graphics can be quite challenging, so we often generate slides that are packed with textual bullet points, which is in fact what I have done with this document.

Production of good graphics is an art that I do not claim to have mastered. The work of Edward Tufte can be helpful for quantitative information. For diagrams, the trick is to avoid overflowing the audience members’ visual memories while making use of their visual sense of place, the idea being to ensure that they do not get lost in a sea of boxes. Easy to say!

Involve Your Audience

Your audience will be much more enthusiastic if they feel like they are not just a passive listener, but instead an active participant. There are a number of ways of doing this:

1. Ask them questions. Keep mental track of the answers you get (or ask an audience member to record them). Refer back to those answers, as appropriate, as you touch on related points later in your presentation.
2. Don’t worry too much if no one answers. You will have at least planted the question in their minds, and most will naturally want the answer, which will lead them to listen more actively.
3. Do put some thought into the audience’s understanding of the subject, so that your question is one that they understand, can relate to, and care about.
4. Call for direct audience participation. This can be especially effective if it involves the audience members physically moving.
5. Use a workshop format where the audience works on a problem. But please be advised that this sort of presentation requires careful preparation. Audience members will make many mistakes, and so you will need to be prepared to help them quickly recover from these mistakes. Which usually means that you need to anticipate the vast majority of them.

Recall the old saying: “I hear and I forget, I see and I remember, I do and I understand.” My RCU audiences sometimes remind me of it, for example by saying something like “I understand RCU for about 15 minutes after your presentation and then I forget it.” Perhaps more hands-on workshops would be helpful. Not at all easy to put on, but helpful!