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.
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.