Sasha Levin z firmy Google, zajmujący się utrzymywaniem LTS gałęzi jądra Linux i członek doradczego komitetu organizacji Linux Foundation, ogłosił utworzenie nowej gałęzi jądra Linux — „linus-next”, która, w analogii do gałęzi „linux-next”, jest przeznaczona do testowania zmian proponowanych do włączenia do głównych wersji przyszłej gałęzi jądra Linux, ale różni się orientacją na zmiany gotowe do przyjęcia do głównej gałęzi oraz dostarczeniem bardziej stabilnej i nadającej się do testowania bazy.
Do tej pory używana gałąź „linux-next” doskonale nadaje się do sprawdzania integracji zmian w jądrze, oceny występowania konfliktów między podgałęziami różnych opiekunów oraz identyfikacji związanych z kompilacją błędów i ostrzeżeń, ale trudno ją wykorzystać do testowania wprowadzanych zmian. Gałąź „linux-next” zawiera mieszankę zmian gotowych do przeniesienia do głównej gałęzi jądra oraz eksperymentalnych dodatków, które mogą być długo rozwijane i być może w ogóle nie zostaną przyjęte do głównej gałęzi jądra.
Obecność niestabilnego eksperymentalnego kodu uniemożliwia pełne testowanie robocze jądra „linux-next”, ponieważ kod eksperymentalny może negatywnie wpływać na inne podsystemy jądra. W nowej gałęzi „linus-next” kryteria przyjmowania zmian będą surowsze — do składu będą włączane tylko pull-requesty adresowane do Linusa Torvaldsa, które według przypuszczeń programistów Linus zaakceptuje do głównej gałęzi jądra.
Pojawienie się gałęzi „linus-next” umożliwi nie tylko testowanie zgodności proponowanych zmian na poziomie kompilacji jądra, ale także bezpośrednią ocenę pracy, co prowadzi do poprawy jakości testowania zmian na etapie rozpatrywania już wysłanego, ale jeszcze nie rozpatrzonego przez Linusa, pull-requestu. Nowa gałąź będzie również stymulować wysyłanie pull-requestów jak najwcześniej, jeszcze przed rozpoczęciem okna przyjmowania zmian, aby umożliwić ich przetestowanie w działaniu. Ponadto gałąź „linus-next” będzie rozwijać się zgodnie z modelem ciągłej integracji, a nie codziennej aktualizacji z tworzeniem nowego tagu, co uprości analizę pojawiających się problemów i identyfikację konkretnych zmian, które spowodowały awarię.
Dodatkowo warto zauważyć niezadowolenie Linusa Torvaldsa z procesu blokowania na poziomie jądra luk w zabezpieczeniach sprzętowych, które zostało wyrażone podczas dyskusji na temat problemów i regresji w kodzie mających na celu przeciwdziałanie atakom wykorzystującym luki w mechanizmie spekulacyjnego wykonywania instrukcji w CPU. Zmiany niezbędne do zablokowania luk w zabezpieczeniach sprzętowych komplikują rozwój, prowadzą do pojawiania się regresji i negatywnie wpływają na wydajność, podczas gdy ataki wykorzystujące większość takich luk są w zasadzie teoretyczne i nigdy nie są stosowane w praktyce, poza warunkami laboratoryjnymi.
Rozważając propozycję zmiany jądra w celu ominięcia potencjalnych problemów związanych z przeciwdziałaniem lukom sprzętowym, Linus zaproponował, aby odpowiedzialność spadła na producentów sprzętu, uznawanych za winnych powstawania luk sprzętowych, i dał do zrozumienia, że powinni oni sami rozwiązywać własne problemy. Dyskutowana zmiana miała być wprowadzona jako zabezpieczenie, ponieważ z powodu niepewności zachowania CPU ochrona mogła potencjalnie przestać działać na niektórych nowych procesorach Intel.
Źródło: opennet.ru
