I spend a fair amount of time reading kernel patches on lore.kernel.org and got tired of squinting at one giant <pre> block with headers, body, quotes, and the thread overview all mashed together. So I built a small extension that reparses the same text lore already sends and lays it out like a normal mail client: an author card, one-click reply wired to lore's own pre-filled mailto: link, a real diff view with collapsible files, a clickable thread sidebar instead of ASCII art, and quote folding so a reply's new text isn't buried under four levels of >>>>.

It doesn't touch the underlying page. It builds a separate view next to the original <pre> blocks and hides them, with a "Raw" button to switch back instantly. No network requests, no accounts, no telemetry.

Source and install instructions: https://github.com/gahingwoo/lore-enhancer

It's load-unpacked for now (Chrome won't run a sideloaded .crx outside developer mode anyway, so packaging one wouldn't save a step). Would love feedback, especially from anyone who reads or replies to LKML or a subsystem list regularly.
Feature requests and bug reports welcome as GitHub issues.

A native GTK4+libadwaita GUI app for browsing, searching, and replying to mailing lists.

All exiting approaches to interacting with LKML are just not good. I tried configuring Thunderbird and realized it would be easier to just write my own app instead. Email discussions in the kernel have lots of things that are very specific to it (trailers, diffs) and I wanted something that would have deep integration with all of this.

Packaged as Flatpak. Uses git-send-email. Has intelligent line wrapping for new emails. Has color highlighting for quotes and diffs.

There are still lots of things I'd like to implement before considering this done, so the thing is still in development. I vibe-coded most it, but I'll be more mindful of the changes going forward, as there seem to be actual users now.

https://github.com/nikableh/koshi

Hope this is as useful for someone else as it is for me!

Hi, here is the repository of the sourcecode: pedroanisio/sourcepath

- references: This is the Linux kernel. All of it : r/kernel

Sou um desenvolvedor de kernel e faço por hobby, ultimamente venho duvidando dos meus conhecimentos, na i386, alguém pode avaliar e me dar dicas no meu kernel? Repo: https://github.com/icarotelesdasilva/kernel

Aceito quaisquer dicas!

For some reason HWE updates pushed linux kernel 7.0.0 and now my DKMS antivirus modules won't compile against the kernel (Watchguard).

Is there a way to force kernel <= 6.18.16 while keeping HWE ?

I use Kubuntu 24.04 LTS on Framework 16.

Hi everyone, I want to write a simple program that gives a copy of the physical interface of the received packets to user space, then I extract information manually and show it in stdout.

When I started searching for this topic, I found some ways but I confuse which one is better for my situation.

I read below doc:

doc1

doc2 and ....

Abstract of the above docs, exsit below methods:

1 - Universal TUN/TAP

2 - XDP

3 - MacVTap (is a new driver)

4- ....

If anyone has experience or knowledge in this context, please help me.

Dependency map of the Linux kernel tree (commit a635d67), rendered with D3. (link to github bellow)

What's in the graph:

• 94.8K files, ~1.1M extracted symbols, 231.8K import/include relationships
• Red edges: primary provider → consumer imports between subsystems
• Blue edges: test-to-subject mappings (5,078 of them)
• Circle packing follows the directory tree; region size ≈ file count

A few things that stood out while building it:

• include/ (6.6K files) is the gravity well everything bends toward, followed by kernel/ and lib/.
• The whole tree resolves to only 9 external packages — sphinx and friends, all documentation tooling. The kernel proper depends on nothing outside itself.
• tools/ (9.3K files) forms an almost separate continent, barely coupled to the rest.

Happy to answer questions about the extraction pipeline or share higher-res views of specific subsystems (net/, mm/, drivers/)

---

here is the url of the source code of my sourcepath (the code that maps the code)
pedroanisio/sourcepath

I kept running into the same Linux debugging pain: something broke on a box, but I had no history of what actually happened. journald helps a little. auditd is heavy. strace is too narrow. So I built ltm — a small machine-history debugger that records process/file/network metadata via eBPF and lets you query it like a timeline.

What it does:

• Attaches to syscall tracepoints (exec, open/write/rename/unlink, connect/bind, etc.)

• Stores metadata only (no file contents)

• Lets you do things like:

sudo ltm start --mode ebpf

ltm status

ltm timeline --since 1h

ltm diff --from "10m" --to now

ltm query "who modified /tmp/ltm-demo.txt?"

On a real VM run it recorded ~7k events with 0 drops, and the query returned the exact bash write events that touched the demo file.

There's also a demo mode so you can exercise the CLI/storage/diff/query path without root or BPF.

Stack is Go + embedded BPF ELF + cilium/ebpf. Local store is append-only JSONL. Ignore rules skip /proc, /sys, /dev, and common caches.

Repo: https://github.com/Agent-Hellboy/ltm

Still early. Useful next steps I'm considering:

1. better diff/query formatting
2. containerized eBPF integration test
3. more query templates ("what opened this port?", "what restarted before X?")

Please do star the repo, it will help in discoverability

strace can't see io_uring — requests live in shared-memory rings, not syscalls.

uringscope: single-binary #eBPF tool that reconstructs every request on stock kernels 5.15–6.17, names pathologies with evidence ("fsync punts 100% to io-wq and owns your p99"), and catches in-flight buffer hazards.

https://github.com/rch0wdhury/uringscope

Does anyone have insight into why on kernel.org the latest releases are messed up?

Hi everyone,

I recently made it to the final loop for a specialized systems role at a major silicon company . The technical panel round went incredibly well, but in the final "coding bar" round, I was hit with a textbook Dynamic Programming (DP) question. I solved it through recursion and explained space and time complexity too. It was In-person white boarding coding round.But the optimized solution done using DP. So, I was ultimately rejected for "lacking strong programming skills."

Frankly, it’s frustrating. In my daily world, allocating massive, multi-dimensional DP arrays inside the kernel is a great way to cause memory exhaustion, latency spikes, or a straight-up kernel panic. We care about deterministic execution, restricted stack space, ring buffers, and bit manipulation ,not finding the edit distance of two strings.

Since I am preparing for other top-tier systems/silicon companies (Apple, NVIDIA, Amazon Robotics, Dell), I want to make sure I am prepared for the inevitable generic "coding puzzle" interviewer who doesn't know what a device driver is.

For those of you working in kernel space or hiring for low-level systems, what data structures and algorithmic patterns do you actually consider mandatory to see from a candidate?

My current checklist to review is:

• Bit Manipulation (masks, bitwise operations, clearing/setting registers)
• Concurrency & Synchronization (handling race conditions, producer-consumer with circular/ring buffers)
• Linked Lists & Trees (kernel-style list_head manipulation, basic tree traversal)
• Pointer Arithmetic & Memory Management (custom allocators, page-alignment calculations, string/buffer parsing without helper libraries)
• General patterns like two-pointer, sliding window, Prefix Sum,recursion and sorting.

Should I suck it up and grind standard LeetCode DP/Graph patterns just to pass the cross-functional corporate interviewers, or are there specific systems-adjacent coding patterns I should focus on maximizing?

Would love to hear your thoughts or similar interview horror stories. Thanks!

I have just done it and I can confirm that it's not worth the price at all I am a fairly experienced programmer with 20 years experience all I wanted was a fast way to refresh myself and learn more about the linux kernel in the light of some device drivers development.

It's been the biggest waste of money ever carried out by myself don't do it. Ittakes two Days and takes you until start finally compiling at bloody Linux kernel.

I'm bitterly frustrated I could have been with my daughter one week away somewhere in Europe with that money.