Linux 7.1: New NTFS Write Driver, Steam Deck OLED Audio, Apple Silicon Power

Linux 7.1 was released by Linus Torvalds on June 14, 2026, bringing a rewritten optional NTFS driver, Steam Deck OLED audio fixes, Apple Silicon battery reporting, AMD power-management changes, Intel FRED enablement, and a large purge of obsolete kernel code. The interesting part is not that Linux gained another long list of hardware enablement patches; it always does. The interesting part is that this release reads like a kernel community deciding, with unusual clarity, what is worth carrying forward and what is not.
For Windows users who live in Linux part-time, Linux 7.1 is unusually relevant. NTFS is a Microsoft filesystem, the Steam Deck is a Linux PC with console expectations, Apple Silicon support is a test of whether mainline can absorb vendor-hostile hardware, and the code removals are a reminder that old compatibility has a maintenance bill. This is a release about borders: between Windows and Linux, upstream and downstream, new hardware and old, convenience and maintainability.

The Kernel’s Windows Problem Gets a Serious Rewrite​

The most WindowsForum-relevant change in Linux 7.1 is the arrival of a new optional NTFS driver. Linux has been able to read NTFS for ages, and the ntfs3 driver contributed by Paragon in Linux 5.15 added in-kernel write support. But NTFS on Linux has remained one of those features that technically exists while still carrying an asterisk in the minds of cautious dual-booters.
Linux 7.1 does not immediately throw ntfs3 overboard. The existing ntfs3 driver remains the default, while the new driver can be selected through kernel configuration. That makes this release less a coronation than an audition: the kernel now has a second in-tree path for NTFS that is trying to be more maintainable, more modern, and more aligned with current Linux filesystem infrastructure.
That distinction matters because NTFS is not a hobby filesystem. It is the default language of Windows data volumes, USB disks, external SSDs, and countless “I just need to copy this one thing” recovery sessions. For Linux users who dual-boot with Windows, run rescue environments, or administer mixed fleets, NTFS support is not a symbolic compatibility checkbox. It is the bridge between the world Windows assumes and the one Linux actually inhabits.
The new driver’s lineage is also notable. It comes from Namjae Jeon, already known in kernel circles for work around exFAT and other storage-related code. That does not guarantee perfection, but it does suggest the effort is not a random drive-by submission. The kernel’s filesystem maintainers have learned the hard way that a feature as risky as write support to someone else’s filesystem needs active ownership, not merely a tarball tossed over the wall.
The technical pitch is that this NTFS implementation revives and modernizes the old in-kernel NTFS driver, adding write support and moving toward newer mechanisms such as iomap-based file operations. For ordinary users, the translation is simple: Linux developers are trying to make NTFS feel less like a tolerated foreign object and more like a filesystem the kernel can reason about using its current tools.

Compatibility Is Only Useful When Someone Maintains It​

There is a temptation to frame the NTFS work as Linux “catching up” to Windows. That is too simple. Windows owns NTFS because Microsoft controls the format, the implementation, and the assumptions around shutdown, hibernation, journaling, and recovery. Linux is doing something more delicate: interoperating with a filesystem whose home turf is elsewhere.
That is why the new driver should be welcomed but not romanticized. Anyone who has mounted a Windows partition from Linux knows the familiar caveats: disable Fast Startup if necessary, do not casually write to a hibernated Windows volume, keep backups, and do not confuse filesystem support with immunity from user error. A better kernel driver can reduce friction, but it cannot make dual-boot storage magically risk-free.
Still, this release changes the conversation. For years, Linux users have had to choose between FUSE-based NTFS-3G, which is mature but slower and outside the kernel, and ntfs3, which was exciting but sometimes regarded as under-attended. Linux 7.1 introduces a third option that says the kernel community has not given up on NTFS as a first-class interoperability problem.
That matters for Windows administrators more than many Linux release notes do. Rescue media, forensic workflows, backup appliances, NAS boxes, and recovery scripts often need to handle NTFS volumes without booting Windows. If the new driver matures, the payoff will be less drama in the moments where cross-platform storage is already stressful.
The correct posture is cautious optimism. Linux 7.1 gives testers and distribution maintainers something substantial to evaluate, not a blanket instruction for everyone to remount their family photo archive read-write on day one. The fact that the new driver is optional is not a weakness. It is exactly how a kernel should introduce risky storage plumbing.

Steam Deck OLED Shows the Cost of Living Downstream​

The Steam Deck OLED audio fix is a smaller change with a larger lesson. Mainline Linux had reportedly carried broken audio support for the OLED model for roughly two years, while Valve’s downstream SteamOS kernel and some handheld-focused distributions worked around the problem. Linux 7.1 finally fixes the issue upstream.
For Steam Deck owners who never leave SteamOS, this may sound academic. Valve ships a curated operating system, not a generic rolling kernel, and it can patch around hardware quirks as needed. But the Steam Deck’s cultural significance has always been that it is a PC pretending to be a console, and PCs invite users to install things they were not necessarily meant to install.
That is where upstream support matters. A Fedora, Arch, Debian, or Ubuntu experiment on the Steam Deck OLED should not require users to rediscover a vendor patch trail just to get sound from the speakers. The longer a device depends on downstream fixes, the more its “Linux support” becomes a fragile stack of tribal knowledge.
The Steam Deck OLED fix also illustrates a quiet truth about Linux hardware support: popularity does not automatically produce mainline polish. Even a high-profile Linux gaming device can carry a broken upstream experience if the relevant subsystem, firmware assumptions, topology files, and vendor patches do not line up. The kernel is vast, and regressions can hide in the seams between drivers and product-specific configuration.
Linux 7.1 does not transform the Steam Deck into a generic laptop. It does, however, reduce the distance between Valve’s supported universe and the broader Linux ecosystem. For handheld PCs, that distance is increasingly important as more Windows-first and Linux-curious devices enter the market.

AMD’s Power Shift Moves Laptop Policy Closer to the Kernel​

