Raghu Bharadwaj

Posted on Aug 6 • Originally published at techveda.live

Kernel & Embedded News: AI-Written Patch Rules; AMD Ryzen X100

#linux #kernel #embedded #ai

This edition tracks how Linux is governed, scheduled, and where its AI now runs. The kernel documentation tree carries new guidelines for tool-generated content, which set expectations for AI-assisted patches. The sched_ext framework is close to supporting a hierarchy of sub-schedulers together with proxy execution. And two moves push inference outward: AMD's Ryzen AI Embedded X100 folds CPU, GPU, and NPU behind one memory space for robots, while Google's LiteRT.js runs on-device models straight in the browser.

The threads this edition are accountability and placement: who is responsible for a machine-generated patch, how a scheduler divides CPU time without losing correctness, and where AI inference runs — on a consolidated robotics SoC, or inside the browser itself. None of these is a finished product on its own, but each shapes how engineering teams will plan work over the next few cycles.

In this edition

The kernel documents its expectations for tool-generated patches. A new Guidelines for Tool-Generated Content page has entered the process documentation, asking contributors to be transparent about tools, including AI, and to defend everything they submit.
sched_ext gains sub-schedulers and proxy execution. Work on enqueue() for sub-schedulers lets a BPF scheduler be attached to a control group, and a long-standing incompatibility with proxy execution is being resolved.
AMD announces the Ryzen AI Embedded X100 for robots. The X100 Series combines up to 16 Zen 5 cores, an integrated GPU, and an NPU on one SoC with unified memory, sampling now with production expected in Q4 2026.
Google's LiteRT.js runs inference in the browser. LiteRT.js executes .tflite models locally through WebGPU, which is relevant to any embedded product whose interface is a web UI.

The kernel now documents how it handles tool-generated patches

The kernel's process documentation has gained a page titled Kernel Guidelines for Tool-Generated Content. It is visible in the current documentation build (7.2.0-rc6), filed under the policy guides and developer statements, next to a separate AI Coding Assistants page. This is guidance, not an enforcement mechanism, and it is deliberately framed around tools in general rather than AI alone.

The scope is drawn carefully. Routine tooling stays out of scope: reformatting with clang-format, rustfmt or Lindent, spelling and grammar fixes, identifier completion, and mechanical changes such as variable renaming. The guidelines apply when a meaningful amount of a contribution was not written by a person in the Signed-off-by chain. The examples named include checkpatch.pl --fix, Coccinelle scripts, a chatbot-generated function, a C file first produced by a coding assistant and then cleaned up by hand, and a changelog written by a generative model.

The core requirement is transparency and accountability. Contributors are asked to state, in the cover letter or changelog, which tools were used, the input given to them, a summary of prompts for longer sessions, which parts of the change were affected, and how the result was tested. The document rests on the existing Developer Certificate of Origin and states the expectation plainly: you must understand and be able to defend everything you submit, and if you cannot, you should not send it. Maintainers keep full discretion, from treating a patch normally to rejecting a machine-generated series without detailed review.

This lands against a sharper backdrop. In a mid-July mailing-list message, Linus Torvalds said the kernel is not an anti-AI project and that contributors who object to others using AI can fork the tree or step away. Separately, in the earlier discussions around AI tagging policy, he observed that a mandatory tagging rule mainly constrains people who already follow rules, while bad actors will not self-identify. Both points are worth keeping in view when reading the guidelines, and both are drawn from secondary coverage rather than primary posts.

For teams, the practical change is to your submission checklist, not your build. If your group already uses Coccinelle, checkpatch.pl --fix or a coding assistant, add a short provenance note to the changelog now, before a maintainer asks. The heavier point is cultural: the burden of understanding a patch stays with the human who signs it, so treat generated code as a draft to be reviewed line by line, not as output to be forwarded. That is the same standard good reviewers already applied; the value here is that it is written down and can be pointed to.

What it means for kernel contributors

