Software-update: Linux Kernel 7.2

Linux penguin logoLinus Torvalds heeft versie 7.2 van de Linux Kernel vrijgegeven. De kernel is het hart van het besturingssysteem en zit, simpel gezegd, als laag tussen de hardware en de applicaties in. De nieuwe uitgave bevat de gebruikelijke hoeveelheid aan veranderingen en verbeteringen. Meer informatie kan bij 9to5Linux, OMG Ubuntu en Phoronix worden gevonden.

Linux Kernel 7.2 Officially Released, This Is What’s New

Highlights of Linux 7.2 include cache-aware load-balancing support, initial HDMI 2.1 FRL support to the AMDGPU driver, support for devres-based management of ACPI notify handlers, initial CRI platform support for the Intel Xe driver, and Rust support for the IBM System/390 (S/390) architecture.

Linux kernel 7.2 also introduces a “Fair(er)” GPU scheduler, support for the ‘zerocopy’ library to Rust support to make zero-cost memory manipulation effortless, new hwcaps for the 2025 dpISA extensions on the AArch64 (ARM64) architecture, and enables large folios by default for the Btrfs file system.

It also brings Intel CPU model number support for Panther Lake R processor series, improvements to the kernel’s swap subsystem, support for multi-size transparent huge pages (mTHPs) to the khugepaged kernel thread, and support for compressed files to the SMB filesystem.

On top of that, Linux 7.2 improves the new NTFS filesystem introduced in Linux kernel 7.1, adds devicetree updates for 64-bit NXP/Freescale and Qualcomm platforms, introduces MPTCP signaling support for IPv6 addresses, adds GRO/GSO support for PPPoE, and brings more SMP load-balancing updates.

The EROFS file system received a fscache backend, the Ceph file system has gained the ability to reset clients manually, sched_ext gained initial support for sub-schedulers, the /proc/interrupts implementation has been updated for better performance, and the openat2() system call received a new O_EMPTYPATH flag.

Among other noteworthy changes, the XFS file system’s experimental zoned storage device support is no longer experimental, the dm-inlinecrypt device-mapper target received support for block devices, the TCP authentication option has been implemented, and there are also some Thunderbolt networking improvements.

Also worth mentioning is that the KVM subsystem has received support for AMD’s “guest-mode execution trap” and Intel’s “mode-based execution control” (MBEC) features, the NFS file system’s default block size was bumped to 4MB on systems with at least 16GB RAM, and support for the Intel Trusted Domain Extensions (TDX) feature has been added.

Security-wise, Linux kernel 7.2 brings the ability to control the use of UDP sockets to the Landlock module, the ability to stage measurement data outside of the kernel to the IMA (Integrity Measurement Architecture) subsystem, and support for compiler-assisted type-based slab cache partitioning to the slab allocator.

Last but not least, Linux 7.2 introduces the usual hardware support expansion through new and updated drivers. Worth mentioning, there’s PCI P2PDMA support for RAID0 and NVMe multipath, support for Intel Lizard Peak 2, support for TP-Link TL-UB250, and support for the HORI HORIPAD Nintendo Switch wireless controller.

Linux Kernel 6.11

Versienummer 7.2
Releasestatus Final
Besturingssystemen Linux
Website Linux Kernel Organization
Download https://www.kernel.org
Licentietype Voorwaarden (GNU/BSD/etc.)

Door Bart van Klaveren

Downloads en Best Buy Guide

18-08-2026 • 12:00

15

Submitter: danmark_ori

Bron: Linux Kernel Organization

Reacties (15)

Sorteer op:

Weergave:

NTFS in Linux? Is dat niet een windows file system? #ignorant
Ja, net zo goed als het aloude FAT, dat ook in Linux ondersteund word. Dat is ook nodig, al was het maar om USB sticks te kunnen lezen. NTFS is al jaren beschikbaar in Linux maar het was jarenlang alleen read-only. Relatief recent is ook write ondersteuning toegevoegd.
FAT is dan weer wel open en veel breder ondersteund / in gebruik. Camera's etc maken ook gebruik van FAT, (vroeger) een navigatie voor de auto had ook een FAT based SD kaartje

