Vlákno názorů k článku Kernel panic s QR v Linuxu 6.12, neshody Rust vývojářů se správci částí jádra od radekm - Otázka je, zda je na tohle Rust vůbec...

Otázka je, zda je na tohle Rust vůbec vhodný jazyk.

• (1) Nejde to psát jen v Safe Rustu.
• (2) Unsafe Rust je ještě složitější než C. Hlavně kvůli pravidlům pro aliasing.
• (3) Kdyby to šlo psát jen v Safe Rustu: Safe Rust se specializuje na RAII, na správu paměti per jednotlivé objekty, což je IMO nevhodné pro výkonný kód. Kde je mnohem lepší se zabývat skupinami objektů.

(3) Kdyby to šlo psát jen v Safe Rustu: Safe Rust se specializuje na RAII, na správu paměti per jednotlivé objekty, což je IMO nevhodné pro výkonný kód. Kde je mnohem lepší se zabývat skupinami objektů.

Můžeš to prosím víc rozvést v kontextu jádra? Nerozumím, jak v jádře/driverech se více pracuje s alokací/uvolněním skupin objektů. Pod skupinami objektů si mám představit pole structů?

Díky.

> Nerozumím, jak v jádře/driverech se více pracuje s alokací/uvolněním skupin objektů.

V jádře k tomu slouží slab alokátory, které alokují objekty stejného typu u sebe a cachují zinicializované objekty, aby se nemusely pořád dokola inicializovat.

Navíc, když objekty daného typu nepotřebují deinicializaci, tak stačí paměť označit jako volnou a není třeba strukturu do hloubky procházet.

> Pod skupinami objektů si mám představit pole structů?

Třeba. Ale může to být i nějaký scratch buffer s krátkou životností, kde se alokují objekty různých typů a který se pak celý uvolní naráz - aniž by bylo třeba procházet jednotlivými objekty.

Cílem je dělat málo velkých alokací (než hodně malých). Tím se snižuje prostor pro problémy. Alokace totiž může selhat, což btw Rust také nemá zrovna dobře ošetřené (možná to nemá dokonce vůbec ošetřené a funkce prostě zpanikaří).