Megjelent a 6.14-es Linux kernel!

Kernel

A megszokotthoz képest néhány órás csúszással (Linus elfelejtette, hogy kiadás lenne aktuális), de kb. időben megjelent a 6.14-es Linux kernel:

Szóval hétfő reggel van (nos – nekem korán van, nem vagyok egy reggeli ember), és szeretnék valami jó kifogást találni arra, hogy miért nem csináltam meg a 6.14-es kiadást tegnap, a szokásos vasárnap délutáni kiadási ütemezésem szerint.

Szeretném azt mondani, hogy valami fontos, utolsó pillanatban felmerült dolog közbejött és késleltette a dolgot.

De nem. Ez egyszerűen csak tiszta hozzá nem értés.

Mert tegnap semmilyen utolsó pillanatos dolog nem történt, én pedig csak néhány teljesen független dolgot rendezgettem, hogy felkészüljek a beolvasztási időablakra. És közben egyszerűen teljesen elfelejtettem ténylegesen kiadni a verziót. D'oh.

Szóval igen, egy kicsit késve, teljesen ok nélkül, és nyilvánvalóan ez azt jelenti, hogy a beolvasztási időablak megnyílt. Nincs pihenés a gonoszoknak (vagy a hozzá nem értőknek).

Alább a múlt heti shortlog. Szép és kicsi – nemcsak hogy nem volt utolsó pillanatos probléma tegnap, de az egész múlt hét is elég nyugodt volt. A patch főként néhány AMD GPU frissítésből áll, és még azok is elég kicsik. A többi pedig véletlenszerű apró módosítás itt-ott.

Az eddigi beérkezett pull requestek alapján a 6.15 sokkal mozgalmasabb lesz.

( trey | 2025. 03. 25., k – 07:53 )

GingkoBiloba, Cavinton stb.

trey @ gépház

( trey | 2025. 03. 25., k – 08:06 )

Contents

  1. Prominent features
    1. NT synchronization primitive driver for faster games
    2. Btrfs RAID1 read balancing
    3. Support for uncached buffered I/O
    4. fsnotify file pre-access notification event
    5. dmem cgroup for better control of GPU memory resources
    6. FUSE support for io_uring-based communication
    7. Add amdxdna driver for AMD NPUs
    8. XFS reflink and reverse-mapping support for the realtime device
    9. NFSv4.2+ attribute delegation
    10. x86 TLB flushing scalability optimizations
  2. Core (various)
  3. File systems
  4. Memory management
  5. Block layer
  6. Tracing, perf and BPF
  7. Cryptography
  8. Virtualization
  9. Security
  10. Networking
  11. Architectures
  12. Drivers
    1. Graphics
    2. Power Management
    3. Storage
    4. Networking
    5. Audio
    6. Tablets, touch screens, keyboards, mouses
    7. TV tuners, webcams, video capturers
    8. Universal Serial Bus
    9. Serial Peripheral Interface (SPI)
    10. Watchdog
    11. CPU Frequency scaling
    12. Voltage, current regulators, power capping, power supply
    13. Real Time Clock (RTC)
    14. Pin Controllers (pinctrl)
    15. Memory Technology Devices (MTD)
    16. Industrial I/O (iio)
    17. Inter-Integrated Circuit (I2C + I3C)
    18. Hardware monitoring (hwmon)
    19. General Purpose I/O (gpio)
    20. Leds
    21. DMA engines
    22. Cryptography hardware acceleration
    23. PCI
    24. Thunderbolt
    25. Clock
    26. PHY ("physical layer" framework)
    27. EDAC (Error Detection And Correction)
    28. Various
  13. List of pull requests
  14. Other news sites

trey @ gépház

setsockopt() API-n nagyjából 33 éve beállítható egy socket prioritása SO_PRIORITY opcióval. Ilyenkor minden kiküldött csomagra beállításra kerül egy prioritás metaadat, IP csomagoknál a ToS headerbe is bekerül. Ez viszont az adott socket minden a küldött csomagjára érvényes.

Az újdonság a SO_PRIORITY és SO_RCVPRIORITY CMSG típus (néhol a CMSG-t ancillary message-nek vagy aux message-nek is hívják, a lényeg ugyanaz): csomagontként lehet megadni a proritási metaadatot. Ez akkor hasznos, ha van egy tunnelhez használt socket, amibe több stream van multiplexelve és ütemezésnél (pl. mqprio, taprio Qdisc-ek) fontos melyiknek mi a prioritása. Pl. vagyünk egy proxy-t, ami több bejövő kacsolatot multiplexál egy socketba, ahol a kapcsolatok más-más prioritással bírnak de amint egy socketen kereszül küldöd ki az összes beérkező csomagot, bukod a priorizálást (mert az csak a socket teljes egészére állítható, nem per-csomag).

Eddig erre workaround lehetett

1. több socket nyitása más-más prioritással,

2. eBPF-el átírni a prioritásokat per-packet megadható SO_MARK priortás alapján

3. esetleg csomagonként setsockoptolni más-más prioritást a teljes socketra (ez utóbbi szerintem elég gázos).

Egyik sem tökéletes, de azt gondolom akinek ilyesmi kellett ezekkel meg tudta/tudja oldani. Ettől függetlenül jó ha van direkt erre a célra kitalált API.

Én ipari témavezetője vagyok a kódhoz kapcsolódó szakdolgozatnak és az elején adtam pár általános tanácsot teszteléssel és lkml-el kapcsolatban (a levlistás fejlesztés nem triviális főleg nem elsőre :D). Maga a kód és az integrációs tesztek teljes egészében a szakdolgozó munkái.

( ricsip v | 2025. 03. 25., k – 08:46 )

Szerkesztve: 2025. 03. 25., k – 09:07

szép ez a tételesen kigyűjtött changelog, témakörökre bontva, látszik h. rendet tart a főgóré :)

( persicsb | 2025. 03. 25., k – 19:06 )

Ezzel se kerültünk közelebb ahhoz, hogy Snapdargon X1 Elite-en normálisan menjenek a hardverelemek.

Persze, elvileg a Qualcomm delegál erre embereket:
https://www.qualcomm.com/developer/blog/2024/05/upstreaming-linux-kerne…

Itt pedig követve van, hogy hogyan állnak a dolgok, érdemes a kommenteket olvasni:
https://discourse.ubuntu.com/t/ubuntu-24-10-concept-snapdragon-x-elite/…

Legújabb kernellel kell BT meg Wifi bináris, amit kívülről kell behúzni, van, ahol rossz a devicetree és felcserélődnek az audio csatornák.
De ez is jó komment, Thinkpad T14s:
 

Updates on T14s using more recent kernels:

Audio: The bluetooth audio problems I reported earlier (Airpods not working) are still present, however one other bluetooth speaker I tested works. So it seems to be specific to Airpods…? This is going to be difficult to debug.

WiFi: I don’t have wifi with 6.14.0-32. I rebooted three times, it never worked. I switched back to -30.