W sumie jak ktoś chcę mięsko, to może przeczytać tylko punkt “4 RQ2: Does RFL live up to the hype?”
TL;DR
-Niby bezpieczeństwo się poprawiło, ale nadal sporo unsafe w użyciu, więc problemu nie udało się całkiem wyeliminować
-Binarki sterowników są większe średnio o 1/3 (przy założeniu, że implementują wszystkie funkcjonalności z oryginału w C).
-Można znaleźć perełki typu sterownik NVM, który nie odstaje wydajnością, a można też znaleźć czarne owce jak przykładowy sterownik od ethernetu, który jest wolniejszy 11 razy względem oryginału w C.
-Społeczność Rusta przykłada się do tworzenia dokumentacji i testów.
Ciekawe jak radzą sobie z sytuacją, gdy zmienia się jakiś core’owy interfejs kernela i bindingi do Rust przestają działać.
Zakładam, że w tym przypadku autor zmiany (będący programistą C) po prostu ją wrzuca i czeka aż RFL naprawi po swojej stronie integrację z Rustem. Automatyczne generowanie FFI bindgenem tego nie rozwiąże, bo później trzeba taki crate owinąć w bezpieczną abstrakcję.
Feature branch z taką zmianą w C pewnie nie może być zmergowany do czasu aż jakiś reviewer od RFL go zatwierdzi?Dla mnie wygląda to na istotną komplikację. No chyba, że komponenty pisane w Rust nie są blockerem dla wydania całej reszty kernela.
Czy Rust jest już wymaganym składnikiem podczas budowania?
Wydaje mi się, że nic nie jest blokerem. Jeśli coś blokuje i nikt się tym nie zajmie to jest wyrzucane.