En EFI gebruikt ook FAT als EFI partitie. Waarmee enerzijds FAT support dus cruciaal is en anderzijds dus ook gekozen zan zijn juist omdat het "vrij" te gebruiken is en overal betrouwbaar werkt.

Waarbij FAT weer iet vetwars moet worden met exFAT. Dat is wel weer een Microsoft specifieke / "gesloten" uitbreiding (om bestanden groter dan 4GB te ondersteunen in ieder geval). Maar in principe ook onder alle gangbare OSen zal werken. (Externe HDDs (en neem aan USB stocks van groter dan 4GB :Y)) etc worden ook vaak standaard exFAT formatted geleverd omdat dat het enige is dat betrouwbaar onder Windows en Mac (en Linux) werkt).

Terwijl NTFS dan weer door MS ontwikkeld is en niet "open" is. Volgens mij is er wel documentatie over de werking, maar MS heeft wel vaker vage licenties, dat je de documentatie niet kunt/mag gebruiken voor een alternatieve implementatie etc (zie Wine die niet de MS documentatie mogen lezen over hoe Windows APIs werken).
exFAT is tegenwoordig vrij te gebruiken, Microsoft heeft het zelf de Linux-kernel in geholpen en heeft er zelfs een specificatie voor gepubliceerd. De SD-kaarten die ik tegenwoordig koop wordt standaard in exFAT geformatteerd, FAT lijkt alleen nog voor EFI gebruikt te worden. Eigenlijk zie ik geen reden meer om voor andere dingen nog FAT te gebruiken.

FAT zelf is origineel net zo gesloten als exFAT, alleen was FAT zo simpel dat het snel en eenvoudig gereverse-engineered was, waardoor iedereen het als een soort van open standaard gebruikte. Daarnaast was exFAT ook nieuwer, dus met dingen als softwarepatenten kwam je sneller in de strik omdat die nog niet verlopen waren toen het "nieuw" was.
NTFS write ondersteuning bestaat ook al de nodige jaren via NTFS-3G, maar die draait via FUSE in userspace. Voor NTFS-3G was er alleen een readonly kerneldriver.

Later is door Paragon een NTFS3 kerneldriver gedoneerd met write ondersteuning, maar die code is gewoon gedumpt en amper onderhouden, zaten de nodige tekortkomingen in.

In kernel 6.9 is de readonly kerneldriver voor NTFS verwijderd uit de kernel, in 7.1 kwam die terug met write ondersteuning.
NTFS werkt links of rechtsom echt al jaren onder Linux.

Vroeger via een userland implementatie (op basis van Fuse). Later is er een kernel based implementatie gekomen, maar die werd slecht onderhouden. En nu is er weer een nieuwe implementatie. Constant ding daarbij is wel dat het niet altijd even betrouwbaar werkt. Of bv voornamelijk op read-only gericht is. (Maar bv ook niet werkt als je in Windows niet "veilig verwijderen" hebt gedaan, dat er nog een vlaggetje staat en "Linux" vervolgens dienst weigert om meer te garanderen dat het niet stuk kan gaan).

En het omgekeerde kan ook. Er is bv ook een ext4 implementatie voor Windows.
ik kan een nfts schijf prima benaderen met lezen en schrijven echter als een game staat geïnstalleerd op een nfts schrijf werkt het niet, is dat probleem hiermee opgelost? al een tijdje geleden dat ik het heb geprobeerd
NTFS ondersteund geen Linux file attributes. Dat betekend hier dat op een NTFS volume òf alle bestanden executable zijn, òf geen enkele. Ik kan me voorstellen dat dat problemen geeft bij geïnstalleerde games.
Het ligt er maar net aan hoe je het implementeert. NTFS doet gewoon ACL's, je kunt prima een bestand executable maken op NTFS. Echter: je moet je systeem daar wel voor instellen.