AMD’s amd-pstate driver gains Dynamic EPP support in Linux 7.1, allowing the system to switch Energy Performance Preference behavior depending on whether a machine is plugged into AC power or running on battery. On wall power, the CPU can favor performance. On battery, it can move toward a more restrained balanced-performance profile without diving straight into a sluggish efficiency mode.
That sounds like a small quality-of-life tweak, and in one sense it is. Laptop users already expect power behavior to change when they unplug. Desktop environments, vendor utilities, and distribution power daemons have been doing some version of this dance for years.
The important shift is where the policy can live. When power-profile switching depends entirely on user-space tools, behavior can vary widely by distribution, desktop environment, or OEM integration. Moving more of that intelligence closer to the kernel driver gives Linux a better chance of behaving consistently across the messy laptop market.
The feature is not enabled by default in Linux 7.1, which is another sign of kernel caution. Users or distributions must opt in, for example through a boot parameter. But the direction is obvious: Linux laptop power management is slowly becoming less of a scavenger hunt and more of a coherent platform feature.
AMD’s Ryzen AI NPU support also improves through the AMDXDNA driver, adding monitoring features such as memory usage queries and power estimate reporting. That is not yet the kind of user-facing AI feature that sells laptops at retail, but it is the substrate such features need. Before Linux desktops can make intelligent use of NPUs, administrators and developers need to see what those accelerators are consuming and how they behave under load.

Intel FRED Is the Kind of Performance Work Users Rarely See​

Intel’s Flexible Return and Event Delivery, better known as FRED, is enabled by default in Linux 7.1 on supported hardware. FRED is one of those CPU features that sounds obscure until you remember that modern operating systems spend a huge amount of time crossing boundaries between user work and kernel work. Every interrupt, system call, exception, and return path is part of the machinery that makes interactive computing feel immediate rather than chunky.
FRED aims to make some of those transitions cleaner and less wasteful. The benefit is not that your desktop suddenly feels twice as fast. It is that certain interrupt-heavy or request-heavy workloads can gain modest but meaningful improvements, especially on newer Intel systems where the hardware support exists.
Audio production is a useful example because it exposes latency and scheduling problems quickly. A few percentage points in a digital audio workstation benchmark may sound boring until you are the person trying to run a project with low buffer sizes without crackles. Kernel performance work often matters most where failure is audible, visible, or measured in missed frames.
The broader story is that x86 is still evolving in ways operating systems must actively absorb. Windows users are accustomed to firmware updates, chipset drivers, and platform features arriving as part of the PC lifecycle. Linux has to implement the same hardware reality through a public, multi-vendor kernel development process. FRED becoming default is one small moment where the upstream kernel stops merely supporting a CPU feature and starts trusting it.
It is also not solely an Intel story forever. FRED support is expected to matter for future AMD processors as well. That makes Linux 7.1 less about one vendor’s performance checkbox and more about the kernel preparing for a new baseline in x86 privilege-transition handling.

Apple Silicon Inches Toward Boring, Which Is the Goal​

Linux on Apple Silicon has always been a strange achievement. It is technically impressive, politically unsupported by Apple in the way mainstream PC hardware is supported, and still incomplete enough that ordinary users should not confuse progress with parity. Linux 7.1’s Apple SMC battery reporting work is therefore a meaningful but unglamorous milestone.
The new macsmc-power driver exposes information such as AC adapter status, battery charge state, voltage, current, temperature, and battery health to the kernel. That is basic laptop plumbing, but basic plumbing is what turns a science project into a daily driver. Power tools, desktop battery indicators, and tuning utilities cannot do serious work if the kernel cannot reliably describe the battery.
The driver also opens the door to controlling charging behavior, including charge limiting. That matters because battery longevity is no longer a niche enthusiast concern. Windows laptops, macOS, and OEM utilities increasingly offer some version of charge thresholds or battery health modes. For Linux on Apple Silicon to feel normal, it must eventually participate in the same expectations.
Audio support on Apple Silicon also moves forward with groundwork for the six-codec speaker arrangement used in some MacBooks. That is a reminder that Apple hardware is not merely “ARM plus a GPU.” It is a stack of custom controllers, unusual audio layouts, platform-specific power behavior, and undocumented decisions. Mainline support advances one subsystem at a time.
For WindowsForum readers, the Apple Silicon work is interesting not because it threatens Windows PCs, but because it shows what modern hardware support really costs. The PC ecosystem is messy, but its conventions are still friendlier to generic operating systems than Apple’s vertically integrated world. Every Apple Silicon improvement in Linux is a small victory over the idea that hardware should only run the software its vendor blesses.

Filesystem Work Is Quiet Until It Saves Your Data​

Beyond NTFS, Linux 7.1 brings a set of filesystem and I/O changes that will not dominate release coverage but will matter to people who push storage hard. EXT4, still the default filesystem for Ubuntu and a major default across the Linux world, mostly receives bug fixes and preparation for a future move of its buffered write path toward iomap. This is groundwork, not fireworks.
exFAT gets a more immediate improvement through fragmentation reduction, helped by pre-allocation support. That matters because exFAT is common on removable media precisely where users least want to think about filesystem behavior. Cameras, SD cards, USB drives, and cross-platform external disks are boring right up until write performance collapses or a transfer fails.
The arrival of BPF support in io_uring is another developer-facing change with potentially broad consequences. io_uring has become one of Linux’s most important modern I/O interfaces, and BPF brings programmable filtering and control closer to that path. Backup tools, databases, package managers, and synchronization software all live or die by efficient I/O.
The ublk user-space block driver gaining zero-copy I/O support is similarly technical but practical. Reducing CPU overhead and latency in block operations matters for storage stacks that increasingly mix kernel mechanisms with user-space services. Linux has spent years making user-space storage more plausible without surrendering too much performance.
Btrfs also sees its shutdown operation graduate from experimental to stable. That may sound like a minor status change, but status matters when system tools and scripts need to trust behavior. Filesystems are one area where “probably fine” is not good enough; stable interfaces are how cautious administrators decide what can be automated.

The Hardware Grab Bag Is Actually the Point​

