Linus Torvalds: Linux 6.1

Kernel

Megjelent a 6.1-es Linux kernel végleges kiadása:

From Linus Torvalds <>
Date Sun, 11 Dec 2022 14:44:24 -0800
Subject Linux 6.1

 

 
So here we are, a week late, but last week was nice and slow, and I'm
much happier about the state of 6.1 than I was a couple of weeks ago
when things didn't seem to be slowing down.

Of course, that means that now we have the merge window from hell,
just before the holidays, with me having some pre-holiday travel
coming up too. So while delaying things for a week was the right thing
to do, it does make the timing for the 6.2 merge window awkward.

That said, I'm happy to report that people seem to have taken that to
heart, and I already have two dozen pull requests pending for tomorrow
in my inbox. And hopefully I'll get another batch overnight, so that I
can try to really get as much of the merge window done with early. We
all want to have a calm holiday season.

And because of that "we all want to have a calm holiday season", I
want to re-iterate that I'm going to be pretty strict about the merge
window rules. The rules are that the pull requests sent to me during
the merge window should have been ready _before_ the merge window, and
have seen some time in linux-next. No last-minute batch of
experimental new development that hasn't been seen by our test
automation.

So to make my life easier, I will just drop any pull requests that
come in late, or that look like they haven't been in linux-next. This
time of year, we're all going to be much happier to deal with the
stress of the season _without_ having to deal with the stress of any
late development. So if you already realize that work hasn't been in
linux-next, let's just all agree to not even send me the pull request
at all, and we'll all be happy with the calm end-of-the-year season.
Ok?

