Ksplice - łatanie jądra Linuksa bez rebootowania
Kilka dni temu pojawiła się nowa postać na LKML-u. Jeff Arnold, student z MIT, swoim pierwszym postem wzbudził niemałe zainteresowanie, również mediów. Otóż przygotował on system do łatania jądra bez restartowania systemu - Ksplice. Właśnie wysyłam do redakcji artykuł tłumaczący o co w tym chodzi, poniżej zaś kilka ciekawostek które się w nim nie zmieściły.
Kolejność mniej więcej przypadkowa:
- Programy przestrzeni użytkownika (ksplice-create, ksplice-apply itd.) napisane są w Perlu.
- Poza 975 linijkami Perla jest też 1928 linijek C.
- Przykład na stronie projektu nie jest zgodny ze stanem faktycznym - w linii poleceń podaje się katalog źródeł jądra (a nie podkatalog ksplice).
- Aby ustrzec się od jakichkolwiek konfliktów, w momencie aplikowania zmian wołane jest stop_machine_run() (to samo co przy hibernacji, powoduje zatrzymanie wszystkich procesorów). W razie niepowodzenia powtarza się próby 5 razy.
- Niepowodzeniem kończy się próba podmiany funkcji, która jest w użyciu. Oznacza to, że nie da się za pomocą Ksplice naprawić na przykład błędu w schedulerze.
- Jeśli lubimy oszczędzać miejsce na symbolach, całkiem prawdopodobne jest, że operacja się nie uda. Dlatego warto rozważyć włączenie CONFIG_KALLSYMS.
- Na /. cała idea została wyśmiana, zaś na LKML-u wprost przeciwnie.
Jeszcze garść linków:
Dodaj komentarz:
Komentarze do notki Ksplice - łatanie jądra Linuksa bez rebootowania
Ech, zapewne jak zwykle służy to jedynie do powiększenia sobie peni^Wuptime’u ;).
lRem dnia 05 maja 2008 o 21:47:37:
Jednym słowem: nie. Ale o tym jest ten artykuł w L+ ;)
Pomyśl jak szybko (i czemu tak wolno) łatane są dziś poważne serwery...
No i umknęło mi (i tutaj i w artykule) chyba najważniejsze:<br>
Od uptime'u często bardziej się liczy ciągłość stanu. Czyli nie zrywanie połączeń, nie przerywanie obliczeń i tak dalej.
trasz dnia 12 maja 2008 o 21:25:52:
Fajny ficzer, chociaz przydatny wlasciwie tylko w Linuksie, z bardzo prostego powodu - nadaje sie jedynie do malych poprawek, glownie bezpieczenstwa, a w systemach innych niz Windows i Linux dziury w kernelu pojawiaja sie na tyle rzadko, ze szkoda czasu na tego typu kombinacje.
Tutaj polemizował nie będę. Rzeczywiście rezygnacja z wspierania czego się da jest metodą na zwiększenie bezpieczeństwa. No i nikt nie szuka dziur tam, gdzie nie ma użytkowników ;)
trasz dnia 13 maja 2008 o 14:07:02:
OSX ma, pi razy oko, trzy razy wiekszy userbase niz Linux, a dziur w kernelu znajduje sie w nim razy mniej. CBDO.