Every Linux kernel release contains a hardware grab bag, and Linux 7.1 is no exception. Lenovo Yoga fan control, expanded TUXEDO and Uniwill laptop support, Bitland MIFS WMI functionality for keyboard backlighting and platform profiles, and more ASUS motherboard sensor support all land in this cycle. Individually, these are modest changes. Collectively, they are what desktop Linux users experience as “my machine finally works properly.”
The Lenovo work is especially representative. Fan control and monitoring are not glamorous, but they determine whether a laptop feels polished or half-supported. A machine that runs hot, spins fans oddly, or hides thermal data from user-space tools may boot Linux perfectly and still feel unfinished.
The same is true for motherboard sensors. Enthusiasts running ASUS boards with lm_sensors are not asking for a philosophical triumph; they want temperatures, voltages, and fan readings to appear correctly. Hardware health visibility is basic hygiene for overclockers, home-lab builders, workstation users, and anyone debugging instability.
Gaming peripherals get their usual dose of charming specificity. Rock Band instruments, DJ Hero turntables, Winwing throttles, Legion Go controllers, haptics, LEDs, rumble, and force feedback support all reinforce a very Linux idea: if a device speaks USB or Bluetooth and someone cares enough, it may eventually be made to work. This is not corporate platform strategy. It is accreted enthusiasm with patches.
There is also support for audio components in newer laptops, including internal microphone arrays on some Ryzen 6000-era systems and codecs appearing in recent Intel and Dell designs. These details matter because laptop audio remains one of the places where Linux can still feel unpredictable. A working speaker is good; a working mic array in a video-call world is essential.

Old AMD Graphics Get a Better Future Than Old Network Stacks​

Linux 7.1 moves more older AMD APUs from the old Radeon driver path toward the modern amdgpu driver. The affected hardware includes A-Series and E-Series era parts from around 2013 and 2014, the sort of budget chips that still turn up in spare desktops, old laptops, garage workstations, and lightweight Linux boxes.
This is one of the kernel’s more endearing habits. A decade-old integrated GPU can sometimes become more useful because the modern driver stack finally embraces it. Better performance, cleaner support, and Vulkan availability through the Mesa ecosystem can make old hardware feel less abandoned than it did under its original software assumptions.
But the same release also deletes a large amount of old code. That contrast is important. Linux is not simply keeping everything forever; it is choosing which old hardware still has a plausible maintenance story. Some aging AMD graphics parts get a second life because the modern stack can carry them. Other subsystems, such as obsolete networking protocols and ancient drivers, are cut loose.
The new DRM-RAS framework points in the other direction: not nostalgia, but observability for modern GPUs and accelerators. Reliability, Availability, and Serviceability features let drivers expose hardware error counters and reliability information to user space in a more standardized way. That matters in workstations, servers, and accelerator-heavy systems where silent hardware faults are not just annoying but operationally expensive.
Intel’s Xe graphics driver also gains a user-space interface for managing video memory pressure. The practical goal is to reduce crashes and out-of-memory failures when VRAM fills under heavy workloads. This is the sort of plumbing that becomes more important as integrated and discrete GPUs handle heavier desktop compositing, media, compute, and AI-adjacent work.

The Great Code Purge Is Not Vandalism​

Linux 7.1 reportedly removes more than 140,000 lines of legacy code, including old networking drivers and support for technologies such as ISDN, ham radio AX.25 networking, UDP-Lite, CAIF, Bluetooth CMTP, and bus mice. The emotional reaction depends on whether you see old code as heritage or liability. Kernel maintainers increasingly see it as both, and liability is winning.
The stated concern is not merely aesthetic. Obsolete drivers can still attract bug reports, security findings, and automated analysis, including AI-generated reports that may be noisy or low-value. Maintainers then have to triage issues in code no one actively uses, for devices few people can test, in subsystems nobody wants to own.
That is not a sustainable bargain. A kernel that supports everything forever eventually becomes a museum with a scheduler. Linux’s strength has always been breadth, but breadth without maintainership is just deferred risk.
Security also changes the calculus. Dead code is not always harmless code. If a subsystem can be built, loaded, fuzzed, or reached through some unexpected path, it can become part of the attack surface. Removing obsolete code is not as exciting as adding a driver for a new handheld, but it is often the more responsible engineering decision.
The i486 phase-out belongs in the same category. Linux 7.1 begins removing build configuration options for old 486 sub-architectures, though the underlying support is not necessarily gone all at once. The message is plain enough: the kernel is preparing to stop pretending that a 1990s CPU is a reasonable target for a 2026 operating system.
For preservationists, that hurts. For maintainers, it is overdue. There are other operating systems, old kernel branches, emulators, and museum builds for historically interesting machines. Mainline Linux cannot be both the operating system of future accelerators and the permanent caretaker of every bus mouse-era assumption.

A Security Change Makes Debugging Less Casual​

Linux 7.1 tightens access to another process’s memory through /proc/PID/mem. Earlier kernels allowed sufficiently privileged processes to inspect or modify memory in ways that were powerful but broad. The new behavior requires an active debugging relationship between the processes.
This is one of those security changes that can irritate tools before it reassures users. Linux has a long tradition of exposing powerful process introspection interfaces, and administrators often rely on them for debugging, tracing, crash analysis, and recovery. Restricting access can break assumptions in obscure workflows.
But the direction is unsurprising. Modern operating systems are steadily narrowing the gap between “privileged” and “allowed to do anything to any process at any time.” Attackers love overly broad introspection surfaces, and endpoint security models increasingly assume that even privileged contexts should face boundaries.
Windows has gone through its own long evolution here, with protected processes, credential isolation, driver signing, and increasingly aggressive containment around sensitive memory. Linux approaches the problem differently, but the underlying trend is shared. Debugging power is useful; ambient memory access is dangerous.
The practical advice is not panic. Most ordinary users will never notice this change. But tool authors, security teams, and administrators with custom debugging workflows should test Linux 7.1 before assuming old /proc-based tricks will behave exactly as before.

This Release Rewards Testers, Not Thrill-Seekers​

Linux 7.1 is out, but that does not mean every Ubuntu, Fedora, Arch, Debian, or Mint user should immediately chase it. Distributions exist partly to absorb kernel churn, apply configuration choices, test interactions, and decide when a new kernel is ready for their users. Mainline kernels are raw material, not always retail product.
Ubuntu users, for example, may see Linux 7.1 appear in development builds or mainline kernel packages before it becomes part of a stable distribution release. That is useful for testing hardware enablement and regressions. It is not the same as a recommendation to replace a working kernel on a production laptop because a changelog looks interesting.
The people who should care soonest are the ones with a specific reason. Dual-booters and storage testers may want to evaluate the new NTFS driver on non-critical volumes. Steam Deck OLED experimenters running non-Valve kernels have a direct incentive. Laptop users on supported AMD systems may want to test Dynamic EPP. Administrators with security-sensitive environments may want to validate the /proc/PID/mem behavior.
Everyone else can let their distribution do its job. Kernel releases are newsworthy because they define where Linux is going, not because they are all meant to be manually installed by Tuesday afternoon. The healthiest Linux ecosystem is one where upstream moves quickly and downstreams decide carefully.

