“`html

تغییرات هیجان‌انگیز زیادی در انتظار لینوکس ۷.۰

۱. پشتیبانی از سخت‌افزار گرافیکی جدید AMD با فعال‌سازی بلوک‌های IP مختلف، از جمله GFX ۱۲.۱

این ویژگی پشتیبانی از نسل جدید کارت‌های گرافیک AMD را اضافه می‌کند. بلوک‌های IP (Intellectual Property) بخش‌های مدولار سخت‌افزاری هستند که برای عملکرد بهتر گرافیک مثل رندرینگ بازی‌ها یا محاسبات GPU فعال می‌شوند. GFX ۱۲.۱ احتمالاً مربوط به معماری جدید AMD است که کارایی بالاتری در لینوکس ارائه می‌دهد.

در درایور AMDGPU (ماژول متن‌باز کرنل لینوکس برای کارت‌های گرافیک AMD) سخت‌افزار گرافیکی به بخش‌های منطقی چندگانه تقسیم می‌شود که به آنها «IP Block» گفته می‌شود. هر بلوک IP مجموعه‌ای از عملکردهای خاص را روی GPU پیاده‌سازی می‌کند. برای مثال:

• بلوک‌های GFX بخش‌هایی هستند که مسؤول پردازش‌های اصلی گرافیکی مثل رندر سه‌بعدی، اجرای دستورات شیدر، و محاسبات گرافیکی در APIهایی مثل Vulkan یا OpenGL هستند.
• علاوه بر GFX، بلوک‌های دیگر نیز وجود دارند مثل MMHUB (مدیریت حافظه گرافیک)، PSP (پردازنده امنیتی)، IH (سیستم مدیریت وقفه‌ها)، SDMA (کپی‌های DMA)، و دیگر زیرسیستم‌ها که هرکدام نقش دقیق در عملکرد کلی GPU دارند.

زمانی که در کرنل لینوکس پشتیبانی از GFX 12.1 افزوده می‌شود، یعنی:

1. کرنل نسخه‌های جدید AMDGPU Driver را به‌روز می‌کند تا بتواند واحدهای سخت‌افزاری جدیدی با شناسه‌های IP به‌روز (از جمله GFX 12.1) را شناسایی، راه‌اندازی و کنترل کند. این کاری است که AMD به صورت بلوک‌به‌بلوک انجام می‌دهد، یعنی هر بخش سخت‌افزاری را جداگانه فعال و پشتیبانی می‌کند تا درایور برای معماری‌های آینده آماده شود.
2. GFX 12.1 به معنی نسخه جدیدی از بلوک گرافیک اصلی است که احتمالا با معماری‌های تازه‌ای از AMD (مثلاً RDNA 4 یا حتی نسل بعدی مانند CDNA 5 برای شتاب‌دهنده‌های AI/HPC) هماهنگ خواهد بود. این پشتیبانی به درایور اجازه می‌دهد کارت‌های گرافیک یا شتاب‌دهنده‌هایی که این نسخه IP را دارند، بدون نیاز به درایور غیر رسمی یا اصلاحات دستی، روی لینوکس کار کنند.
3. افزودن پشتیبانی از این IPها در کرنل به این معناست که زمانی که سیستم عامل بوت می‌شود و درایور amdgpu را بارگذاری می‌کند، می‌تواند دقیق‌تر سخت‌افزار گرافیکی را شناسایی و مدیریت کند، واحدها را مقداردهی اولیه کند، و ویژگی‌های خاص معماری GPU را درست فعال کند. این موضوع اثر مستقیم روی پایداری، عملکرد در رندر گرافیک، پشتیبانی از APIهای مدرن، و هماهنگی با اکوسیستم Mesa دارد.

۲. تحلیل زمینه و قفل‌گذاری مبتنی بر کامپایلر

ابزاری برای تحلیل خودکار کد در زمان کامپایل (build-time) که بررسی می‌کند چگونه زمینه‌های اجرا (مثل threadها) و قفل‌ها (locks) برای جلوگیری از تداخل کار می‌کنند. این کمک می‌کند تا باگ‌های پیچیده امنیتی و عملکردی زودتر پیدا شوند و کد هسته ایمن‌تر شود.

ویژگی «تحلیل زمینه و قفل‌گذاری مبتنی بر کامپایلر» که اخیراً وارد کرنل لینوکس شده است، ابزار استاتیک جدیدی است که به کامپایلر اجازه می‌دهد قواعد مربوط به زمینه‌های اجرا (context) و قفل‌گذاری (locking) در هسته را بررسی کند پیش از آنکه برنامه حتی اجرا شود. این تحلیل به صورت مستقیم در زمان کامپایل کد هسته با Clang انجام می‌شود و هدفش کشف اشتباهات پیچیده در همگام‌سازی و امنیت است.

این تحلیل که در مستندات رسمی کرنل با نام Context Analysis شناخته می‌شود یک افزونه زبانی است که به کامپایلر Clang اجازه می‌دهد قوانین مربوط به قفل‌ها و زمینه‌های فعال یا غیرفعال را به‌طور ایستا بررسی کند. برای فعال شدن آن لازم است کرنل با گزینه‌های پیکربندی مناسب (مثلاً CONFIG_WARN_CONTEXT_ANALYSIS=y) ساخته شود و قابلیت در فایل‌های ماژول یا دایرکتوری‌هایی که باید تحلیل شوند فعال گردد.

در این سیستم، مفهومی به نام context lock یا قفل زمینه تعریف می‌شود. این قفل‌ها معمولاً با ساختارهای همگام‌سازی معمولی مثل mutex، spinlock، rwlock و دیگر primitives همگام‌سازی در هسته مرتبط هستند. تحلیل، بررسی می‌کند که آیا در نقاط مختلف برنامه، قفل مورد نیاز برای اجرای منطقی بخش کد فعال (held) یا غیرفعال (not held) است و آیا این قواعد توسط کد رعایت شده‌اند یا خیر.

تحلیل زمینه و قفل‌گذاری مبتنی بر کامپایلر بر بررسی استاتیک کد تمرکز دارد. یعنی این بررسی روی کد منبع پیش از اجرا انجام می‌شود و خطاهایی را که ممکن است منجر به شرایط رقابتی، استفاده نادرست از قفل‌ها، یا نقض قواعد همگام‌سازی شوند شناسایی می‌کند. این مزیت دارد که باگ‌های همگام‌سازی و مشکلات پیچیده عملکردی را پیش از اجرای کد در محیط واقعی پیدا می‌کند، در حالی که ابزارهای تحلیل زمان اجرا مثل lockdep یا KCSAN چنین بررسی‌هایی را به زمان اجرا موکول می‌کنند.

نکات کلیدی:

• این تحلیل کامپایلر را به یک ابزار بررسی همگام‌سازی تبدیل می‌کند، چیزی شبیه به آنچه در ابزارهای تحلیل ایستا انجام می‌شود، اما مخصوص زبان C و قراردادهای هسته لینوکس با Clang.
• برای فعال‌سازی باید زیرسیستم‌ها یا فایل‌های مشخصی را در Makefile مشخص کرد تا تحلیل روی آن‌ها اعمال شود (opt-in).
• تحلیل به طور کاملاً ایستا انجام می‌شود؛ یعنی هیچ هزینه اجرا/زمان اجرا ندارد و فقط خروجی‌های هشداری یا خطا را هنگام ساخت نشان می‌دهد.
• این ابزار به ویژه برای بخش‌هایی از کرنل که با چند نخ/همگام‌سازی زیاد سروکار دارند یا خطاهای همگام‌سازی می‌تواند پیامدهای امنیتی داشته باشد مفید است.

۳. پشتیبانی از “Turn On Display” ACPI DSM مایکروسافت برای حل مشکلات لپ‌تاپ

ACPI یک استاندارد برای مدیریت قدرت سخت‌افزار است. DSM (Device Specific Method) یک تابع خاص برای دستگاه‌هاست. این ویژگی کمک می‌کند تا مشکلات روشن شدن نمایشگر در لپ‌تاپ‌ها (مثل تأخیر یا خاموشی ناگهانی) در ویندوز و لینوکس حل شود، به‌خصوص در دستگاه‌های هیبریدی.

ویژگی «پشتیبانی از “Turn On Display” ACPI DSM مایکروسافت» که اخیراً به کرنل لینوکس اضافه شده، در واقع مربوط به گسترش پشتیبانی از روش‌های خاص مدیریت انرژی ACPI در لپ‌تاپ‌ها است. ACPI (Advanced Configuration and Power Interface) یک استاندارد است که سیستم‌عامل را قادر می‌سازد با firmware/BIOS سخت‌افزار تعامل کند تا حالت‌های صرفه‌جویی در انرژی، خواب، روشن/خاموش کردن نمایشگر، و دیگر موارد مدیریت انرژی را کنترل کند.

در این استاندارد، Device Specific Method یا DSM توابع خاصی هستند که هر OEM یا سیستم‌عاملی ممکن است برای کنترل بهتر سخت‌افزار تعریف کند. هر DSM یک «شناسه عملکرد» (Function Index) دارد که مشخص می‌کند چه عملیاتی باید انجام شود.

• مایکروسافت در Windows 11 22H2 یک تابع جدید ACPI DSM به نام «Turn On Display Notification» (Function 9) معرفی کرده که برای اعلام به firmware این‌که سیستم قصد دارد نمایشگر را روشن کند (هنگام خروج از حالت Modern Standby) استفاده می‌شود. این اعلان به firmware اجازه می‌دهد تا پاور ریل‌ها را سریع‌تر فعال کند و بخش‌های سخت‌افزاری (مثل فن‌ها، نور پس‌زمینه صفحه‌کلید و دیگر اجزا) را درست در زمان مناسب از حالت خواب خارج کند.
• قبلاً در بسیاری از دستگاه‌های لپ‌تاپ (مثلاً Lenovo Yoga Slim 7i Aura) دیده شده که وقتی سیستم از حالت خواب (s2idle) خارج می‌شود، فن‌ها و نور پس‌زمینه کلیدها دوباره فعال نمی‌شوند مگر این‌که firmware این اعلان خاص را دریافت کند. علت این است که firmware در برخی طراحی‌ها انتظار دارد OS از این DSM استفاده کند تا بتواند اجزای مختلف را به‌طور کامل راه‌اندازی کند.
• اضافه کردن این پشتیبانی به کرنل به این معناست که در مسیر اجرای مدیریت انرژی (مثلاً در درایور s2idle)، کرنل اکنون این تابع DSM را در ترتیب مناسبی صدا می‌زند:
  1. خروج از LPS0 (LPS0 Exit)
  2. اعلان Turn On Display
  3. خروج از Modern Standby
  4. روشن کردن صفحه

  این ترتیب باعث می‌شود که firmware بتواند ریل‌های پاور و دیگر کنترل‌های سخت‌افزاری را قبل از تکمیل خروج از حالت خواب بازیابی کند.

۴. فعال‌سازی پیش‌فرض Intel TSX در CPUهای سازگار (برای عملکرد بهتر، جایی که مسائل امنیتی تأثیر زیادی ندارند)

TSX (Transactional Synchronization Extensions) یک فناوری اینتل برای اجرای تراکنش‌های اتمی بدون تداخل است که سرعت برنامه‌ها را افزایش می‌دهد. قبلاً به دلیل آسیب‌پذیری‌های امنیتی (مثل ZombieLoad) غیرفعال بود، اما حالا در CPUهای امن‌تر پیش‌فرض فعال می‌شود.

ویژگی «فعال‌سازی پیش‌فرض Intel TSX در CPUهای سازگار» که در کرنل لینوکس جدید (نسخه‌های 7.0 و بالاتر) اعمال شده به این معناست که Transactional Synchronization Extensions (TSX) روی CPUهای Intel که این قابلیت را دارند و بدون آسیب‌پذیری‌های شناخته‌شده جدی هستند، دیگر به‌طور پیش‌فرض غیرفعال نیستند و در حالت auto فعال می‌شوند تا عملکرد بهتر در همگام‌سازی چندنخی فراهم شود. این تغییر در کرنل اصلی لینوکس پذیرفته شده و حالات پیش‌فرض در بخش x86-cpu به «auto» تغییر داده شده است.

TSX مجموعه‌ای از دستورات سخت‌افزاری برای حافظه تراکنشی است که به نرم‌افزار اجازه می‌دهد بخش‌هایی از کد را در قالب «تراکنش» اجرا کند. اگر تراکنش بدون تداخل نهایی شود، دستورات به‌صورت اتمی commit می‌شوند و در صورت وقوع تداخل یا خطا، rollback انجام می‌شود. این روش می‌تواند هزینه قفل‌گذاری سنتی را کاهش دهد و در بهینه‌سازی کارهای چندنخی یا ساختارهای داده اشتراکی کارا باشد.

در گذشته، به دلیل آسیب‌پذیری‌های مربوط به Spectre/Meltdown و به‌خصوص TSX Asynchronous Abort (TAA)، بسیاری از پردازنده‌های Intel TSX را به‌طور پیش‌فرض خاموش می‌کردند یا نیازمند گزینه‌های بوت خاص بودند تا فعال شوند، چرا که فعال بودن TSX می‌توانست بردار حملات جانبی (speculative execution) را باز کند.

تغییر اخیر در کرنل بدین معناست که:

• اگر CPU دارای پشتیبانی سخت‌افزاری TSX قابل اعتماد باشد و آسیب‌پذیری‌های شناخته‌شده در آن برطرف شده باشند (مثلاً با میکروکد جدید)، این قابلیت در حالت «auto» فعال می‌شود.
• حالت «auto» به کرنل اجازه می‌دهد به‌صورت پویا تصمیم بگیرد که TSX را روشن کند یا نگه دارد (بر اساس تشخیص اینکه آیا خطر امنیتی وجود دارد یا خیر).
• این کار باعث می‌شود نرم‌افزارهایی که می‌توانند از تراکنش‌های اتمی سخت‌افزاری بهره ببرند (مثل پایگاه‌داده‌ها، سامانه‌های VM، یا بارهای محاسباتی چندنخی پرکار) بدون پیکربندی دستی عملکرد بهتری داشته باشند.

۵. تنظیم آسان لوگوی بوت سفارشی به جای Tux (در فرآیند بوت هسته لینوکس با کنسول)

Tux پنگوئن معروف لینوکس است. این ویژگی اجازه می‌دهد کاربران لوگوی دلخواه (تصویر سفارشی) را به راحتی در زمان بوت (راه‌اندازی سیستم) جایگزین کنند، بدون نیاز به تغییرات پیچیده در کد.

ویژگی مورد اشاره در هسته لینوکس (پشتیبانی از تنظیم آسان لوگوی بوت سفارشی به جای Tux) به صورت رسمی وارد درخت اصلی شده است. تا پیش از این، اگر می‌خواستید لوگوی معروف پنگوئن Tux را در آغاز فرآیند بوت لینوکس عوض کنید، معمولاً باید به صورت دستی منابع درایور لوگو را در سورس کرنل پاک یا تغییر می‌دادید، فایل لوگو را جایگزین می‌کردید و سپس کرنل را مجدداً می‌ساختید. این کار پیچیده، دردسرساز و مستعد خطا بود.

در نزدیک‌ترین نسخه‌های کرنل (در شاخه development ۶.۲۰ تا ۷.۰) پچ‌هایی وارد شده‌اند که این فرآیند را بسیار ساده‌تر می‌کنند. این پچ‌ها گزینه‌های Kconfig جدید اضافه می‌کنند تا بتوانید فایل لوگو سفارشی (مثلاً در فرمت‌های PBM یا PPM) را در زمان کامپایل هسته مشخص کنید، بدون اینکه مجبور باشید خودتان سورس یا Makefile را دستکاری کنید.

مشخصات این تغییر:

• گزینه‌های پیکربندی جدید مثل LOGO_LINUX_MONO_FILE, LOGO_LINUX_VGA16_FILE و LOGO_LINUX_CLUT224_FILE اضافه می‌شود که به شما اجازه می‌دهد فایل لوگوی دلخواه را برای نمایش لوگوی بوت انتخاب کنید. این فایل‌ها در قالب‌های استاندارد مانند PBM/PPM هستند که قبلاً هم برای لوگوهای بوت استفاده می‌شدند.
• این گزینه‌ها در زمان ساخت هسته (kernel build) فعال می‌شوند و آیتم لوگوی جدید مستقیماً در پیکربندی Kconfig قابل انتخاب است؛ یعنی لازم نیست از طریق ویرایش سورس‌کد و Makefile وارد تغییرات شوید.
• تغییراتی که این پچ‌ها انجام می‌دهند همچنین شامل پاک‌سازی و ساده کردن منطق داخلی قسمت‌ مربوط به لوگو در پوشه drivers/video/logo/ نیز هست، به طوری که مدیریت لوگوها قابل فهم‌تر و انعطاف‌پذیرتر شود.

نکته مهم: این لوگو در کنسول اولیه framebuffer console هنگام راه‌اندازی هسته نمایش داده می‌شود — و این با همان اسپلش‌اسکرین‌های گرافیکی که در ابزارهایی مثل Plymouth یا Usplash در سطح کاربری نمایش داده می‌شوند متفاوت است. لوگوی بوت در هسته بسیار زودتر از آن انجام می‌شود که فضای کاربری بارگذاری شود.

• حذف HIPPI، استاندارد نزدیک به گیگابیتی برای شبکه supercomputerها در دهه ۱۹۹۰

HIPPI (High-Performance Parallel Interface) یک پروتکل قدیمی شبکه برای کامپیوترهای فوق‌العاده قدرتمند بود که سرعت نزدیک به ۱ گیگابیت داشت. حالا حذف می‌شود چون منسوخ شده و هیچ دستگاه مدرنی از آن استفاده نمی‌کند.

ویژگی «حذف HIPPI از هسته لینوکس» یعنی پشتیبانی رسمی از پروتکل شبکه HIPPI (High Performance Parallel Interface)، که از دهه ۱۹۸۰ و ۱۹۹۰ در محیط‌هایی مثل سوپرکامپیوترها برای ارتباط نزدیک-به-گیگابیت (حدود ۰.۸ Gb/s) استفاده می‌شد، از درخت اصلی کرنل حذف شده است. این تغییر بخشی از آماده‌سازی کرنل برای نسخه ۷.۰ لینوکس است و به صورت یک پچ در شاخه net-next وارد شده است.

دلایل اصلی این تصمیم:

• پروتکل HIPPI حدود دو دهه است که به‌طور عملی منسوخ شده و عملاً هیچ سخت‌افزار مدرنی از آن استفاده نمی‌کند. در عمل ارتباطات شبکه‌ای پرسرعت دهه‌هاست که با استانداردهایی مثل Ethernet، Fibre Channel و بعدتر InfiniBand جایگزین شده‌اند.
• نگهداری کد مربوط به HIPPI در هسته بار نگهداری بی‌موردی ایجاد می‌کرد، زیرا به جز رفع اشکالات سطحی در طول سال‌ها، هیچ تغییری فعال یا استفاده واقعی در دنیا نداشته است. حذف این کد حدود ۲۸۳۲ خط مربوط به زیرسیستم HIPPI و درایور RoadRunner را از پایه کد هسته پاک می‌کند.
• بخش‌هایی از هدرهای قدیمی (مثل include/uapi/linux/if_hippi.h) به دلایل پایداری فضای کاربر (userspace) باقی می‌ماند تا از شکستن برنامه‌های قدیمی جلوگیری شود، اما پشتیبانی فعال حذف شده است.

۶. گسترش time slice (پس از یک دهه توسعه، بالاخره ادغام می‌شود)

Time slice بخشی از زمان CPU است که به هر فرآیند اختصاص می‌یابد. این گسترش کمک می‌کند تا مدیریت زمان‌بندی بهتر شود، عملکرد سیستم در محیط‌های چندوظیفه‌ای افزایش یابد و تأخیرها کاهش یابد.

ویژگی «گسترش time slice» که در کرنل لینوکس پس از حدود یک دهه تلاش توسعه‌دهندگان بالاخره ادغام شده ارتباط دارد به بهبود مدیریت زمان اختصاص‌یافته به فرایندها (time slice/quantum) در scheduler هسته. این کار به ویژه برای کاهش تداخل زمانی در بخش‌های حساس و افزایش کارایی در سیستم‌های پرتراکم چند هسته‌ای طراحی شده است، و اکنون رسماً در شاخه اصلی هسته برای نسخه‌های ۷.۰ به بعد پذیرفته شده است.

«Time slice extension» به این معنی است که:

• در حالت استاندارد، هر thread مقداری مشخص از زمان CPU (quantum) دریافت می‌کند تا اجرا شود و سپس scheduler آن را preempt می‌کند تا CPU به دیگر threadها اختصاص یابد. این مقدار پیش‌فرض در scheduler تعیین می‌شود و برای تقسیم عادلانه CPU بین threadها استفاده می‌شود.
• ایده‌ی این توسعه جدید این است که به threadها اجازه داده شود در برخی شرایط خاص درخواست کنند که «مقدار زمان اختصاص‌یافته به آن‌ها» به شکل موقت افزایش یابد تا بتوانند بخش بحرانی (critical section) کد خود را کامل اجرا کنند بدون اینکه در میانه‌ی اجرای آن preempt شوند.
• این درخواست بر اساس یک API مبتنی بر restartable sequences (RSEQ) انجام می‌شود: thread با تنظیم یک بیت در ساختار rseq ثبت‌شده نزد هسته به کرنل اعلام می‌کند که زمان slice را موقّتی طولانی‌تر کند.
• کرنل در صورت دیدن این بیت، زمان slice را برای مدت کوتاهی (مثلاً حدود ۳۰ میکروثانیه) افزایش می‌دهد تا thread فرصت بیشتری برای تکمیل بخش بحرانی داشته باشد و سپس با استفاده از یک تایمر مجبور به preempt کردن آن می‌شود (اگر هنوز مشغول باشد).

هدف کلی این توسعه این است که در مواردی که thread در حلقه‌های بحرانی یا بخش‌های حساس قرار دارد، preemption ناگهانی باعث افت عملکرد یا تداخل (مثلاً قفل‌گذاری‌های طولانی یا waitهای زیاد) نشود. این می‌تواند در بارهای کاری سنگین و پرتراکم، تاخیر‌های scheduler را کاهش دهد و توازن بهتری بین پاسخ‌دهی و بهره‌وری CPU ایجاد کند.

• مدیریت منابع revocable (که به نظر می‌رسد در این چرخه هسته بعدی ادغام شود)

این سیستم اجازه می‌دهد منابع (مثل حافظه یا فایل‌ها) که به فرآیندها اختصاص داده شده، به راحتی پس گرفته شوند بدون crash سیستم. مفید برای امنیت و مدیریت منابع در سرورها و کانتینرها.

ویژگی «مدیریت منابع revocable» در کرنل لینوکس یک زیرساخت جدید برای مدیریت امن و پویا منابعی است که ممکن است به‌طور ناگهانی از دسترس خارج شوند یا لغو (revoke) شوند، و به نظر می‌رسد این تغییر در چرخه‌ی توسعه‌ی ۶.۲۰/۷.۰ لینوکس ادغام شود.

در مدل قدیمی یک درایور یا زیرسیستم منابعی (مثل حافظه، داده‌های سخت‌افزاری یا اشاره‌گرها) را اختصاص می‌دهد و مصرف‌کننده (مثل بخش دیگری از کرنل یا userspace) فرض می‌کند که این منابع تا زمانی که خودش از آنها آزاد نشده‌اند معتبر هستند. اما در دنیای مدرن سخت‌افزارهای hot-pluggable (مثلاً USB یا دیگر دستگاه‌هایی که می‌توانند هر لحظه جدا شوند)، این فرض دیگر همیشه درست نیست. اگر منبع در حین استفاده آزاد شود، ممکن است منجر به خطاهای خطرناک مثل Use-After-Free (UAF) شود.

زیرساخت revocable resource management این مشکل را با ارائه یک مدل weak reference حل می‌کند:

• منابع توسط revocable_provider نگه داشته می‌شوند و مصرف‌کنندگان از آن با یک revocable handle استفاده می‌کنند، که در حقیقت یک اشاره‌گر امن به منبع است.
• هنگامی که مصرف‌کننده می‌خواهد به منبع دسترسی یابد، از APIهایی مثل revocable_try_access استفاده می‌کند که قبل از استفاده بررسی می‌کند که منبع هنوز معتبر است. اگر منبع قبلاً لغو یا آزاد شده باشد، این API به‌جای دسترسی نامعتبر، مقدار NULL یا خطای مناسب برمی‌گرداند، و از crash جلوگیری می‌کند.
• وقتی تحویل‌دهنده (provider) نیاز دارد منبع را لغو کند (مثلاً دستگاه جدا شده است)، با revocable_provider_revoke نشان می‌دهد که منابع دیگر معتبر نیستند و صبر می‌کند تا همه مصرف‌کنندگان در حال استفاده به پایان برسند.

این مدل می‌تواند بسیار مفید باشد در شرایطی که:

• منابع ممکن است در هر زمانی از دستگاه حذف یا آزاد شوند (مثلاً درایور دستگاه hot-plug)،
• بخشی از کد ممکن است همچنان بخواهد از آن منبع استفاده کند،
• یا سیستم‌های container و سرور که نیاز دارند منابع را بدون crash و به صورت کنترل‌شده پس بگیرند.

۷. OPEN_TREE_NAMESPACE برای بهبودهای امنیتی و عملکردی در کانتینرها

یک syscall جدید برای باز کردن namespaceهای tree (ساختار درختی فایل‌سیستم) که امنیت کانتینرها (مثل Docker) را افزایش می‌دهد و عملکرد را با جداسازی بهتر بهبود می‌بخشد.

ویژگی OPEN_TREE_NAMESPACE که در هسته لینوکس برای open_tree syscall معرفی شده، یک بهبود ساختاری در مدیریت namespaceهای mount است که هدفش هم افزایش کارایی در ایجاد و مدیریت کانتینرها و هم کاهش بخشی از هزینه‌های غیرضروری در این فرآیند می‌باشد. این تغییر در مسیر اصلی توسعه برای کرنل لینوکس نسخه ۷.۰ ادغام شده است.

به صورت کاربردی: تا پیش از این، هنگامی که یک container runtime (مثل Docker یا Podman) قصد ایجاد یک namespace مجزا برای کانتینر داشت، معمولاً از CLONE_NEWNS استفاده می‌کرد که کل mount namespace فعلی را کپی می‌کند تا سپس با استفاده از pivot_root ریشه فایل‌سیستم جدید را نصب کند. این کار باعث می‌شود با جدول mountهای بزرگ یا در زمان ایجاد تعداد زیادی کانتینر هم‌زمان، قفل‌های داخلی namespace شدیداً محتوا شود و باعث تاخیر در راه‌اندازی و استفاده از منابع شود.

با افزودن OPEN_TREE_NAMESPACE به open_tree، رفتار این سیستم‌کال به شکل زیر تغییر می‌کند:

• به جای کپی کردن کل mount namespace والد، فقط درخت mount خاصی که قرار است برای کانتینر استفاده شود کپی می‌شود، یعنی تنها بخش موردنیاز برای rootfs کانتینر استخراج می‌شود.
• این فراخوانی سپس یک file descriptor مربوط به namespace جدید mount برمی‌گرداند (نه یک mount منفصل). این به این معناست که کارهای مرسوم unshare(CLONE_NEWNS) و pivot_root در یک syscall واحد جمع شده‌اند.
• نتیجه این است که ایجاد namespaceهای جدید سریع‌تر و با overhead کمتر انجام می‌شود (در آزمایش‌ها حدود افزایش throughput نزدیک به ۴۰٪ در ایجاد کانتینرها دیده شده است).

مزایای این طراحی:

• عملکرد بهتر و مقیاس‌پذیری بالاتر برای ابزارهای مدیریت کانتینر که هزاران کانتینر را به‌طور هم‌زمان راه‌اندازی می‌کنند، چون contention روی semaphoreهای namespace کاهش می‌یابد.
• سادگی بیشتر در کدهای سطح کاربر و در runtimeها؛ چون دیگر نیازی به اجرای چند syscall و مدیریت دستی pivot_root نیست.
• به دلیل اینکه namespace جدید به‌عنوان fd بازگشت داده می‌شود، می‌شود با استفاده‌های امن‌تر و محدودتر از آن namespaceها در سطح امنیتی کار کرد که در برخی سناریوهای کانتینری می‌تواند حملات دسترسی اشتباه به mountهای والد را کاهش دهد.

۸. CAKE_MQ برای تطبیق SCH_CAKE با سیستم‌های چند هسته‌ای مدرن (در کد شبکه)

SCH_CAKE یک الگوریتم صف‌بندی شبکه برای کنترل ترافیک است. CAKE_MQ نسخه چندصف (multi-queue) آن است که برای CPUهای چند هسته‌ای بهینه شده تا پهنای باند بهتر مدیریت شود و تأخیر کاهش یابد.

ویژگی CAKE_MQ که برای SCH_CAKE در هسته لینوکس در حال ادغام شدن است، یک بهبود ساختاری در صف‌بندی شبکه (qdisc) برای بهینه‌سازی عملکرد روی سخت‌افزارهای چند هسته‌ای مدرن است. این توسعه هدفش برطرف کردن محدودیت‌های نسخه‌ی تک‌صف (single-queue) SCH_CAKE در هنگام کار با سرعت‌ها و معماری‌های سخت‌افزاری جدید است.

به صورت خلاصه، CAKE_MQ معماری SCH_CAKE را به صورتی بازطراحی می‌کند که از چند صف سخت‌افزاری (multi-queue) پشتیبانی کند. SCH_CAKE خود یک الگوریتم صف‌بندی و کنترل ترافیک شبکه است که برای کاهش تاخیر، به حداقل رساندن پدیده‌ی bufferbloat و مدیریت عادلانه‌ی پهنای باند طراحی شده. CAKE_MQ نسخه‌ی “چند-صف aware” آن است به این صورت که:

• به جای این‌که کل shaping روی یک هسته‌ی CPU یا یک صف انجام شود (مثل نسخه‌ی معمولی sch_cake)، CAKE_MQ برای هر صف سخت‌افزاری شبکه (TX queue) یک نمونه‌ی CAKE نصب می‌کند و ترافیک را بین آن‌ها تقسیم می‌کند،‌ که باعث می‌شود کار روی چندین هسته‌ی CPU به‌طور همزمان اجرا شود و bottleneck تک هسته‌ای از بین برود.
• همه‌ی نمونه‌های CAKE که روی صف‌ها نصب می‌شوند، تنظیمات مشترکی دارند که فقط از طریق یک شیء پدر (parent qdisc) قابل تغییر است. این یعنی پیکربندی همچنان متمرکز و ساده باقی می‌ماند و لازم نیست برای هر صف جداگانه پارامترها را دستکاری کنید.
• CAKE_MQ باعث می‌شود که rate shaper (کنترل‌کننده‌ی نرخ ارسال/دریافت) روی یک رابط شبکه با چندین صف سخت‌افزاری رفتار صحیح و مقیاس‌پذیری بهتر داشته باشد، حتی در سرعت‌های بالای لینک یا محیط‌های دیتاسنتری که CPUهای چند هسته‌ای دارند.

کاربرد عملی این تغییر این است که وقتی روی سرور یا روتر لینوکسی ترافیک سنگین شبکه دارید یا ترافیک روی چندین صف سخت‌افزاری انجام می‌شود، CAKE_MQ می‌تواند بهره‌وری بالاتر، تاخیر کمتر و مدیریت بهتر پهنای باند نسبت به نسخه‌ی قدیمی sch_cake ارائه دهد، چون کار صف‌بندی به شکل چند-هسته‌ای انجام می‌شود (به جای این‌که روی یک هسته متوقف بماند).

۹. جایگزینی کد caching بیشتر هسته لینوکس با Sheaves برای “امیدوارانه” عملکرد بهتر

Sheaves یک ساختار داده جدید برای کشینگ (ذخیره موقت داده‌ها) است که جایگزین روش‌های قدیمی می‌شود. هدف افزایش سرعت دسترسی به داده‌ها در هسته است، هرچند هنوز در مرحله آزمایشی است.

این تغییر مشخصاً بخشی از کار روی allocator کشینگ SLUB است، یعنی زیرسیستمی که مسئول مدیریت حافظه و کش کردن اشیای کوچک در هسته است. راه‌حل‌هایی مثل Sheaves به‌عنوان یک لایه‌ی کش per CPU با آرایه‌ها وارد شده‌اند تا عملکرد را در سیستم‌های چند هسته‌ای بهتر کنند. در اصل هدف چنین ساختاری این است که هر هسته‌ی CPU بتواند اشیایی که قبلاً آزاد شده‌اند را بدون رقابت (contend) روی یک منبع مشترک مجدداً بگیرد، که در نتیجه قفل‌ها و هم‌زمانی پیچیده‌ی SLUB را کاهش می‌دهد.

در حال حاضر Sheaves از مرحله‌ی opt-in (انتخابی) خارج شده و در مسیر توسعه است تا بیشتر caches در SLUB به آن منتقل شود — به‌جای استفاده از «partial slabs per CPU» که قبلاً شایع بود. این کار به برنامه‌نویسان و معماری جاری کمک می‌کند که با کد ساده‌تر، قفل‌گذاری کمتر و رفتار بهتر روی تعداد زیادی هسته، حافظه را مدیریت کنند.

نکات کلیدی:

• Sheaves چیست؟ Sheaves یک لایه‌ی کشینگ مبتنی بر آرایه‌های per CPU است که به طور مستقیم از SLUB allocator در هسته استفاده می‌کند و به دنبال کاهش contention و پیچیدگی در مدیریت cacheهاست. هر CPU می‌تواند از cacheهای خودش استفاده کند بدون اینکه دائماً بر سر دسترسی به منابع مشترک رقابت کند.
• هدف نهایی جایگزینی بیشتر کدهای کشینگ است: در نسخه‌های قبلی Sheaves فقط برای برخی cacheها فعال بود، اما توسعه‌دهندگان قصد دارند تقریباً همه‌ی cacheهای CPU (به‌جز چند مورد ابتدایی bootstrap) را با Sheaves جایگزین کنند و سپس کدهای قدیمی slab partial CPU را حذف نمایند.
• چرا این کار انجام می‌شود؟ دلیل اصلی این تغییر آن است که کدهای قدیمی slabs و caching در SLUB پیچیده و مشکل‌ساز در محیط‌های چند هسته‌ای عظیم هستند؛ با Sheaves، کد ساده‌تر، احتمال برخورد (contention) پایین‌تر، و در نتیجه عملکرد بهتری به‌ویژه در سرورها و بارهای چندنخی سنگین فراهم می‌شود.
• آیا عملکرد بهتر خواهد بود؟ توسعه‌دهندگان به صراحت گفته‌اند که Sheaves ممکن است به بهبود عملکرد امیدوارکننده منتهی شود (به‌ویژه در سیستم‌های بزرگ با هسته‌های متعدد)، اما هنوز نتایج کامل یا استانداردی برای عملکرد نهایی منتشر نشده است.
• وضعیت فعلی در هسته: Sheaves ابتدا در Linux 6.18 به صورت opt-in پذیرفته شد و اکنون توسعه‌دهندگان در شاخه‌ی «slab/for-next» در حال گسترش آن هستند تا در چرخه‌ی بعدی (معمولاً Linux 7.0) بیشتر cacheها را تحت پوشش Sheaves قرار دهند.

۱۰. تمرکز فقط روی مدل‌های preemption کامل و lazy برای معماری‌های CPU مدرن

Preemption مکانیزمی است که اجازه می‌دهد هسته فرآیندها را قطع کند و اولویت‌بندی کند. مدل‌های کامل (full) و تنبل (lazy) فقط وقتی لازم برای CPUهای جدید بهینه می‌شوند تا تعادل بین پاسخ‌دهی و کارایی ایجاد شود.

در نسخه‌های جدید هسته لینوکس (مثلاً 7.0) توسعه‌دهندگان در حال بازتنظیم مدل‌های Preemption هستند تا فقط روی دو مدل تمرکز شود که برای پردازنده‌های مدرن بهترین تعادل بین پاسخ‌دهی و کارایی را فراهم می‌کنند: Preemption کامل (full) و Preemption تنبل (lazy). این انتخاب موجب حذفِ مدل‌های قدیمی (مثل none و voluntary) برای اکثر معماری‌های CPU می‌شود و باعث می‌گردد هسته روی گزینه‌هایی که به‌طور مؤثرتر با سخت‌افزارهای چند هسته‌ای امروزی کار می‌کنند، متمرکز بماند.

نکات فنی مهم:

• Preemption کامل (full): به این معناست که scheduler می‌تواند تقریباً در هر نقطه از کد کرنل، حتی در بخش‌های غیرتعطیلی (non-voluntary)، یک task را قطع (preempt) کند تا task دیگری با اولویت بالاتر اجرا شود. این مدل باعث پاسخ‌دهی بهتر سیستم به وقایع خارجی و تعامل با کاربر می‌شود، اما هزینه‌ی پردازشی بیشتری دارد (چون اغلب باید context switch انجام شود).
• Preemption تنبل (lazy): مدلی است که می‌کوشد تعادل بین full و voluntary برقرار کند: scheduler هنوز امکان preemption را دارد، ولی در حالت SCHED_NORMAL preemption را تا زمانی که در نقطه‌ی مناسب (مثلاً tick یا زمان‌بندی بعدی) باشد به تأخیر می‌اندازد، در حالی که برای کلاس‌های Realtime (مثل RR/FIFO/DEADLINE) رفتار نزدیک به full دارد. این کار باعث می‌شود که هزینه‌های preemption زیاد در مسیرهای معمولی کاهش یابد و در عین حال latency برای taskهای حساس نیز حفظ شود.

این تمرکز جدید روی دو مدل Preemption اصلی در کرنل با هدف این انجام می‌شود که:

• مدیریت بهتر CPU زمان‌بندی‌‌ها روی سخت‌افزارهای چند هسته‌ای و پیچیده‌ی امروز (مثل x86_64، ARM64، POWER، RISC V و دیگر معماری‌ها) انجام شود،
• هزینه‌های اضافی preemption بی‌مورد در بارهای کاری معمولی کاهش یابد،
• و همچنان پاسخ‌دهی مناسب برای بارهایی که به اولویت و تاخیر کم نیاز دارند فراهم گردد.

۱۰. به‌روزرسانی‌های DT اپل برای پورت‌های USB Type-C در مک‌های اخیر

DT (Device Tree) فایلی است که سخت‌افزار را توصیف می‌کند. این به‌روزرسانی‌ها پشتیبانی بهتر از USB-C در مک‌های اپل (مثل شارژ و انتقال داده) را در لینوکس اضافه می‌کنند.

در کرنل لینوکس جدید (به‌خصوص در مسیر ادغام تغییرات برای نسخه‌های ۶.20/۷.0)، مجموعه‌ای از به‌روزرسانی‌های Device Tree (DT) مخصوص دستگاه‌های Apple Silicon به‌اضافه‌ی پشتیبانی بهتر از پورت‌های USB-C در سخت‌افزارهای مک عرضه شده است. این به‌روزرسانی‌ها به‌طور خاص شامل توصیف دقیق‌تر و کامل‌تر USB2/USB3 و درگاه‌های USB-C در فایل‌های DT برای سیستم‌های Apple Silicon بوده‌اند، که بخش مهمی از توانمندسازی پشتیبانی USB روی مک‌های جدید در لینوکس محسوب می‌شود.

چگونگی این به‌روزرسانی‌ها:

• افزودن گره‌های لازم برای USB3 و USB-C در فایل‌های Device Tree: این کار بخش بزرگی از تغییرات است و اجازه می‌دهد تا کانال‌های USB2.0 و USB3.x که در دستگاه‌های Apple Silicon وجود دارد برای پورت‌های USB-C به‌صورت درست شناسایی و پیکربندی شوند.
• این فایل‌های DT به توسعه‌دهندگان کرنل اطلاعات دقیق سخت‌افزاری می‌دهند (مانند اتصال USB-C PHY به کنترلر USB)، کاری که پیش از این به‌صورت downstream (مثلاً در پروژه‌های مستقل مثل Asahi Linux) نگه‌داشته می‌شد و اکنون در مسیر upstream برای هسته اصلی هم در نظر گرفته شده است.
• بخشی از این به‌روزرسانی‌ها شامل پشتیبانی از PHY مخصوص Apple Type-C (که مسئول کارکرد USB2/USB3، USB4/Thunderbolt و DisplayPort از طریق همان پورت USB-C است) نیز در حال ادغام شدن هستند، اگرچه بخش‌های دیگر برای حالت‌های پیشرفته‌تر (مثل Alt Mode برای ویدئو) هنوز کامل نشده‌اند.

در عمل، این تغییرات باعث می‌شود که وقتی کرنل لینوکس روی مک‌های مبتنی بر Apple Silicon اجرا می‌شود، پورت‌های USB-C به‌طور صحیح شناخته، مقداردهی اولیه و فعال شوند (نه اینکه به‌خاطر نبود پیکربندی دقیق در DT یا عدم پشتیبانی از PHY به‌درستی کار نکنند).

۱۱. بهبودها برای ساخت هسته با Rust و LTO

Rust زبانی امن‌تر برای نوشتن کد هسته است. LTO (Link-Time Optimization) بهینه‌سازی در زمان لینک است. این بهبودها ساخت هسته را سریع‌تر و ایمن‌تر می‌کنند.

در مسیر ترکیب Rust و بهینه‌سازی زمان لینک (LTO) در ساخت هسته لینوکس، چند بهبود فنی مشخص در حال ادغام شدن است که هدفش هم افزایش ایمنی کد و هم افزایش کارایی ساخت و اجرای هسته است، به ویژه در چرخه‌ی توسعه‌ی Linux 6.20/7.0.

اول اینکه پروژه‌ی Rust for Linux اکنون دیگر فقط یک آزمایش نیست؛ Rust رسماً به‌عنوان یکی از زبان‌های پذیرفته‌شده برای توسعه کد هسته (کنار C و اسمبلی) شناخته می‌شود. این بدان معناست که ماژول‌ها و درایورهای ایمن‌تر به‌تدریج به هسته وارد می‌شوند و از بررسی‌های زمان کامپایل و مدل مالکیت Rust برای کاهش خطاهای حافظه بهره می‌برند.

برای ادغام LTO (Link Time Optimization) با Rust در هسته، یک سلسله پچ در حال پذیرفته‌شدن است که به Rust اجازه می‌دهد تابع‌های کمکی نوشته‌شده در C را هنگام ساخت LTO «درون‌خط» (inline) کند. در وضعیت فعلی (بدون این پچ‌ها)، کامپایلر LLVM به دلیل تفاوت‌های گزینه‌های تولید کد بین بخش‌های Rust و C، این inlining را انجام نمی‌دهد. افزوده شدن نشانه‌گذاری‌هایی مثل __rust_helper به این تابع‌ها باعث می‌شود که وقتی هسته با LTO ساخته می‌شود، LLVM بتواند آنها را مثل کد Rust داخل‌خط کند. این موضوع می‌تواند به بهینه‌سازی بهتر و واحدهای کد کوچکتر/سریع‌تر در نتیجه‌ی لینک منتهی شود.

در کنار این، پشتیبانی Rust در ساخت هسته به‌طور گسترده‌تر بهبود یافته است تا زیرساخت‌های مورد نیاز Rust، (مثل bindings و ابزارهای build)، با LTO و LLVM/Clang سازگارتر شوند. استفاده از LLVM/Clang برای ساخت کل هسته (نه فقط بخش Rust) سبب می‌شود که بهینه‌سازی‌های LTO در سراسر هسته اعمال شود (و نه فقط در بخش‌های مجزا)، که هم زمان اجرا و هم اندازه‌ی نهایی باینری را بهبود می‌بخشد.

۱۲. پشتیبانی نمایشگر Qualcomm Snapdragon 8 Elite Gen 5

اضافه کردن درایور برای نمایشگر چیپست Snapdragon 8 Elite Gen 5 برای گوشی‌ها و تبلت‌ها تا گرافیک بهتر در دستگاه‌های مبتنی بر ARM کار کند.

ویژگی پشتیبانی از نمایشگر چیپست Qualcomm Snapdragon 8 Elite Gen 5 در کرنل لینوکس به‌معنای اضافه شدن درایورها و پشتیبانی رسمی برای پنل‌های نمایش و بخش‌های گرافیکی این SoC در مسیر اصلی هسته است. این پشتیبانی با مجموعه‌ای از به‌روزرسانی‌های زیرسیستم MSM (Qualcomm Mobile Display / Graphics) وارد درخت توسعه هسته شده و در حال آماده شدن برای ادغام در نسخه‌های ۷.۰ لینوکس می‌باشد.

در حالت دقیق‌تر:

• در هسته‌های پیش از Linux 7.0 بخش initial GPU support برای نسل جدید GPUهای Adreno (مثل Adreno 840 – که همراه با Snapdragon 8 Elite Gen 5 ارائه می‌شود) وجود داشت، اما پشتیبانی کامل از واحد نمایش (display controller) هنوز ناقص بود. با به‌روزرسانی‌های جدید در درایور Qualcomm MSM DRM، کرنل اکنون نمایشگر دستگاه‌های مبتنی بر Snapdragon 8 Elite Gen 5 را نیز مدیریت می‌کند.
• این تغییر اساساً نمایش تصویر روی صفحه (framebuffer/DRM) را فعال می‌کند، یعنی وقتی لینوکس روی دستگاهی با این SoC اجرا می‌شود، نمایشگر به‌طور مستقیم کار خواهد کرد (به جای این‌که صرفاً بوت در کنسول خام انجام شود یا کاربر نیاز به درایورهای غیر رسمی داشته باشد).
• علاوه بر این، در کنار پشتیبانی از نمایش، افزودن پشتیبانی از ویژگی‌های مرتبط با GPU (مثل gamma correction و UBWC (Universal Bandwidth Compression)) نیز در همین مجموعه پچ‌ها انجام شده است که به بهینه‌سازی نمایش و انتقال داده‌ی تصویر در سخت‌افزار کمک می‌کند.

۱۳. چند به‌روزرسانی مرتبط با پشتیبانی گرافیکی اینتل

چند به‌روزرسانی مرتبط با پشتیبانی گرافیکی اینتل در کرنل لینوکس که در مسیر ادغام برای نسخه‌های بعدی (معمولاً Linux 6.20/7.0) دیده شده‌اند عبارت‌اند از:

• پشتیبانی از به‌روزرسانی firmware GPU اینتل روی پلتفرم‌های غیر x86: درایور Intel Xe در هسته لینوکس از ابتدا طوری طراحی شده که کمتر وابسته به معماری x86 باشد (بر خلاف درایور قدیمی i915) و این امکان را فراهم می‌کند که کارت‌های گرافیک اینتل حتی روی سیستم‌های ARM64 یا RISC V هم کار کنند. در حال حاضر تا حدی پشتیبانی از به‌روزرسانی firmware برای GPUهای گسسته‌ی اینتل روی این معماری‌های غیر x86 در حال اضافه شدن است، به‌طوری که پچ‌هایی در شاخه‌های مربوط به char/misc برای Linux 7.0 آماده شده‌اند که امکان انتقال و به‌روزرسانی firmware کارت‌های اینتل را روی این سیستم‌ها فعال می‌کنند. این کار با جدا کردن وابستگی‌های رابط مدیریت MEI از درایور GPU انجام می‌شود تا کد بتواند روی سیستم‌های غیر x86 هم اجرا شود.
• گزارش گسترده‌تر دما برای کارت‌های گرافیک اینتل: در درایور Intel Xe در هسته لینوکس تغییراتی اعمال می‌شود تا اطلاعات دمایی بیشتری از کارت‌های گرافیک در اختیار قرار گیرد. علاوه بر دمای کلی GPU، اکنون سنسورهایی اضافه می‌شوند که دمای بخش‌های متفاوت (مثل کنترلر حافظه (memory controller)، دمای PCIe، و همچنین حدود دمای بحرانی و shutdown) را از طریق رابط مانیتورینگ سخت‌افزاری HWMON در sysfs در دسترس می‌گذارند. این امکان باعث می‌شود که نرم‌افزارهای سطح کاربر (مثل lm_sensors یا ابزارهای مانیتورینگ) بتوانند جزئیات بیشتری درباره وضعیت حرارتی GPU گزارش دهند، که برای مدیریت حرارت، جلوگیری از Overheating و اورکلاک ایمن مفید است.
• تغییر رفتار D3cold برای GPUهای نسل Battlemage: حالت D3cold (که یکی از عمیق‌ترین حالات صرفه‌جویی انرژی برای GPU در استاندارد ACPI است) قبلاً برای همه GPUهای Intel Arc Battlemage مسدود شده بود، چون روی بعضی سخت‌افزارها هنگام بازگشت از حالت D3cold به D0 (فعال) مشکلات پایداری ایجاد می‌کرد. در مسیر ادغام برای Linux 7.0، این محدودیت برداشته شده و D3cold فقط روی پلتفرم‌های شناخته‌شده به‌عنوان مشکل‌دار (در حال حاضر فقط برخی مدل‌های ASUS NUC) غیرفعال می‌شود، در حالی که روی سیستم‌های دیگر این حالت انرژی مجدداً فعال خواهد شد تا مصرف انرژی بهتر مدیریت شود.

۱۴. سایر ویژگی‌های قابل توجه

• کد SVM چنددستگاهی اینتل آماده برای هسته لینوکس ۶.۲۰~۷.۰: SVM یا Shared Virtual Memory قابلیت اشتراک حافظه بین CPU و GPU را فراهم می‌کند. این به این معنی است که داده‌ها می‌توانند بدون نیاز به کپی بین حافظه CPU و GPU استفاده شوند، که باعث کاهش تأخیر و افزایش کارایی می‌شود. نسخه چنددستگاهی این قابلیت را برای سیستم‌هایی با چند GPU بهبود می‌دهد و برای محاسبات سنگین (مثل هوش مصنوعی یا رندرینگ) مفید است.
• پشتیبانی multi-queue برای Intel Crescent Island: Crescent Island احتمالاً یک پلتفرم جدید اینتل برای CPU/GPU یا چیپ‌ست است. Multi-queue به معنای داشتن چند صف برای عملیات ورودی/خروجی است، که باعث می‌شود سیستم‌های چند هسته‌ای بتوانند همزمان داده‌ها را سریع‌تر پردازش کنند و کارایی شبکه و ذخیره‌سازی بهبود یابد.
• پشتیبانی نمایشگر Intel Nova Lake: Nova Lake نسل بعدی CPU/GPU اینتل است. این ویژگی درایور نمایشگر (display driver) را برای Nova Lake فراهم می‌کند تا خروجی گرافیکی و نمایش تصویر بدون مشکل کار کند، مخصوصاً برای برنامه‌های چندرسانه‌ای و بازی‌ها.
• پشتیبانی non-root برای ابزار intel-speed-select: این ابزار امکان تنظیم سرعت هسته‌های CPU اینتل را می‌دهد. اکنون کاربران بدون دسترسی ادمین می‌توانند از آن استفاده کنند، که امنیت را بالا می‌برد و خطر تغییر ناخواسته تنظیمات سیستم را کاهش می‌دهد.
• رفع پشتیبانی large pages در درایور Nouveau DRM برای NVK: Nouveau یک درایور متن‌باز برای کارت‌های گرافیک NVIDIA است. Large pages یا صفحات حافظه بزرگ‌تر، دسترسی به حافظه را سریع‌تر می‌کنند. NVK، درایور Vulkan برای Nouveau، با این تغییر عملکرد گرافیکی برنامه‌های ۳D و بازی‌ها را بهبود می‌دهد.
• پشتیبانی cTGP برای درایور Uniwill: cTGP یا configurable Total Graphics Power به کاربر اجازه می‌دهد توان مصرفی GPU لپ‌تاپ‌های Uniwill/TUXEDO را تنظیم کند. این ویژگی برای لپ‌تاپ‌های گیمینگ یا دستگاه‌هایی که می‌خواهند بین عملکرد و عمر باتری تعادل ایجاد کنند، مفید است.
• پشتیبانی نظارت سنسور برای مادربردهای ASUS دسکتاپ: اضافه کردن درایورکه امکان خواندن داده‌های سنسورها (مثل دما، ولتاژ و سرعت فن) را فراهم می‌کند. این داده‌ها برای نظارت بر سلامت سیستم و اورکلاکینگ ضروری هستند.
• آستانه‌های هدف فن و دما برای لپ‌تاپ Framework 13: Framework یک لپ‌تاپ مدولار است. این ویژگی به کاربر امکان می‌دهد دما و عملکرد فن را به صورت دقیق کنترل کند، که به خنک‌کاری بهتر و کاهش صدای فن کمک می‌کند.
• پشتیبانی یکپارچگی جریان کنترل shadow stack برای RISC-V: RISC-V یک معماری CPU متن‌باز است. Shadow stack یک مکانیزم امنیتی برای جلوگیری از حملات overflow و تغییر جریان اجرای کد است. این ویژگی امنیت پردازش را در برنامه‌ها بالا می‌برد.
• ارسال دسته‌ای I/O برای ublk: ublk یک درایور بلوک در فضای کاربر است. Batch I/O یا ارسال دسته‌ای داده‌ها باعث کاهش overhead و افزایش سرعت پردازش داده‌ها، به ویژه برای ذخیره‌سازی، می‌شود.
• بهبود polling IOPOLL در IO_uring: IO_uring رابط سریع I/O در لینوکس است. IOPOLL (بدون انتظار) polling تأخیر عملیات I/O را کاهش می‌دهد و عملکرد برنامه‌های پرسرعت، (مثل سرورهای وب و پایگاه داده) بهتر می‌شود.
• پشتیبانی بلندگو لپ‌تاپ LG Gram Style 14: اضافه کردن درایور صوتی جدید برای این مدل لپ‌تاپ تا خروجی صدا درست کار کند و کیفیت صوت بهبود یابد.
• حذف کد قدیمی API mount برای بلوک لینوکس: API قدیمی mount برای اتصال فایل‌سیستم‌ها استفاده می‌شد. حذف آن باعث ساده‌تر شدن هسته و کاهش کدهای غیرضروری می‌شود و هسته را مدرن‌تر می‌کند.
• پشتیبانی رابط صوتی USB Focusrite Forte: اضافه کردن درایور برای این دستگاه حرفه‌ای USB امکان استفاده از آن در لینوکس را فراهم می‌کند. این ویژگی برای موسیقی‌دانان و استودیوها کاربرد حیاتی دارد.

“`