If you send patches upstream, fold this into your workflow now. When a tool produced a meaningful part of a change, say so in the changelog or cover letter: name the tool, give the input, and describe what you did with the output. This page mandates no specific tag — plain, honest prose satisfies it — but where AI was involved, pair that prose with the Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] tag the AI Coding Assistants page recommends, and remember that the same page says an AI agent must never add a Signed-off-by tag: only the human submitter can certify the DCO. For example, in a changelog:

This conversion was produced with the Coccinelle script below, then
reviewed and adjusted by hand. Tested with the rcutorture selftests.

  @@ expression E; @@
  - kfree(E);
  + kfree_sensitive(E);

The reviewer can then judge the change with the right context, and you have met the transparency the document expects.

sched_ext gains sub-schedulers and proxy execution

The extensible scheduler class, sched_ext, lets a custom CPU scheduler be loaded as a set of BPF programs. Recent work, described by Jonathan Corbet, brings the ability to build a hierarchy of sub-schedulers close to completion, and ends a long-standing incompatibility with proxy execution.

A sub-scheduler associates a sched_ext scheduler with a control group, so every process in that group is managed by the attached scheduler. A capability mechanism lets a parent share part of its access downward: a newly attached sub-scheduler starts with access to no CPUs, and its parent then grants it a specific set. The design work in the enqueue() path is about keeping control groups isolated from one another while avoiding needless calls up through the hierarchy, which would otherwise cost performance.

Proxy execution is the other half. It addresses priority inversion by letting a task that holds a lock run on behalf of a higher-priority task that is waiting for it. Making that cooperate with sched_ext matters for realtime and latency-sensitive workloads, which are common in embedded and industrial systems, because a scheduler that cannot handle priority inheritance correctly will produce latency spikes that are hard to diagnose.

Custom schedulers are attractive when a general-purpose policy leaves performance on a mixed workload, where latency-critical and throughput tasks share the same cores. The trade-off is that you now own a scheduler, and BPF scheduling is a skill your team either has or has to build. Sub-scheduler support makes the model more practical for multi-tenant and container hosts, where per-group policies are exactly what you want.

How to try it

You can experiment with sched_ext on a mainline kernel today. Build a kernel with the extensible scheduler class and BPF support enabled:

CONFIG_SCHED_CLASS_EXT=y
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_JIT=y
CONFIG_DEBUG_INFO_BTF=y

Then build and load one of the in-tree example schedulers:

raghu@techveda.org:~$ make -j -C tools/sched_ext
raghu@techveda.org:~$ sudo ./tools/sched_ext/build/bin/scx_simple

With the scheduler running, /sys/kernel/sched_ext/state reports that a BPF scheduler is active; stop the binary and the kernel reverts to its default scheduler. The scx_simple example runs a global weighted virtual-time policy, and the sched-ext/scx project carries fuller schedulers to read and adapt. Trying a sample scheduler first is the cheapest way to decide whether a custom policy is worth owning.

AMD's Ryzen AI Embedded X100 targets robots and the industrial edge

AMD used its Advancing AI 2026 event to announce the Ryzen AI Embedded X100 Series, a family of embedded processors aimed at what it calls physical AI: robotics, industrial automation, healthcare, and aerospace and defense. Each part combines up to 16 Zen 5 CPU cores, a discrete-class integrated GPU, and an NPU on a single SoC, tied together by a unified memory architecture that AMD says improves determinism and lowers latency. AMD has not published a maximum memory capacity for the series; its own benchmark configurations used 64 GB and 128 GB of LPDDR5x, so treat exact capacity as unconfirmed until the system-on-module partners publish real specifications. The parts are rated for industrial use, with a -40 to 105 C operating range and 24/7 operation for up to ten years.

The number worth attention is not the TOPS rating; it is the unified memory architecture. A typical robot today spreads its compute across a control board, a separate GPU, and an inference accelerator, and moving data between them costs latency and predictability. Placing the CPU, GPU, and NPU behind one memory space removes those cross-device copies, which is what a real-time control loop actually needs.

That raises the harder question for anyone building on it: real-time behavior. A robot has to run deterministic control alongside AI inference, and doing that on an x86 Linux SoC is a systems problem, not a benchmark. AMD's answer is to pair Linux with the Xen hypervisor for mixed-criticality partitioning, so a real-time control domain can run beside the AI and GPU workloads. Teams still have to decide where PREEMPT_RT, CPU isolation, and partitioning fit, because the chip does not remove latency on its own.