The Linux 7.1 Story Fits in a Windows Admin’s Notebook​

Linux 7.1 is a broad kernel release, but its most practical consequences are concrete enough to separate from the noise. The release is not merely a performance bump or a hardware dump. It is a maintenance statement with visible user impact.

• Linux 7.1 introduces a new optional in-kernel NTFS driver, while the existing ntfs3 driver remains the default for now.
• Steam Deck OLED audio is fixed upstream, reducing the need for Valve-specific or distribution-specific workarounds on mainline kernels.
• AMD laptop power management gains Dynamic EPP support, although users and distributions must opt in before it changes behavior.
• Apple Silicon Linux support becomes more laptop-like through battery and power reporting, even though full parity remains a long-term project.
• The kernel drops a large amount of obsolete legacy code, signaling that unmaintained compatibility is no longer treated as free.
• Security around process memory access tightens, which should interest tool developers and administrators who rely on low-level debugging workflows.

The through-line is that Linux 7.1 is less about one blockbuster feature than about the kernel becoming more deliberate. It improves interoperability with Windows storage, fixes a conspicuous gaming handheld regression, prepares for newer CPU behavior, and cuts code whose maintenance cost no longer makes sense. That is what mature platforms do: they add, they prune, and they force users to distinguish between compatibility worth saving and history worth archiving.

---

References​

1. Primary source: OMG! Ubuntu
   Published: 2026-06-15T04:00:09.778470
   
   

   Linux 7.1 brings new NTFS driver, Steam Deck OLED audio fix + more - OMG! Ubuntu

   Linux 7.1 arrives with a rewritten NTFS driver, Apple Silicon battery reporting, and Steam Deck OLED audio fixes alongside massive legacy code removals.

   www.omgubuntu.co.uk
2. Related coverage: phoronix.com
   
   

   Linux 7.1 Fixes Audio For The Steam Deck OLED After Being Broken 2 Years On The Upstream Kernel - Phoronix

   It turns out the Steam Deck OLED gaming handheld has not had working audio support with the mainline (upstream) Linux kernel since a change in late 2023 that was merged for Linux 6.8

   www.phoronix.com
3. Related coverage: linuxjournal.com
   
   

   Linux 7.1-rc2 Released with Driver Fixes, Steam Deck OLED Audio Repair, and Growing AI Patch Trends | Linux Journal

   www.linuxjournal.com
4. Related coverage: tomshardware.com
   
   

   Linux 7.1 update includes new in-kernel NTFS driver — delivers storage support upgrade for Linux users | Tom's Hardware

   New driver is a ground-up rewrite that allows Windows volumes to be accessed directly by the kernel for reads and writes.

   www.tomshardware.com
5. Related coverage: techcroute.com
   
   

   Linux 7.1-rc2 est disponible : corrections importantes pour Steam Deck OLED et AMD - TechCroute.com

   Linux 7.1-rc2 corrige enfin le problème audio du Steam Deck OLED et apporte plusieurs améliorations pour les cartes AMD. Découvrez les nouveautés de cette deuxième version candidate.

   www.techcroute.com
6. Related coverage: elchapuzasinformatico.com
   
   

   La Steam Deck OLED ve resuelto su problema de audio en Linux

   La Steam Deck OLED ha visto solventados los problemas de audio cuando se utilizaban versiones de Linux con kernels oficiales.

   elchapuzasinformatico.com

Spoiler: Additional references (9)

1. Related coverage: linuxdork.com
   
   

   Linux 7.1-rc1: NTFS Gets a Full Rewrite and the i486 Finally Retires | Linux Dork

   Linus Torvalds opened the Linux 7.1 merge window on April 26, 2026. The first release candidate brings a four-year-in-the-making NTFS driver rewrite with full write support, FRED enabled by default, and the long-overdue removal of 486-class CPU support.

   linuxdork.com
2. Related coverage: windowsreport.com
   
   

   Steam Deck OLED Audio Finally Fixed on Mainline Linux With Kernel

   Steam Deck OLED audio finally works on mainline Linux with kernel 7.1, eliminating the need for custom patches.

   windowsreport.com
3. Related coverage: lucaberton.com
   
   

   NTFS on Linux 7.1: Native Read/Write Support | Luca Berton

   Linux 7.1 merges a completely overhauled NTFS driver with native read/write support, replacing the stagnated NTFS3 driver. Four years of development by.

   lucaberton.com
4. Related coverage: linuxiac.com
   
   

   Linux Kernel 7.1 Merges New NTFS Driver With Full Write Support

   A new NTFS driver is now part of Linux kernel 7.1, combining write support, folio conversion, iomap, and userspace utility support.

   linuxiac.com
5. Related coverage: linux.org.ru
   
   

   В состав ядра 7.1 принят новый драйвер NTFS — Ядро Linux — Новости

   Линус Торвальдс принял в состав ядра Linux 7.1, релиз которого ожидается в середине июня, набор изменений с новой реализацией драйвера для файловой системы NTFS...

   www.linux.org.ru
6. Related coverage: newsminimalist.com
   
   https://www.newsminimalist.com/articles/linux-71-resolves-steam-deck-oled-audio-bug-bbf17bbc
7. Related coverage: access.redhat.com
   
   

   Release Notes - Release Notes for Red Hat Enterprise Linux Server for ARM Development Preview

   PDF document

   access.redhat.com
8. Related coverage: docs.huihoo.com
   
   https://docs.huihoo.com/redhat/rhel7/pdf/Red_Hat_Enterprise_Linux-7-7.1_Release_Notes-en-US.pdf
9. Related coverage: files.serialport.org
   
   

   Migrating Network Drivers

   Created with The GIMP

   files.serialport.org

 

[ChatGPT]

Linux 7.1 was released by Linus Torvalds on June 14, 2026, bringing a new in-kernel NTFS implementation, default Intel FRED support, AMD power-management changes, broader graphics enablement, and a deliberate purge of obsolete hardware support. The headline sounds like storage, but the real story is discipline. Linux is not merely adding support for newer machines; it is deciding which old assumptions no longer deserve a permanent seat in the kernel.
That is a useful distinction, because Linux kernel releases are often misunderstood as feature dumps. Version 7.1 is better read as a maintenance philosophy made visible: modernize the paths that ordinary users and administrators still depend on, then cut away the subsystems that have become liabilities. For WindowsForum readers, the NTFS work is the obvious bridge between worlds, but the deeper message is that interoperability now has to meet the same engineering standards as native Linux infrastructure.

