ext4’s full data-journaling mode, data=journal, is deprecated as of Linux 7.3 and is scheduled for removal in January 2028, so products that rely on it for power-loss behaviour now have a fixed migration deadline. This edition also covers a framework, now at its seventeenth revision, that records why a device last rebooted; a series that makes the kernel’s platform-profile interface work without ACPI; the Yocto Project 6.1 release due in early November; the decision to retire the Assisted-by tag; the AI tools now entering kernel maintenance; and the Linux Foundation’s report on 35 years of Linux.
Most of this edition concerns interfaces that embedded products depend on without much notice: a mount option, a reset-cause record, a power-profile setting and a build-system release line. Several of them are still patch series or deprecation notices rather than shipped features, and none has reached a longterm kernel, so the value this week is in planning, not in anything to switch on. The rest concerns how the kernel itself is now being written and reviewed.
In this edition
- ext4 deprecates data=journal. The full data-journaling mode now warns at every mount on 7.3 and will be removed in January 2028. — plan the migration
- A common record of why a device rebooted. The PSCRR framework reaches v17, collecting reset causes from the PMIC, watchdog, bootloader and kernel in one place. — long-term watch
- Platform profiles without ACPI. A series moves the power-profile core out of the ACPI directory so device-tree boards can use the same interface as laptops. — interface to converge on
- Yocto Project 6.1 is due in early November. Blacksail is a six-month release built on Linux 7.2; Wrynose remains the long-term base. — planning signal
- The Assisted-by tag is set to go. Maintainers agreed the AI-attribution tag carries no reliable signal; the human sign-off rule is unchanged. — process signal
- AI tools enter kernel maintenance. LLM-assisted fixes, a backport-validation tool and an automated reviewer show where these tools help today. — evaluate with care
- 35 years of Linux. A Linux Foundation report sets out the kernel’s reach and development pace. — context
ext4 deprecates data=journal
ext4 inherited three data modes from ext3. In data=writeback only metadata is journaled. In data=ordered, the default, only metadata is journaled but file data is forced to disk before the metadata that refers to it is committed. In data=journal, file data itself is written into the journal first and then copied to its final location, so both data and metadata are replayed together after a crash.
That last mode gives ext4’s strongest crash-consistency guarantee, and it is why many embedded products chose it for eMMC and SD storage on devices that lose power without warning. The cost has always been high. Every data block is written twice, and the mode is incompatible with features ext4 has built its performance around over the last decade: the kernel already prints a warning that it disables delayed allocation, dioread_nolock, O_DIRECT and fast commits. The ext4 documentation describes it as the slowest mode except for workloads that read and write the same data at the same time.
On 24 September, ext4 maintainer Theodore Ts’o committed a two-file change marking the mode deprecated, and it shipped in Linux 7.3. The documentation now states that support will be removed in January 2028, and every mount with the option prints a second warning saying so. The commit carries no explanation beyond its subject line; the list of features the mode already disables is the practical context, since it sits outside the code paths the filesystem is developed and tested around.
Two details matter for planning. First, the warning was not backported: the current 7.2, 6.18, 6.12 and 6.6 stable releases do not print it, so a device running a longterm kernel today gets no signal at all. Second, kernel series released before the removal will keep the option for their whole maintenance life, so the deadline applies when a product moves to a kernel released after January 2028, not to the series it ships today. Because product kernels are usually chosen a year or more before release, a product planned for 2028 or later should be designed without the option now.
What it means for products
Find every place the mode can be set, because it is not always visible as a mount flag. It can appear in /etc/fstab, on the kernel command line as rootflags=data=journal for the root filesystem, or as a default mount option stored in the filesystem superblock by tune2fs (journal_data), in which case the image itself carries the setting into every mount. Build-system image recipes and factory provisioning scripts are the usual places such defaults are introduced.
Moving to data=ordered is the normal path, but it shifts responsibility. Under ordered mode, file contents written but not yet synced can be lost or appear stale after a power cut, so applications that store state must use fsync() and atomic rename patterns correctly. Repeat your power-cut test campaign against the new configuration rather than assuming equivalence; that test, not the mount option, is what shows whether the product’s data survives.
A common record of why a device rebooted
When an embedded device resets in the field, the first question in any failure analysis is why, and Linux has no single answer to give. The information is scattered. A watchdog driver may report a previous watchdog reset, over-temperature or power fault through flags such as WDIOF_CARDRESET, WDIOF_OVERHEAT and WDIOF_POWERUNDER. A few reset drivers, such as Microchip’s AT91 reset controller, expose a power_on_reason attribute using fixed strings like “watchdog timeout” and “brown-out reset” from include/linux/power/power_on_reason.h. Everything else sits in PMIC registers, SoC reset-status registers, bootloader variables or pstore, read by vendor-specific code.
The kernel’s own emergency paths have the same gap. When the thermal core or the regulator framework detects a critical over-temperature or under-voltage, it calls hw_protection_trigger(), introduced under that name in Linux 6.15, to shut down or reboot the system. The reason is passed as a free-form string that ends up only in the kernel log, which is usually lost with the reset itself.
The Power State Change Reasons Recording framework, PSCRR, is an attempt to fix this. On 19 October, Faruque Ansari of Qualcomm posted its seventeenth revision. The work began with Oleksij Rempel of Pengutronix, dates back at least to the 6.8 development cycle in early 2024, and is now carried by the two jointly. PSCRR gives each source of reset information — PMIC, watchdog, SoC registers, bootloader, kernel — its own provider, reported side by side under /sys/kernel/pscrr/. It deliberately does not collapse them into a single “winning” cause, because the sources often disagree and the disagreement is itself useful evidence.
The series also adds a software recorder, so that reasons the kernel detects itself — under-voltage, over-temperature, a watchdog pretimeout, a panic, a controlled reboot — are saved before the transition and can be read after the next boot. To make that possible, hw_protection_trigger() is changed to take standardised numeric reasons instead of strings. The storage side is not finished: the device-tree binding a recorder needs to select its non-volatile NVMEM storage has been stuck in review, so v17 contains only the framework, the reason definitions and the sysfs documentation, with the provider drivers to follow. One built-in provider is included, reporting the reset source a bootloader passes in the device tree’s /chosen/reset-source, so the framework is useful without a new binding.
It is the counterpart to the reboot-mode interface we covered in Reboot Modes: A Wrong String Is a Silent Normal Reboot. Reboot mode carries an instruction forward to the bootloader about where to go next; PSCRR carries evidence forward about why the last transition happened. The series has not been merged, and no current longterm kernel will carry it.
What it means for your devices
Today, fleet tooling has to understand every board’s private way of reporting resets, and that cost grows with every product line. Write down now where each of your boards keeps this information — which PMIC register, which SoC status bits, what the watchdog driver reports and what the bootloader preserves — because that inventory is exactly the provider list PSCRR expects. Avoid adding a new product-specific sysfs file for reset causes in the meantime: a common interface is close enough that a private ABI would become a migration cost rather than an asset.
Platform profiles without ACPI
The platform-profile interface lets userspace choose how a machine balances power and performance, using a small set of named modes such as low-power, balanced and performance. Drivers translate the choice into fan curves, thermal limits and power limits. It was added in Linux 5.12 as a single file, /sys/firmware/acpi/platform_profile, so that laptop firmware modes on ThinkPads and similar machines could be selected through one generic interface instead of per-vendor tools; desktop components such as power-profiles-daemon build on it.
Linux 6.14 extended it to multiple drivers on one machine. Each driver now registers its own class device under /sys/class/platform-profile/, and the original ACPI-path file became an aggregate that sets all of them at once. The provider interface itself never needed ACPI, but the core still lives in drivers/acpi/, its Kconfig symbol sits inside the ACPI menu, and it fails to initialise when ACPI is disabled. Device-tree systems, which includes nearly every Arm and RISC-V embedded board, cannot use it.
On 19 October, Daniel Lezcano of Qualcomm posted the second revision of a five-patch series titled “Make platform profiles firmware independent”. It moves the core to drivers/platform/profile/ under a new CONFIG_PLATFORM_PROFILE symbol, and it was build-tested on arm64 with ACPI disabled and boot-tested on x86 with ACPI turned off. The legacy aggregate files become optional through CONFIG_PLATFORM_PROFILE_LEGACY, enabled by default, and are marked deprecated with removal intended after the 2028 LTS kernel once userspace has moved to the class devices. The first patch also fixes a teardown deadlock in the existing code. No new sysfs interface is introduced.
The motivating case is Arm laptops: Lezcano has also posted an RFC that adjusts thermal trip points by profile on a Snapdragon-based ThinkPad. The same interface suits any device-tree board that trades performance for heat or battery life. Rafael Wysocki, Ilpo Järvinen and Mario Limonciello are reviewing the series, and a third revision of the first patch followed on 20 October.
What it means for BSP teams
Many embedded BSPs expose a “power mode” through a vendor sysfs file, a cpufreq governor switch or a custom daemon, and each needs its own userspace support. If this series lands, the standard place for that choice on a device-tree board becomes the platform-profile class device, which existing userspace already understands. When you next touch a board’s power-mode support, design it so the driver can register as a platform-profile provider, and write new userspace against the class devices rather than the legacy ACPI-path file that is now on a deprecation path.
Yocto Project 6.1 is due in early November
The Yocto Project releases a long-term release every two years, in April, with four years of support, and standard releases in between with much shorter support. Scarthgap 5.0 (April 2024) is supported to April 2028, and Wrynose 6.0 (April 2026) to April 2030. Blacksail 6.1 is the first standard release after Wrynose.
According to the project’s release calendar, 6.1.0 is due in the week beginning 2 November 2026, and the 20 October status report lists it as due for release alongside the 6.0.4 point release; development on master has already moved to 6.2. The draft release notes list Linux kernel 7.2, GCC 16.2, glibc 2.44 and LLVM 23.1.1 among more than 300 recipe upgrades, and raise the minimum host Python version to 3.9. Support runs to April 2027, with 6.1.1 scheduled for the week of 30 November. We covered 6.1 reaching feature freeze in our 15 September edition.
The kernel choice deserves attention. Linux 7.2 is an ordinary stable series, not a longterm one, and with 7.3 released on 18 October its upstream maintenance is close to ending. A product built on the release’s 7.2 kernel would therefore move onto an unmaintained kernel series within weeks of the release. The status report also notes that rsync will be updated to version 3.5.1 on both long-term branches as an exception to the usual policy, because the backported security fixes were not reviewable or maintainable.
How to use it
Keep shipping products on Wrynose, whose four-year support window matches a product’s maintenance life. Use 6.1 as an early test target: build your layers against it to find recipe, toolchain and host-tool breakage ahead of the next long-term release, rather than as a base for a product that must be maintained for years. If you do test product images on 6.1, pair it with a longterm kernel from your BSP rather than the release’s default 7.2.
The Assisted-by tag is set to go
Linux 7.0 added the kernel’s first written policy for AI coding tools. Documentation/process/coding-assistants.rst sets two rules: an AI agent must never add a Signed-off-by tag, because only a person can certify the Developer Certificate of Origin, and contributions made with such tools should carry an Assisted-by: tag naming the agent, the model version and any analysis tools used. A separate document, generated-content.rst, sets broader expectations for tool-generated contributions, on the reasoning that reviewer time is the scarce resource.
At the 2026 Maintainers Summit in Prague on 8 October, the room reached consensus that the Assisted-by tag has outlived its purpose. In 7.3, only 1,884 of 18,533 non-merge changesets — about ten percent — carried it, while the real share of LLM-assisted work is believed to be far higher. Many contributors omit the tag and few maintainers check it, so it gives no reliable signal. Dave Airlie estimated that around ninety percent of contributors now use these tools; Linus Torvalds said the requirement may discourage honest disclosure and was willing to drop it; Shuah Khan still found the tag useful but accepted the consensus. Jeff Layton had proposed removing it as early as July, arguing that compliance was inconsistent and that the tag mainly advertised proprietary tools.
What was agreed is narrower than ending disclosure. Model and process details move from the changelog to the patch cover letter, and maintainers still expect to know that a person understood and tested the change. The Signed-off-by rule is not affected: the human submitter still certifies the origin of every patch and takes responsibility for it. No documentation change has been merged yet. It follows the AGENTS.md proposal we reported in the 29 September edition, part of the same effort to adapt the process to automated contributors.
What it means for contribution workflows
Do not build an internal review gate around a tag that is being removed. The parts that remain are the important ones: a person signs off, a person tested the change, and the cover letter can explain how it was produced. If your team contributes upstream, keep an internal record of which tools were used and who verified the result, because that is the information maintainers say they still value.
AI tools enter kernel maintenance
Several developments this month show where AI tools already help with kernel work, and in each case the useful pattern is the same: the tool proposes, and a test or a person decides.
The clearest example came from Linus Torvalds himself. The kernel’s associative-array library, written by David Howells in 2013, is used by the keyrings subsystem to store keys. Nils Ollrogge reported a bug in it with a proposed fix, but Torvalds found the code too hard to follow, so he used LLM tools to split its largest functions into readable pieces and published the result as an assoc-array-fixes tag during the 7.3-rc7 week. Running the restructured code through a user-space test harness confirmed the reported bug and found three more, all present since the library’s first commit.
Separately, a page-cache change Torvalds drafted with an AI coding assistant, which lets small reads proceed without taking a reference on the page-cache folio, was reworked by Kiryl Shutsemau of Meta and showed large gains on ext4, tmpfs and XFS in testing. Both are expected to be proposed for 7.4; neither is in mainline yet.
Two tools were presented at the Linux Plumbers Conference in Prague. Roman Gushchin of Google reported that Sashiko, Google’s automated patch reviewer, has completed more than 191,000 reviews across 99 kernel mailing lists in under a year, and that 463 kernel CVEs this year cite it. Andrea Righi of NVIDIA showed Boro, an Apache-licensed command-line tool written in Rust and inspired by Sashiko, designed around local models with remote back-ends as an option. It reviews patches before they are posted, checks backports to older kernels, and builds, boots and tests patches.
How to evaluate them
For BSP and product-kernel teams, backport checking is the most relevant use, because carrying fixes into an older kernel is where errors are most expensive and least visible. Local-model operation also matters for vendor trees that cannot leave the building. Treat any tool’s output as a lead to verify, not a conclusion. The associative-array case shows the pattern that worked: the model made the code readable, and a test harness, not the model, established which bugs were real.
35 years of Linux
Linux was first announced on a Usenet newsgroup in August 1991. The Linux Foundation marked the anniversary with a research report published on 6 October, the week of Open Source Summit and Embedded Linux Conference Europe in Prague, where the milestone was celebrated. The report, written with Daniel German of the University of Victoria, puts Linux on 4 billion Android devices, 30 million Chromebooks a year, more than 200 million servers and every system on the TOP500 list.
On development, it describes nearly ten changes reaching the kernel every hour and a new release every eight to nine weeks, notes record numbers of first-time contributors across 7.0 to 7.2, and identifies the mainlining of PREEMPT_RT in Linux 6.12 as the end of a twenty-year effort that opens the kernel further to industrial and automotive use.
What it means for engineering teams
These are the Foundation’s figures, and most of the installed base they describe is embedded. For a product team, the useful numbers are the cadence ones. A kernel that changes ten times an hour and releases every two months cannot be frozen in a BSP and left alone; longterm kernels and a routine for taking their stable updates are the realistic way to keep a device maintained, and the items above on ext4 and Yocto are examples of why.
References
- ext4: mark data=journal as deprecated and will be removed in January 2028 (commit 3e78d7b06323)
- [PATCH v17 0/6] Power State Change Reasons Recording (PSCRR) framework
- [PATCH v2 0/5] Make platform profiles firmware independent
- Yocto Project release calendar
- Release notes for Yocto Project 6.1 (blacksail), draft
- The 2026 Maintainers Summit
- assoc-array-fixes tag message
- Celebrating 35 Years of Linux — Linux Foundation
— Raghu Bharadwaj