Anyway,  I think I've harped on that enough, let's just enjoy this
release and the upcoming festivities. As can be seen from the shortlog
below, last week really was very quiet, and it's mainly a few
last-minute fixes mostly dominated by drivers (networking in
particular, but there's some media, HID and GPU noise in there too).

              Linus

( trey | 2022. 12. 12., h – 07:54 )

Szerkesztve: 2022. 12. 12., h – 07:54

Contents

  1. Prominent features
    1. Initial support for the Rust programming language
    2. Multi-gen LRU
    3. Memory tiering improvements
    4. BPF features: BPF-specific memory allocator, panic helper
    5. KMSAN, a kernel memory sanitizer
    6. Support for KCFI, a forward-edge control-flow integrity scheme
    7. Maple trees, to replace the existing red-black trees
  2. Core (various)
  3. File systems
  4. Memory management
  5. Block layer
  6. Tracing, perf and BPF
  7. Virtualization
  8. Security
  9. Networking
  10. Architectures
    1. ARM
    2. X86
    3. LOONGARCH
    4. RISCV
    5. POWERPC
    6. S390
    7. MIPS
    8. M68K
    9. MICROBLAZE
    10. UM
    11. XTENSA
    12. ALPHA
  11. Drivers
    1. Graphics
    2. Power Management
    3. Storage
    4. Drivers in the Staging area
    5. Networking
    6. Audio
    7. Tablets, touch screens, keyboards, mouses
    8. TV tuners, webcams, video capturers
    9. Universal Serial Bus
    10. Serial Peripheral Interface (SPI)
    11. Watchdog
    12. Serial
    13. CPU Frequency scaling
    14. Voltage, current regulators, power capping, power supply
    15. Pin Controllers (pinctrl)
    16. Multi Media Card (MMC)
    17. Memory Technology Devices (MTD)
    18. Industrial I/O (iio)
    19. Multi Function Devices (MFD)
    20. Inter-Integrated Circuit (I2C + I3C)
    21. Hardware monitoring (hwmon)
    22. General Purpose I/O (gpio)
    23. Leds
    24. DMA engines
    25. Cryptography hardware acceleration
    26. PCI
    27. Thunderbolt
    28. Clock
    29. PHY ("physical layer" framework)
    30. EDAC (Error Detection And Correction)
    31. Various
  12. List of Pull Requests
  13. Other news sites

trey @ gépház

( uid_6201 v | 2022. 12. 12., h – 08:27 )

Rust: This release includes some initial support; more support will be added in later releases.

Na ezt a minimumot a hétvégén megtapasztaltam. Viszont belekerült a Rust alrendszer és a minimum már működik.
A kernel fordul Rust résszel is is és Rust környezet hiányában csak a C részek is fordulnak. (Linus jogos kérése volt, hogy ne törje el a Rust a fordítást)

Rust-ban történő driver írására viszont csak a későbbi kernelverziók lesznek felkészítve.

( Raynes v | 2022. 12. 12., h – 12:20 )

Isten áldja érte, nagyon vártam már. Végre újra hajtani tudom az ASUS TUF laptop billentyűzet-háttérvilágításának a színét és módjait. Bár azért üröm az örömben, hogy dokumentáció nincs hozzá, így elég nehéz volt kisilabizálni, részben a korábbi faustus kernelmodul weblapjának a leírása alapján, pl. mode (0 - static color, 1 - breathing 2 - color cycle, 3 - strobe), speed (0 - slow, 1 - medium 2 - fast).

A /sys/devices/platform/asus-nb-wmi/leds/asus::kbd_backlight/kbd_rgb_mode_index csak annyit mond, hogy "cmd mode red green blue speed" formában kell megadni a paramétereket a ./kbd_rgb_mode felé. Megnéztem a kernelfában a drivernél /tmp/linux-6.1/drivers/platform/x86/asus-wmi.c fájlból is csak annyi derült ki, hogy decimális bájtokként kell megadni, míg korábban hexadecimálisban várta az RGB-t. A "cmd" még mindig nem egyértelmű, egyelőre 1-et adtam meg neki, így működik, de csak szerencsés találgatás volt, szintén a korábbi faustus kernelmodul leírása alapján:
kbbl_set: 1 write them permanently or 2 to write them temporarily

Erre a dokumentálásra rágyúrhatnának, mert a driver forrása nem említi, még csak kommentek szintjén sem derül ki. A kernel doksijába se került bele. Mindegy, működik, átalakítottam a korábbi szkriptemet, így már kényelmesen állítható. Sokat kellett rá várni, 5 hónapot. Igazából már a kód kész volt a laptop kiadása után, de csak ilyen külön telepíthető faustus DKMS kernelmodul formájában, ami csak a 4.x és 5.x kernelekhez jó, 6.x-nél már nem működött, de szándékosan. Úgy volt, hogy már a 6.0-ba bekerül, de csúsztak vele, oda nem fért be, így csak a 6.1-ben érkezett meg.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ez van. A gaming laptopok átka, hogy idő, míg normálisabb linuxos támogatás lesz hozzá. A 6.1-gyel ahogy nézem, a dedikált GPU is jobban szabályozható, pl. a GPU fan is lekérdezhető, állítható. Bár ez se tökéletes, mert X alatt az Fn+spéci funkciókat nem mindet viszi továbbra sem, 9 közülük nem működik. Erről nem tudom, hogy a kerneldriver hibája, vagy a libinput fogyatékossága egyelőre, már csak ez az apróság hiányzik, de enélkül meg tudok lenni, ezekből, ami kell, sxhkd-vel átdrótozom más billkombókra.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A gaming laptopok átka

Az utolsó 12..24 hónapban fejlesztet számítástechnikai eszközök átka. Főleg GPU fronton, de némely alaplapi chipset varázslatát se tudják ennyi idő alatt lekövetni, megfelelő számú visszajelzés alapján kitesztelni.
Szervereknél az egy előny, hogy ott viszonylag egységalkatrészekből építkeznek. Kivéve ha nem. Volt olyan, hogy szervernél is tesztverziós disztrót kellett első évben használnom, mert a stabilban valami chipset alapfunkció támogatás hiányzott. Aztán következő évre a disztró stabil lett és a probléma végleg elfelejthető lett.

Van benne igazság, de nem teljesen. Az Intel és az AMD manapság már előre dolgozik, a legtöbb CPU, GPU, Wi-Fi, stb. drivert előre fejlesztik bele a kernelbe, hogy már termékrajtra használható legyen. Nem úgy megy, mint néhány éve, hogy lemaradásba kerülnek bele ezek. Viszont a laptopgyártók gyakran nem ennyire szorgosak, ott várni kell. Főleg az ASUS-nál, ahol maga a cég nem fejleszt linuxos drivereket, hanem kiadja a hardverspecifikációkat lelkes magánamatőröknek, és ők fejlesztik, ha kész van, küldik be a fő kernelfába. Lenovo, Dell egy fokkal jobb, a HP viszont lefogadom, hogy rosszabb. Vegyes a kép emiatt még mindig. Egy részről simán mentek termékrajtra a Ryzen 6-7. gen, RX 6xxx-7xxx, Intel 13. gen, Intel ARC, stb., másrészről meg ugye ilyen fostos laptopoknál, meg USB-s hátvakaró, okosóra, stb. eszközöknél még jellemzően várni kell, az is változó, hogy mennyit.

Mivel amatőrök csinálják ez utóbbiakat, ezért dokumentációval, ezzel-azzal elmaradnak. Nem corporate meg production grade kódok ezek, csak ilyen megoldjuk legegyszerűbben típusú hackek. Nem lehet nekik felróni, ingyen dolgoznak. Azért 3 sort betehetett volna kommentbe vagy a kerneldoksiban, de ez van. Csak kódfejtést igényelt. Szerintem néhány nap, és az OpenRGB-t is hozzászögelik, akkor az egyszeri user is tudja használni GUI-ból.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Igen, terminálban próbáltam. Vagyis már nem kell, mert írtam rá két saját szkriptet, az egyik terminálos, a másik meg a hivatalos Aura billentyűre van bedrótozva, meghívja a gcolor3 nevű Gtk3 colorpickert, abban kiválasztom a színt (vagy színkeréken, vagy csúszkákkal vagy RGB-értékek beírásával, vagy mentett színek megnyitásával), kilépés után az aktiválja a másik szkriptet, ami meg ténylegesen átállítja az RGB-t. Nem volt nehéz megcsinálni. Az volt csak trükkös, hogy dokumentáció híján rájöjjek, hogy a sysfs kernelparaméter milyen formában várja az adatokat. Látszik, hogy kapkodva került be a kernelbe a driver, és nem maradt idő a dokumentálásra, még csak kommentek szintjén sem.

Sajnos néhány Fn+combo billentyű továbbra sem működik. Nem vészes, csak 9 ilyen van, amit úgyse nagyon használok, és ha használnék, át tudnám drótozni másra (snippet tool, fényerő fel/le: ez az egy, ami kéne, külső kijelzőre váltás, touchpad letiltása, sleep, airplane mód). Egyedül a fényerő volt, ami hiányzott, azt már 5 hónappal ezelőtt rádrótoztam a Super + Num plusz/mínusz (fényerő fel/le), illetve Ctrl + Super + Num plusz/mínusz (max/min. fényerő) billentyűkre. Snippet toolnak megfelelő screenshot programot nem használok, de a felparaméterezett scrot-ot hívom a PrtScr billentyűre, ami automatikusan ment egy megfelelő screenshot mappába, és a dátum/idő alapján nevezi el a fájlokat.

Amit nem értek, hogy 3 darab Fn+combo (Fn+F1-F3) mindig is működött, hogy azok miért mennek, míg a másik 9 darab (Fn+F4-F12) nem (a xev és a libinput sem látja őket). Rejtély, talán azokat a BIOS kezeli. Mindegy, nincs rá szükség, csak maximalista vagyok, és kicsit zavarja az OCD-met. Amúgy minden más működött mindig is, 6.1-es kernel nélkül is, pl. kapcsolgatás az integrált RX680M és a dedikált RTX 3060 Ti között, a dedikált GPU letiltása, proci TDP-jének állítása (Turbo, Silent, Balanced mód), ventilátormódok (alacsony, közepes, maximális) szabályozása. A helyzet még kicsit jobb is, mint Windowson, mert ott vaskos gyártói bloat, ún. Asus Aura program végezte ezeket, Linux alatt extra bloat nélkül a sysfs-ből szabályozható, írtam rá scripteket, amiket sxhkd-val drótoztam be különböző billentyűkre.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”