Linux 7.1 Makes Compatibility Earn Its Keep​

The Linux kernel has always lived with a peculiar bargain. It is expected to run on everything from servers and laptops to tiny embedded systems and aging hobbyist hardware, while also supporting the latest CPUs, GPUs, storage stacks, security mechanisms, and virtualization models. That breadth is part of Linux’s power, but it also creates a permanent tax on maintainers.
Linux 7.1 looks like one of those releases where the bill came due. The kernel gains a modern NTFS path, new processor features, GPU improvements, Apple Silicon battery reporting, and fixes for devices such as the Steam Deck OLED. At the same time, it starts letting go of i486-era support and removes large amounts of old networking and peripheral code.
That tradeoff is not nostalgia versus progress. It is risk management. Every driver, protocol, and architecture quirk that remains in-tree must be reviewed, built, tested, patched, and defended against security bugs, even when almost nobody uses it anymore.
The arrival of AI-assisted bug hunting has sharpened that tension. Automated reports can surface real bugs, but they can also bury maintainers in findings for hardware and protocols that no one is realistically deploying. Linux 7.1’s cleanup push is therefore not just aesthetic pruning; it is an answer to a changed development environment.

NTFS Is No Longer Treated Like a Guest in the House​

The most Windows-relevant change in Linux 7.1 is the new NTFS driver. NTFS remains unavoidable in mixed environments because Windows still dominates many desktop, gaming, and external-storage workflows. Dual-boot users, repair technicians, forensic analysts, and administrators moving disks between systems all know the practical importance of being able to read and write NTFS volumes reliably from Linux.
Historically, that support has been awkward. NTFS-3G made Linux NTFS access broadly useful through FUSE, but the userspace approach carried overhead and never felt as native as ext4, XFS, or Btrfs. The later NTFS3 driver improved the situation by putting more capability in the kernel, yet NTFS support still carried the aura of something Linux tolerated rather than fully absorbed into its modern filesystem architecture.
Linux 7.1 attempts to reset that bargain. The new implementation, originally discussed around the NTFSPlus work and merged as a replacement for the old NTFS driver path, is built around newer kernel infrastructure such as folios and iomap rather than legacy buffer-head assumptions. That matters less because of branding and more because filesystem drivers live or die by how well they fit the kernel’s memory-management and writeback machinery.
The promise is not that NTFS suddenly becomes a Linux-native filesystem. It does not. NTFS semantics were designed around Windows, and there will always be translation issues where Linux permissions, metadata expectations, journaling behavior, and repair tooling do not map perfectly. But the new driver changes the baseline from “can Linux access this Windows volume?” to “can Linux do so using contemporary kernel mechanisms without dragging an old code path forward indefinitely?”
That is a meaningful shift for everyday users. External drives formatted for Windows are not going away, and neither are dual-boot setups. If the new driver matures as intended, the benefit will be less drama: fewer reasons to reach for userspace workarounds, fewer performance cliffs in write-heavy tasks, and a cleaner foundation for future fixes.

The New NTFS Driver Is a Bridge, Not a Peace Treaty​

The temptation is to declare the NTFS problem solved. That would be premature. Filesystem support earns trust slowly, especially when write access is involved and the other operating system in the relationship is Windows.
Administrators know this from hard experience. A filesystem driver can look healthy in benchmarks and still reveal edge cases in crash recovery, sparse files, compression, alternate data streams, permissions, encryption, or repair workflows. NTFS is not merely a layout on disk; it is part of a Windows ecosystem that includes assumptions made by Explorer, BitLocker, Windows Update, backup tools, antivirus software, and enterprise policy engines.
For WindowsForum readers, the practical advice is straightforward: the new Linux 7.1 NTFS implementation is important, but it should be adopted with the same caution as any major filesystem-path change. Reading from NTFS volumes is one thing. Writing to irreplaceable production data from a newly introduced kernel driver is another.
That does not weaken the release. It makes the release more interesting. Linux is acknowledging that interoperability with Windows is not a second-class hobbyist concern, while also moving the implementation toward the same maintainability expectations applied elsewhere in the kernel.
In the long run, this is how cross-platform storage gets better. Not through slogans about replacing Windows or Linux, but through boring, difficult, low-level work that makes the shared boundary between them less fragile.

Intel FRED Shows Where Performance Work Has Gone​

Linux 7.1 also enables Intel FRED by default on supported systems. FRED, short for Flexible Return and Event Delivery, is a low-level CPU feature concerned with how processors handle events, interrupts, and transitions between privilege levels. That is not the sort of feature that sells laptops at retail, but it is exactly the kind of plumbing that affects latency, reliability, and performance on newer platforms.
This is the modern shape of kernel performance work. The easy wins are mostly gone. What remains are targeted improvements in event delivery, scheduler behavior, memory pressure handling, asynchronous I/O, GPU memory management, and CPU power-state selection.
For Intel, FRED’s default enablement is part of preparing Linux for current and upcoming client and server platforms. The benefit will not be evenly visible across every workload, and users should be skeptical of any claim that one CPU feature magically transforms a system. But for latency-sensitive workloads, virtualization-heavy environments, and newer silicon platforms, these architectural details matter.
The important point is that Linux 7.1 is not merely chasing benchmark headlines. It is aligning the kernel with processor designs that expect operating systems to participate more intelligently in event handling. That is a long-term bet, not a one-release trick.

AMD Gets the Kind of Laptop Behavior Users Actually Notice​

The AMD changes in Linux 7.1 are more visible to ordinary users because power behavior is something people feel. The amd-pstate work allowing dynamic performance-profile switching depending on AC power or battery state is not glamorous, but it addresses a very real complaint: Linux laptops can still feel less polished than Windows when it comes to balancing responsiveness and battery life.
A Windows laptop user expects the machine to understand context. Plugged in, it should lean into performance. On battery, it should conserve power without feeling broken. Linux has made enormous progress here, but behavior can still depend heavily on distribution defaults, firmware quality, desktop environment integration, and hardware generation.
Linux 7.1 does not solve all of that. Kernel support is only one layer in a chain that includes firmware, system services, desktop power profiles, and vendor quirks. But the kernel has to expose the right capabilities before the rest of the stack can make good decisions.
For AMD users, that makes this release a practical one. The improvement is not a flashy new app or control panel. It is the sort of platform behavior that makes Linux feel less like a port and more like a first-class operating system on modern mobile hardware.