Windows doet alles via wat op Linux via `setfacl` en vrienden wordt beheerd, waar Linux op de meeste bestandssystemen nog met het simpele rwxrwxrwx-model wordt gewerkt. Je kunt prima een /usr/bin-map op NTFS maken waarbij iedereen read+execute-rechten heeft en alleen root write-rechten heeft, maar veel Linux-tooling snapt dat niet.

Overigens kunnen systemen als ext4 en btrfs dat ook gewoon: je kunt je hele schijf chmodden naar 000 en via FACL's de boel beheren zoals Windows dat ook doet, maar ik ken geen distro die op die manier werkt.
Eigenlijk moet je dat niet willen: NTFS is vanwege backwards compatibility met Windows zwaar beperkt in z'n functionaliteit en performance. Ook Microsoft wil er vanaf (zie hun pogingen), maar dat blijkt lastig te verwezenlijken.
i know i know alleen stond er voor paar tb aan games geïnstalleerd en wat andere programma's die enkel met windows werken(adobe) op die schijf vandaar dat ik geen zin had de schijf om
te zetten
Al vanaf het begin van linux is dualboot met een msWindows systeem een ondersteunde installatie. Daarbij is het altijd handig om ook bij de bestanden van die msWindows installatie te kunnen. En al vanaf het begin ondersteunt linux zo ongeveer alles wat in computer-land gebruikt wordt.

Daarbij heeft microsoft steeds een doorgaande ontwikkeling van ntfs gedaan en dat niet altijd publiekelijk gedocumenteerd. Daarom was het gebruik altijd 'voorzichtig' en vaak ook officiëel alleen 'read-only' en ook vooral in user-land, dus zonder kernel ondersteuning. Sinds een aantal msWindowsNT versies is de functionatliteit van ntfs redelijk stabiel en dus kan de code onder linux uitkristialiseren en bij komen. Ondertussen is microsoft bezig met ReFS. Geen idee of/hoe dat onder linux bruikbaar is.

Sinds enige tijd ondersteunt microsoft ook de linux wereld op diverse vlakken, ook omdat ze het zelf gebruiken. Ik weet geen details maar ik kan mij voorstellen dat de kwaliteit van de implementatie van ntfs binnen linux een stuk beter is en sinds enige tijd is de code voor ntfs al in de kernel zodat de mounts onder linux systeem breed beschikbaar zijn.
NTFS benaderen vanuit Linux is echt al heel lang geen probleem. Read-write zat eind jaren '90 al in de kernel. Eerst experimenteel. Read-only zat ook al sinds eind jaren '90 in de kernel. Vervolgens had je NTFS middels FUSE en Paragon. Dankzij beide opties kan men vanuit Linux (en macOS) NTFS read-write benaderen. Paragon is proprietary en commercieel. FUSE is FOSS em user-space. Dat laatste heeft voor- en nadelen. Het grootste voordeel is compatibiliteit met oudere kernels (gaat immers om FUSE layer), het grootste nadeel is lagere performance. Ook kunnen in een monolithic kernel (dat is Linux) een probleem met zo'n kernel driver het complete systeem laten crashen, terwijl die kans bij een microkernel of bij user-space daemons nagenoeg nul is. Komt nog bij dat user-space of microkernel met minder privileges kan draaien, wat ten goede komt aan de lagere attack surface dus veiligheid. Als je dus kernel-space gaat draaien, dan wil je ook dat het stabiel en veilig is.
Is inderdaad ontwikkeld door Microsoft, en ook het primaire bestandssysteem voor Windows.

Daarmee wel fijn dat de kernel ondersteuning heeft om te lezen en te schrijven.
Bijvoorbeeld om je bestanden te kunnen redden vanaf een liveusb of om backups naar een plek te schrijven waar ook Windows erbij kan.
PPPoE GSO/GRO is een interessante voor de Tweakers die hun eigen router draaien. Kan PPPoE performance drastisch verbeteren als je CPU-gelimiteerd bent. Waarom de meeste providers nog PPPoE gebruiken op glasvezel weet ik ook niet 8)7

[Reactie gewijzigd door Nathan07 op 21 augustus 2026 05:46]


Om te kunnen reageren moet je ingelogd zijn