The software stack is the other decision. AMD is pushing an open stack — Linux, the ROCm stack for the integrated GPU, and frameworks such as PyTorch and ONNX — with tools to migrate CUDA code to ROCm. That answers NVIDIA's Jetson line and its CUDA ecosystem, but the real test is whether ROCm runs cleanly on this embedded part under the exact kernel you ship, worth confirming on real hardware rather than a reference image.

Two caveats keep this in proportion. AMD's headline comparisons, such as up to 2.1 times the multi-threaded CPU performance of an Intel Core Ultra Series 3 part, are its own projections measured on a proxy processor configured to represent the top X100 model, not independent numbers on final silicon. And the series is not shipping yet: sampling began in June 2026, with production expected in the fourth quarter through system-on-module partners. It is a platform to evaluate now and design around later, not one to build a shipping product on today.

What it means for engineering teams

Even before silicon ships, there is work to scope, and the early decisions are about the software platform. If you are evaluating the X100 for a real-time product, decide whether you run a PREEMPT_RT kernel or partition the machine with a hypervisor, and how you isolate the control cores from the AI and GPU load — the usual levers are boot parameters such as isolcpus and nohz_full plus IRQ affinity. Confirm early that the ROCm stack and its kernel driver build and load against the kernel you intend to ship, not just AMD's reference image. An x86 embedded SoC also moves a team used to Arm device trees toward ACPI-based enumeration, a real BSP and skills consideration to plan for and budget.

Google's LiteRT.js pushes inference into the browser

Google has released LiteRT.js, a JavaScript build of its LiteRT on-device runtime, the runtime formerly known as TensorFlow Lite, that runs .tflite models directly in the browser. It brings the LiteRT C++ runtime to the web through WebAssembly, using XNNPACK on the CPU, ML Drift over WebGPU for the GPU, and an experimental WebNN path for neural accelerators. Google reports up to three times the performance of previous web runtimes on vision and audio models, and much larger gains over its own CPU path when WebGPU is available.

For an embedded audience this matters wherever the product's interface is a browser: kiosks, industrial HMIs, medical and retail front ends, and any device that already ships a web UI. Running inference locally in that interface removes the round trip to a server, which means lower latency, no per-inference cloud cost, and data that stays on the device.

The trade-off is the sandbox. WebGPU gives the browser real GPU compute, but through a portable abstraction, not the native driver and delegate control you get from LiteRT on the device itself. Memory is bounded by the browser, the NPU path through WebNN is still experimental and limited to some browsers, and you give up the deterministic, hardware-specific tuning a native runtime allows. What you gain is portability: one build runs across whatever GPU the host exposes, with no per-target driver work.

The practical read is that browser inference is now fast enough to be a real option for on-device features in an embedded web UI, not only a demonstration. Where you need full control of the accelerator and predictable latency, the native runtime remains the right tool; where portability and privacy matter more, LiteRT.js is worth evaluating. A companion preview, LiteRT-LM.js, extends the idea to language models in the browser.

How to use it

Getting a model running in the browser is a short path. Install the runtime, load the Wasm, then compile a .tflite model against a backend:

raghu@techveda.org:~$ npm install @litertjs/core

import {loadLiteRt, loadAndCompile, Tensor} from '@litertjs/core';

await loadLiteRt('https://cdn.jsdelivr.net/npm/@litertjs/core/wasm/');
const model = await loadAndCompile('/models/vision.tflite', {
  accelerator: 'webgpu',   // 'webgpu' | 'webnn' | 'wasm'
});
const out = await model.run(new Tensor(pixels, [1, 3, 224, 224]));

Operations unsupported on the chosen backend fall back to the CPU automatically, so the same code runs where WebGPU is unavailable. An existing TensorFlow.js pipeline can keep its pre- and post-processing and swap only the model, using the @litertjs/tfjs-interop package. For an embedded HMI, that means one build serves whatever GPU the device's browser exposes.

References

Originally published at techveda.live.

— Raghu Bharadwaj

DEV Community