Graphics Support Keeps Moving Toward the Hardware Horizon​

The graphics story in Linux 7.1 is broad rather than singular. Intel’s Xe driver continues to mature with work around Arc Battlemage and upcoming Nova Lake-P graphics. AMDGPU gains expanded paths for older GCN-era hardware while continuing enablement for newer devices and accelerators. The Rust-based Nova driver for NVIDIA hardware also continues its early, cautious march.
This is the reality of Linux graphics in 2026: there is no single “Linux graphics driver” story anymore. There are multiple vendors, multiple driver families, several generations of hardware, and a growing split between display, compute, media, and AI-adjacent acceleration work. Kernel support has to land early enough for distributions to be ready when hardware ships, but stable enough not to punish users who update.
Intel’s work is especially important because the company is still rebuilding its reputation in discrete and integrated graphics. Arc Battlemage improvements and Nova Lake-P enablement are not just checkboxes; they are part of making sure Linux is not late to the next hardware cycle. If a new laptop arrives and Linux support is months behind, enthusiasts notice, developers complain, and enterprise evaluators quietly move on.
AMD’s case is different. The company has benefited from a strong open driver story, but supporting both old and new Radeon generations is a constant balancing act. Linux 7.1’s movement of some older GCN 1.1 APUs toward better AMDGPU defaults shows that modernization is not only about brand-new silicon. Sometimes the best user-facing improvement is making old-but-still-useful hardware follow the healthier driver path.
NVIDIA remains the most complicated case. The Nova driver’s Rust foundation is interesting because it signals a future where memory safety and maintainability become part of the driver conversation, not just performance and feature parity. But early support is early support. Users should not confuse architectural promise with a finished replacement for mature driver stacks.

The Steam Deck OLED Fix Is Small Only If You Do Not Own One​

Linux 7.1’s Steam Deck OLED audio fix is the sort of change that looks minor in a release summary and major to the affected users. Valve’s SteamOS hides much of the complexity for mainstream Deck owners, but mainline kernel support matters for distributions, tinkerers, downstream projects, and anyone who wants hardware to work outside a vendor-curated image.
The Steam Deck has become more than a gaming handheld. It is one of the most visible consumer Linux devices ever sold at scale, and its success has changed expectations. Linux hardware support is no longer only judged by whether a ThinkPad boots or a server NIC works. It is judged by speakers, sleep states, controllers, suspend behavior, refresh-rate switching, and whether the machine feels appliance-like.
That is why mainline fixes matter. The healthier the upstream support, the less downstream patching and vendor-specific maintenance is needed. In the long run, that helps not just Steam Deck users, but the broader ecosystem of handheld gaming PCs that increasingly depend on Linux-friendly graphics, input, audio, and power-management paths.
The same logic applies to Apple Silicon battery reporting. Nobody should mistake a battery metric driver for complete M-series MacBook support. But everyday usability is built out of exactly these small pieces: battery status, temperature readings, suspend behavior, display handling, keyboard quirks, and power limits. Linux on Apple Silicon advances by accumulation.

Rust Moves From Symbol to Infrastructure​

Linux 7.1 continues the kernel’s cautious adoption of Rust, including raised toolchain expectations and additional integration work. The important word is cautious. Rust in the Linux kernel is neither a revolution that rewrites the project overnight nor a sideshow destined to disappear. It is a slow experiment in changing how certain classes of kernel code can be written and maintained.
The security argument for Rust is familiar: memory-safety bugs remain a major source of vulnerabilities in systems software. But the kernel cannot simply swap languages as if it were a web service. It has decades of C code, complex build constraints, architecture-specific paths, and maintainers who rightly care more about correctness than trend alignment.
That makes driver development the natural testing ground. New drivers can use Rust without demanding that old subsystems be rewritten wholesale. The Nova NVIDIA driver work is symbolically important for this reason. A modern driver for complex hardware, written with safety-oriented tools, is a plausible place for Rust to prove value.
Still, Linux 7.1 does not turn Rust into the dominant kernel language. It moves the experiment forward. That is how infrastructure changes should happen in a project where mistakes can corrupt filesystems, crash servers, or break boot on millions of machines.

BPF and io_uring Keep Blurring the Kernel Boundary​

The integration of BPF handlers with io_uring is one of the more technical changes in Linux 7.1, but it deserves attention because it reflects a broader trend. Linux is increasingly building programmable machinery into areas that used to be fixed kernel behavior. BPF began as packet filtering and has become a general-purpose mechanism for safe, constrained programmability inside the kernel.
io_uring, meanwhile, has become one of Linux’s most important high-performance I/O interfaces. It is powerful, controversial, and security-sensitive precisely because it sits close to the performance boundary between applications and the kernel. Allowing BPF handlers to interact with that world opens new design possibilities for high-throughput services.
The upside is obvious for advanced users: less overhead, more flexible dispatch paths, and the possibility of replacing application-side event loops with more kernel-coordinated logic. The risk is equally obvious: every increase in kernel programmability expands the need for verification, policy, and careful privilege boundaries.
Linux 7.1’s security changes should be read in that context. The kernel is adding power while trying to tighten access around process memory, stacked filesystems, Unix sockets, and virtualization boundaries. In modern Linux, performance and security are no longer separate stories. The same features that make the kernel faster and more flexible also demand more disciplined containment.

The i486 Farewell Is Really a Governance Decision​

The start of i486 support removal will attract sentimental headlines, and understandably so. The 486 era belongs to a formative period of PC history, when Linux itself was young and the desktop computing world was still taking shape. For some readers, “Linux drops i486” will sound like the end of an emotional contract.
But operating systems cannot be museums at kernel scale. If a hardware class requires special-case logic that complicates modern assumptions, and if almost nobody is maintaining or testing it, then keeping it alive is not neutral. It consumes attention that could be spent on hardware people are actually deploying.
The same argument applies to removed ISDN pieces, old network adapters, bus mouse support, UDP-Lite, AX.25, obsolete PCMCIA and PCI drivers, and other dead code. Some of these technologies have historical or niche value. That does not automatically justify their presence in the mainline kernel forever.
This is where Linux differs from closed platforms in a useful way. The code does not vanish from history. Older kernels remain available. Specialist users can maintain out-of-tree paths or run period-appropriate software. What changes is whether the mainline kernel must continue carrying that burden for everyone.
There is a security dimension too. Old code is not harmless just because old hardware is rare. Unmaintained subsystems can contain vulnerabilities, and automated auditing has made obscure code easier to probe. The more attack surface the kernel keeps, the more maintainers must defend.

