Linux Microscope collects eBPF tools, programs, docs and a visualisation project

A collection of four subprojects rather than one tool

Linux Microscope, usually shortened to LMP, does not ship a program you install. It is an umbrella project, and the value of reading it as a single repository is that it shows the shape the community wants eBPF tooling to take.

The stated goals are three: to serve eBPF beginners and enthusiasts with learning material and program examples while building a learning community, to become a gathering point for eBPF tools on the belief that every beginner has unlimited creativity, and to incubate eBPF ideas, tools and projects. The project description also notes the community activity behind it, with participation in open source summer programmes and a CCF summer camp between June and October 2022 across 13 topics.

The repository is organised to match. The top level holds `.github/`, a `CODEOWNERS` file, a `LICENSE`, a `.gitmodules` file, and directories for the subprojects: `eBPF_Supermarket/`, `eBPF_Hub/`, `eBPF_Visualization/` and `eBPF_Documentation/`, alongside `MagicEyes/`, `OSPP/` and a `lib/` directory. The default branch is `develop`, which tells you something about how the project expects changes to land. The licence is Apache-2.0, and the primary language recorded for the repository is C, which reflects the eBPF programs rather than the documentation.

The Supermarket is the part that runs today

The eBPF Supermarket is the subproject described as mature, directly runnable and open to questions and code. It is a catalogue of eBPF related tools, and the count given in the project description is 17 at present.

What makes the catalogue worth reading is that the project states its own selection policy rather than pretending to be comprehensive. The purpose of a tool is not a mandatory requirement, so a submission does not have to fill an obvious gap, and the ask on contributors is that a pull request have a relatively complete structure and a README so that other people can understand the idea quickly. That is a low bar for what a tool is and a high bar for how it should be presented, and the second is the more unusual choice.

The subject matter follows the eBPF ecosystem rather than a single use case. The repository topics list `bcc` and `bpftrace`, the two toolchains most associated with eBPF work on Linux, which tells you what kind of programs are in scope. Documentation for the subproject lives in its own README inside `eBPF_Supermarket/`, so the details of individual tools are one level down from the top of the repository.

For a newcomer, the Supermarket is the least ambiguous entry point: seventeen tools, each with a README, collected in one place.

eBPF Hub standardises how programs are stored

The eBPF Hub is marked as still under development and open to contributors. Its stated purpose is to collect eBPF related code repositories and to manage eBPF programs in a standardised way, so that a program can be downloaded and run at any time.

That is a different job from the Supermarket. The Supermarket indexes tools, where the tool is the unit and the README describes it. The Hub treats the eBPF program itself as the managed artefact, with a format and a layout that is consistent across the collection. The difference matters to a user: a tool index helps you find something to install, while a standardised program library is what you would pull from when you want to run a known program on your own machine without first reverse engineering how its author laid it out.

The project description gives no technical detail on that standardisation, only the intention, and points to the README inside `eBPF_Hub/` for more. Anyone planning to depend on the layout as a contract should read that file rather than infer it from the top level, because the top level says the subproject is still being built.

The two subprojects are also at different stages on purpose. A tool collection can be useful while it is still growing, whereas a standardised format is only useful once the format has stopped moving.

Visualization is a web console that is not usable yet

The eBPF Visualization subproject is the clearest case of a piece of the plan that has not arrived. The project description marks it as in development and not yet usable, and invites people to build it together.

What it is meant to be is a web management system built for managing eBPF programs, with a focus on eBPF data visualisation and kernel visualisation. Two project goals are listed: managing eBPF components, and displaying Linux system performance data in real time, quickly and conveniently.

Read those two goals against the current state and the shape of the intended tool becomes clear. It is not a metrics scraper that writes to a database and you query later. It is a console that holds eBPF components in some managed way and then shows what the kernel is doing while it happens, which is why the focus sits on kernel visualisation rather than on historical analysis.

The honest assessment is that this is the subproject to watch rather than the one to plan around. Nothing in the project description documents a working release, and the top level has no GitHub releases to point at. If a web console for eBPF is on your critical path, the description itself says this is not it yet, and the entry to look at is the README inside `eBPF_Visualization/`.

The documentation project is a translation and curation effort

The documentation subproject is described as rich and still accumulating, and it is where most of the repository's text lives. Its stated purpose is to hold eBPF and LMP related documentation and to give people a learning path.

The planned categories are five: introductory eBPF material, an eBPF learning checklist, detailed eBPF study material, eBPF programming techniques, and the documentation for LMP's own subprojects, covering description, deployment and development. The categories that exist today are three: LMP's own project documentation, translations of foreign eBPF literature with classic papers collected and translated for reference, and other eBPF documents.

The translation component is the distinctive part, and it is aimed squarely at readers who read Chinese. The project asks for contributions and for corrections to existing documents, and it names a specific gap: the maintainers have years of accumulated Linux kernel material that is rich but in need of being organised. The call for help is directed at anyone willing to help tidy and translate it.

For an engineer who reads Chinese and wants a single entry point into eBPF, this is the practical value of the repository. For a reader who does not, the LMP project documentation and the Supermarket tools still stand on their own.

Where LMP is the wrong place to look

The main mismatch is expecting a tool. Nothing in the repository is an application you install and depend on. It is a catalogue, a format proposal under construction, a web console that the description says is not usable yet, and a documentation collection. If you are looking for something to add to a build, or a library to import, you will not find it here, and the Supermarket is where you would look instead, as a list of things other people wrote.

The second mismatch is language. The descriptions and documentation are written in Chinese, and while the material includes translations of foreign eBPF papers, the guidance on the subprojects themselves is not offered in English. An international team will get the most out of the tool catalogue and the least out of the learning path.

The third is release discipline. The repository has no GitHub releases, and the default branch is `develop` rather than `main`. That is normal for an actively worked-on collection, and it means you should pin a commit rather than track a tag, and read the subproject README before you rely on a directory layout.

The project also spans additional directories at the top level, `MagicEyes/` and `OSPP/`, alongside a `lib/` folder, which suggests the scope is broader than the four subprojects the description enumerates. That is worth a look before you decide where the boundary is.

Editorial conclusion

LMP fits an eBPF beginner looking for runnable tools, Chinese-language learning material and translated papers in one place, and it fits a developer who wants to contribute a tool to a curated collection with a defined submission bar. It does not fit someone looking for a production-ready visualisation console, since the eBPF Visualization subproject is marked as under development and not yet usable, and it does not fit a team that needs tagged releases, because the repository has no GitHub releases and work happens on the develop branch. Check three things first: whether the tool you want is in the 17 already collected in the Supermarket, that the subproject you pick actually has a README you can act on, and where the code sits, since the last push was on 2026-10-15 while the newest public documentation site lives at the project homepage.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. linuxkerneltravel/lmp on GitHub
4. Project website
5. README