IPv6 Becoming Less Optional Reflects the Same Logic​

One of the subtler changes reported around Linux 7.1 is that IPv6 can no longer be compiled as a separate module in the same old way; it must either be built into the kernel or disabled. To casual users, that may sound like an obscure configuration detail. To kernel builders and distribution maintainers, it reflects a familiar pattern: optionality has costs.
IPv6 is no longer an exotic add-on. It is part of the modern network stack, and many kernel features assume its presence or must account for its absence. Supporting every possible modular combination may satisfy a purist sense of configurability, but it can also create dependency problems and poorly tested edge cases.
This is one of the least glamorous forms of modernization: reducing configurations that technically exist but operationally make less sense each year. Linux remains configurable to a degree most operating systems are not. But configurability without maintainability is just another kind of debt.
The kernel community has become more willing to say that some options do not deserve the complexity they impose. Linux 7.1’s broader cleanup makes that stance visible across architectures, drivers, protocols, and now network-stack configuration.

Enterprise IT Should See a Kernel That Is Getting Less Romantic​

For enterprise administrators, the Linux 7.1 release is not a reason to rush production systems onto a new mainline kernel. Most organizations will consume these changes through vendor kernels, long-term support releases, cloud images, appliance updates, and distribution backports. The mainline release is the upstream weather system, not the immediate forecast for every data center.
Still, IT pros should pay attention to the direction. The kernel is prioritizing maintainable modern paths over indefinite compatibility. That has consequences for hardware qualification, recovery environments, dual-boot workflows, and security baselines.
The NTFS work is especially relevant for mixed Windows and Linux shops. Even if production Linux servers rarely write to NTFS volumes, support desks, migration teams, backup operators, and forensic workflows often encounter Windows-formatted disks. A more modern in-kernel driver can eventually improve those workflows, but enterprises will wait for distribution validation before trusting it with sensitive data.
The hardware cleanup matters too. Organizations still running extremely old devices should not assume mainline Linux will preserve support forever. In many cases, the right answer is not outrage but segmentation: keep legacy systems on stable, isolated, period-appropriate software, and do not pretend they can be carried safely into every modern kernel.
For security teams, Linux 7.1 reinforces an uncomfortable truth. Reducing attack surface is sometimes indistinguishable from removing beloved features. That may be unpopular among hobbyists, but it is a rational posture for an operating system that underpins servers, clouds, phones, routers, desktops, and embedded devices.

Desktop Users Will Feel the Release Indirectly​

Most desktop users will not install Linux 7.1 and immediately notice a transformed machine. There is no new shell, no redesigned settings panel, and no magical gaming switch. Kernel releases rarely announce themselves that way.
Instead, the changes appear as fewer annoyances. An NTFS external drive behaves better. A laptop chooses power states more intelligently. A newer Intel system handles low-level events more efficiently. A Steam Deck OLED running a mainline-friendly distribution gets working audio. An Apple Silicon MacBook reports battery information through upstream plumbing.
That indirectness is why kernel work is often undervalued. Users see the distribution, the desktop environment, the package manager, and the app store. They rarely see the driver fix that made suspend reliable or the scheduler change that reduced glitching in an audio workload.
Linux 7.1 is a good reminder that the operating system experience is cumulative. The desktop feels polished only when hundreds of low-level assumptions are correct. Filesystems, firmware interfaces, graphics drivers, CPU features, device trees, input quirks, and security policies all have to cooperate before the user can simply stop thinking about them.

The Real Upgrade Is a Narrower Definition of Support​

Linux 7.1’s concrete changes are easy to summarize, but the strategic point is sharper: Linux is becoming more selective about what support means. Supporting hardware or a filesystem is no longer enough if the support path is obsolete, unmaintained, insecure, or poorly integrated with modern kernel architecture.
That is a healthier definition. It treats compatibility as an engineering commitment rather than a sentimental archive. It also acknowledges that the kernel’s scale has changed. Linux is too important, too widely deployed, and too heavily scrutinized to carry old code indefinitely just because someone, somewhere, might theoretically compile it.
The new NTFS driver fits neatly into that philosophy. Windows interoperability remains important, so the kernel invests in a cleaner implementation. The i486 and dead networking pieces fit too. Rarely used, fragile code imposes a cost, so the kernel begins to remove it. The through-line is not “new good, old bad.” It is “maintained, useful, and defensible.”

The Kernel’s Message to Windows Users Is Practical, Not Tribal​

For a Windows-heavy audience, Linux 7.1 should not be read as a victory lap over Windows. The NTFS work is actually a concession to reality: Windows filesystems remain part of the computing landscape, and Linux users need to interact with them safely and efficiently.
That is the kind of interoperability that matters. Not marketing claims about ecosystem openness, but the ability to plug in a disk, recover files, share data, or maintain a dual-boot setup without stepping through a minefield. The better Linux handles NTFS, the easier it becomes for Windows users to experiment with Linux without abandoning their existing storage habits on day one.
But Linux 7.1 also sends a warning to anyone who treats operating systems as static compatibility layers. The kernel is moving. It is dropping old assumptions, adopting newer CPU primitives, hardening access paths, and making driver architecture more modern. Users who want the benefits of current hardware and current security work cannot expect infinite backward compatibility at zero cost.
That is the bargain every platform eventually faces. Windows faces it with old drivers, legacy control panels, 32-bit assumptions, and enterprise application compatibility. Linux faces it in public, patch by patch, with every removal debated in the open.

The Upgrade Path Is Clearer Than the Headline​

Linux 7.1 is not a release most users should manually force onto production machines simply because it exists. Kernel adoption depends on distribution policy, hardware needs, and risk tolerance. Rolling-release users will see it sooner. Stable and enterprise distributions will take what they want, when they are ready, often with backports and vendor testing in between.
The more useful approach is to map the release to actual needs. If you rely on NTFS-heavy workflows, watch how your distribution handles the new driver and what defaults it chooses. If you run newer Intel hardware, especially platforms that benefit from FRED, kernel 7.1 is part of the enablement story. If you use AMD laptops, power-management behavior is worth tracking as distributions integrate the new pieces.
Gamers and handheld users should pay attention to mainline hardware fixes, but they should also remember that vendor-tuned distributions may already carry patches ahead of upstream or maintain their own integration layers. Apple Silicon users should treat every mainline improvement as progress, not completion.
The release is therefore less about immediate installation and more about where the ecosystem is heading. Linux 7.1 establishes upstream facts that distributions, vendors, and users will absorb over the coming months.

Linux 7.1’s Most Important Changes Are the Ones That Remove Excuses​

Linux 7.1 gives users plenty to test, but its significance lies in how many old excuses it eliminates. NTFS can no longer be treated as a neglected compatibility corner. Obsolete drivers can no longer hide behind theoretical users forever. Modern CPU features can no longer wait indefinitely for safe defaults. Hardware support can no longer mean “works only if your vendor image carries the right patch.”
The practical picture is compact:

• Linux 7.1 was released on June 14, 2026, after a development cycle focused on filesystems, hardware enablement, performance plumbing, and code removal.
• The new NTFS driver is the most Windows-relevant change, because it modernizes an important bridge for dual-boot systems, external drives, recovery workflows, and mixed-platform environments.
• Intel FRED being enabled by default shows that kernel performance work is increasingly tied to low-level CPU event handling rather than visible desktop features.
• AMD power-profile improvements, Steam Deck OLED audio fixes, and Apple Silicon battery reporting are examples of kernel work that users experience as polish rather than as a headline.
• The removal of i486-era paths and obsolete networking or peripheral code reflects a security and maintainability decision, not merely a lack of affection for old hardware.
• Enterprises should watch the release as an upstream signal while waiting for distribution-vetted kernels before trusting new filesystem and hardware paths in production.

Linux 7.1 is best understood as a cleanup release with consequences: it makes Windows storage interoperability more serious, modern hardware support more automatic, and obsolete code less welcome. That combination will not satisfy everyone, especially those who see the kernel as a permanent preservation layer for every machine that ever booted. But the future Linux is preparing for is not smaller; it is more demanding, and the kernel that serves it will have to keep choosing maintainability over mythology.

---

References​

1. Primary source: Desde Linux
   Published: 2026-06-15T17:30:15.477927
   
   

   Linux 7.1: ntfsplus, says goodbye to obsolete hardware, AMD improvements, BPF security, and more

   Linux 7.1 comes with the super-fast ntfsplus, dynamic performance for AMD processors, advanced BPF security, and the removal of more than 140 lines of old code.

   blog.desdelinux.net
2. Independent coverage: Research Snipers
   Published: 2026-06-15T13:30:15.481503
   
   

   Linux 7.1 is here: New in NTFS & CPU support, an end to old hardware – Research Snipers

   Linus Torvalds gave the starting signal for Linux 7.1. In addition to a completely new...

   researchsnipers.com
3. Independent coverage: Techgenyz
   Published: 2026-06-15T12:30:15.473488
   
   

   Linux Kernel 7.1 Released With New NTFS Driver and Wider Hardware Support

   Linux Kernel 7.1 adds a new in-kernel NTFS driver, Intel FRED by default, Steam Deck OLED audio fixes, Apple Silicon support and wider hardware updates.

   techgenyz.com
4. Independent coverage: Techzine Global
   Published: Mon, 15 Jun 2026 12:10:10 GMT
   
   

   Linux kernel 7.1 released with updated NTFS driver - Techzine Global

   Linux kernel 7.1 has been released with an updated NTFS driver, enhanced Landlock security, and broader hardware support.

   www.techzine.eu
5. Independent coverage: Neowin
   Published: Mon, 15 Jun 2026 04:36:00 GMT
   
   

   Linux 7.1 arrives with an NTFS overhaul and major hardware performance boosts - Neowin

   The stable Linux 7.1 kernel release brings massive performance enhancements for upcoming Intel and AMD chips, a rewritten NTFS driver, and vital hardware bug fixes.

   www.neowin.net
6. Related coverage: linuxteck.com
   
   

   Why Linux Kernel 7.1 Is An Important Update | LinuxTeck

   Linux kernel 7.1 shipped on June 14, 2026, announced by Linus Torvalds from a different timezone mid-travel. The release delivers a new in-kernel NTFS

   www.linuxteck.com

Spoiler: Additional references (7)

1. Related coverage: phoronix.com
   
   

   Linux 7.1 Features: New NTFS Driver, New Intel + AMD Hardware, Performance Optimizations & Modernization - Phoronix

   The Linux 7.1 development kernel that amounts to nearly 40 million lines has a lot of new features and changes in tow.

   www.phoronix.com
2. Related coverage: ostechnix.com
   
   

   Linux Kernel 7.1 Final Released: Here's What's New - OSTechNix

   Linus Torvalds officially released the final version of Linux Kernel 7.1. Learn what's new in Linux 7.1.

   ostechnix.com
3. Related coverage: muylinux.com
   
   

   Disponible Linux 7.1, nueva versión del kernel

   Linux 7.1 llega con nuevo controlador NTFS, Intel FRED activado por defecto, mejoras de hardware y más limpieza de código antiguo.

   www.muylinux.com
4. Related coverage: technetbooks.com
   
   

   Linux 7.1 Kernel Testing Begins With Modern NTFS Driver Support And Removal Of Legacy i486 Code | Technetbook

   Linux 7.1 Release Candidate starts testing with modernized NTFS drivers, drops obsolete i486 architecture support, and adds new graphics hardware code

   www.technetbooks.com
5. Related coverage: tomshardware.com
   
   

   Linux 7.1 update includes new in-kernel NTFS driver — delivers storage support upgrade for Linux users | Tom's Hardware

   New driver is a ground-up rewrite that allows Windows volumes to be accessed directly by the kernel for reads and writes.

   www.tomshardware.com
6. Related coverage: linuxdork.com
   
   

   Linux 7.1-rc1: NTFS Gets a Full Rewrite and the i486 Finally Retires | Linux Dork

   Linus Torvalds opened the Linux 7.1 merge window on April 26, 2026. The first release candidate brings a four-year-in-the-making NTFS driver rewrite with full write support, FRED enabled by default, and the long-overdue removal of 486-class CPU support.

   linuxdork.com
7. Related coverage: docs.redhat.com
   
   https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/pdf/7.1_release_notes/71-release-notes.pdf