Kernel Traffic #147 For 24 Dec 2001

Andrea, wygląda na to, że seria -aa jest nie tylko do spraw VM. Jeśli chcesz włączyć to, co zrobiłeś dobrze, do jądra Marcelo, proszę, zrób to w sposób ,,jedna łatka z wyjaśnieniem na problem''.

Jeśli nie będziesz tak robił, wezmę moją piłę łañcuchową i wytnę wszystkie jednorazowe rzeczy z jądra, aby pozbyć się z 2.4 najgorszych przypadków. Nawet jeśli będzie to oznaczało możliwość usunięcia miłych rzeczy, nad którymi pracujesz.

Brak dokumentacji nie jest błędem, kropka. Również nie jest prawdą, że jestem jedyną osobą rozumiejącą kod. Np. Linus rozumie go w całości, jestem tego pewien na 100%.

Abstrahując od tego, zrobiłem z tuzin slajdów obrazujących VM wraz ze schematami, na wypadek, gdyby komuś łatwiej było zrozumieć slajdy niż kod.

Wierzę, że slajdy są przydatne do zrozumienia koncepcji, ale jeśli chcesz zmienić choćby linijkę kodu - slajdy czy nie, musisz przeczytać kod. Wszyscy narzekają na brak dokumentacji. Niesłusznie. Nie było dokumentacji, która pozwalałaby na hakowanie poprzedniego kodu VM. Ciekawi mnie, ile z osób zadowolonych z poprzedniej dokumentacji było czynnymi deweloperami. Poza niektórymi zwodniczymi komentarzami w bieżącym kodzie, które jeszcze nie zostały uaktualnione, nie sądzę, żeby sytuacja z dokumentacją była gorsza niż poprzednio.

Interesuje mnie tylko ,,co kod robi'' i ,,jakie są wyniki i zgłoszenia błędów''. Wszystko inne jest spekulacją i nie troszczę się o to.

Jak powiedziałem, napisałem trochę dokumentacji do VM na potrzeby mojego ostatniego referatu na jedno z największych wydarzeñ linuksowych we Włoszech. Wyjaśnia ona podstawowe koncepcje. Powinna się ukazać na ich stronie, jak tylko znajdę czas na wysłanie slajdów. Podeślę tu adres, jak tylko pojawią się na stronie. Pozwoli to osobom nie będącym programistami VM zrozumieć logikę algorytmów VM, ale zrozumienie tych slajdów jest odległe od zdobycia umiejętności do hakowania VM.

_Całkowicie_ zgadzam się z Linusem, że ,,prawdziwy świat jest zdominowany przez szczegóły implementacji''. Myślałem w ten sposób jeszcze przed przeczytaniem jego ostatnich emaili na linux-kernel (jednakże całkowicie nie zgadzam się z losowym charakterem ewolucji i innymi wiadomościami nie-na-temat z tego wątku :).

Dla programistów, prawdziwą wolnością jest kod, nie dokumentacja, a kod tam jest. I wydaje mi się, że bieżący kod jest łatwiejszy do zrozumienia (ok, jestem stronniczy, ale wciąż wydaje mi się, że jest łatwiej).

To częściowo historyczne:

Na oryginalnym PDP-11 jądro przechowywane było w pliku /unix (było to w okolicach późnych lat '70).

Kiedy dodano podsystem pamięci wirtualnej, zmieniono nazwę na /vmunix (wczesne lata '80, o ile pamiętam), aby zaznaczyć różnicę między systemami, które mogły uruchamiać obie wersje (w połowie lat '80 miałem Motorolę 68020, która wciąż używała /unix, gdyż VM był jeszcze niedokoñczony).

Dochodzimy do Linuksa, gdzie dodana została kompresja. Ponieważ nazwa UNIX (we wszystkich postaciach) była chroniona przez prawa autorskie i nie mogła zostać użyta, jądro zostało nazwane linux, a wraz z postępem, vmlinux, a ponieważ pliki skompresowane mają rozszerzenie Z lub gz - vmlinuz.

Właśnie wrzuciłem 2.4.17-rc1 na ftp.kernel.org... Prawdopodobnie teraz roznosi się na serwery lustrzane.

Hmm, chciałbym, aby ludzie z problemem ,,niezwalnialnej'' pamięci buforowej/podręcznej potwierdzili, czy 2.4.17-rc1 działa poprawnie.

Zmiany, który powinny rozwiązać problem, powinny też uczynić 2.4 mniej chętnym do swapowania.

Linus w tej chwili przyjmuje niektóre łatki, innych nie ... co z tego? Parę moich łatek, wyizolowanych i jasno niezwiązanych z bio (WE/WY urządzeñ blokowych) i sterowniki mochela, znalazły się w jądrze. Inne zostały odrzucone.

Widzę wiele osób (nie tylko Ciebie, Andre) rozpaczających nad odrzuconymi łatkami, kiedy dla mnie jest jasne, że tylko niektóre rzeczy, w specyficznych obszarach, zostaną zaaplikowane. Jeśli chodzi o Ciebie, Andre, łatki Jena zostały odłożone dla 2.5.x na jakiś czas, więc jest uderzająco oczywiste, że Linus nie weźmie Twoich łatek IDE, dopóki podsystem bio nie będzie ukoñczony i czysty, ponieważ Twoje łatki jasno zależą od zmian w bio.

Nie wierzę, że łatki zostały odrzucone dlatego, że były Twoje, czy bcrla, czy czyjekolwiek.

Cierpliwość jest cnotą ;-). Mamy przed sobą długą serię rozwojową, a jesteśmy dopiero na pre-łatkach do PIERWSZEGO wydania z serii 2.5.x.

Właśnie ukoñczyłem 2.5.1, ale cały czas skupiam się na kwestiach bio, więc nie wysyłajcie mi innych łat, o ile nie są to poprawki poważnych błędów w pozostałych rejonach jądra.

2.5.1 jest przypuszczalnie dobrym etapem pośrednim -- wiele sterowników urządzeñ blokowych powinno działać już poprawnie, ale wiele więcej jeszcze nie. Jednakże łaty pre stawały się coraz większe, więc zdecydowałem, że opublikuję 2.5.1, zamiast czekać na więcej szczegółów.

Co do innych rzeczy -- zauważcie oddzielenie sterowników dla nowych i starych układów tulipa: jeśli macie stary układ tulipa -- 2104x (w przeciwieñstwie do nowszych układów -- 2114x) -- normalny sterownik tulipa nie zadziała. Nie bądźcie tym faktem zdziwieni, tylko wybierzcie CONFIG_DE2104X.

uzgodnijmy więc kilka spraw: nie chcesz żadnych łatek, które opisują zasady rejestracji sterowników do ,,domen poprawności''. Nie chcesz również żadnych łatek naprawiających większe rzeczy. Np. wychodzenie z Interrupt Service Request, aby wykonać czynności związane z BH. Zauważmy, że nie możemy wciąż tych problemów obchodzić oraz, że rozwiązaniem jest wyrwanie chwasta i napisanie tego od nowa.

W tej chwili waga ,,domen poprawności'' sterowników urządzeñ blokowych/przechowujących dane staje się wewnętrzną rozgrywką z warstwą VM poprzez partycję lub plik wymiany.

Dopóki nie możesz sprawdzić, czy nowe WE/WY urządzeñ blokowych jest poprawne na poziomie transportu danych, gdzie żądania danych są zmieniane na rzeczywistą komunikację z dyskiem, nie masz żadnej pewności, tylko ślepy traf. Nie będziesz miał również żadnych szans na sprawdzenie, czy uszkodzenia zachodzą na poziomie warstwy systemu plików, czy pamięci. Aby im zapobiec musisz wyłączyć wszelki możliwy SWAP - na partycjach i w plikach.

Ponieważ nie ma sposobu na sprawdzenie poprawności sterowników, a wiele osób uważa, że nie jest ważnym przeprowadzanie takich testów, w jaki sposób chcesz zapewnić jakiegokolwiek użytkownika, że jego dane są bezpieczne? W tej chwili sprawiasz wrażenie osoby nie troszczącej się o integralność danych, a odmowa przyznania się do tego pogłębi to wrażenie.

Pamiętam całą żółć wylaną nad uszkodzeniami systemu plików w przeszłości, a Ty teraz otrzymujesz idealny sterownik i sposób na uwierzytelnienie transportu danych, i zgniatasz ideę w zarodku, bezpośrednio, czy też pośrednio. Miałem plany zrobienia tego samego uwierzytelnienia dla SCSI, aby być w zgodności z SPI 4, ale w sytuacji całkowitego odrzucenia izolacji warstw dla testów regresyjnych, nie wydaje mi się to praktyczne. Tak twierdzę, gdyż w obliczu odrzucenia prostego przypadku, nie widzę sposobu na wprowadzenie kiedykolwiek bardziej skomplikowanych projektów.

Więc wyświadcz nam wszystkim przysługę -- odpowiedz i wyjaśnij swoje stanowisko nt. tej delikatnej sprawy. Jestem pewien, że wszyscy chętnie usłyszą Twoją opinię nt. potrzeby lub braku testowalnej warstwy transportu danych z dysku twardego.

Założę się, że nazwiesz to ,,bezużytecznym nadęciem''.

Tłumaczenie: Andre wziął udział w zbyt wielu spotkaniach ATA i nie może myśleć inaczej niż w slangu pracownika przemysłu pamięci masowych ;)

Mam za sobą jedynie 6 miesięcy partycypowania w tym przemyśle, ale sądzę, że mówi on o zasadach inżynierii dźwięku.

Pierwsza z nich mówi, że jeśli próbujemy znaleźć problem w skomplikowanym systemie, powinniśmy wyizolować system spod wpływu innych systemów. A jeśli próbujemy zapobiec występowaniu nowych problemów, powinniśmy wypróbowywać i testować każdy z elementów złożonego systemu w procesie postępującym.

Andre skupia się tutaj na warstwie WE/WY urządzeñ blokowych, pownieważ jest to obszar, na którym się zna. Sądzę, że wskazuje na symptomy problemów, które mogą wystąpić w każdym pieprzonym rejonie jądra.

NAPRAWDĘ powinniśmy mieć jakąś logiczną strategię testowania różnych elementów, aby określić, czy są one warte włączenia do oficjalnego jądra i wyłapać wcześniej błędy. Tak, gdy dostatecznie dużo par oczu będzie się przyglądać, błedy zaczną znikać, ale wkładając trochę wysiłku w stworzenie systemu do testów, będziemy mogli zmniejszyć obciążenie najważniejszych ludzi pracujących nad jądrem, zdejmując im z karku przedzieranie się przez bezużyteczne zgłoszenia błędów, ponieważ użytkownik nie wiedział dostatecznie dużo o debugowaniu.

Musimy mieć jakiś sposób na oddzielanie poszczególnych podsystemów i katalog ,,testów regresyjnych'', które będą sprawdzać, czy nowe zmiany nie spowodowały błedów w jakichś podsystemach. Nie spodziewam się, że te testy regresyjne wyłapią wszelkie możliwe pomyłki, ale *SPODZIEWAM* się, że będziemy w stanie wyłapać każdy błąd, który wcześniej popełniliśmy. W ten sposób opiekunowie jądra będą musieli patrzeć na opis problemu jedynie raz, a potem jedynie napisać test, który wyłapie ten błąd, zamiast oglądać ten sam błąd z punktu widzenia 300 różnych użytkowników.

Nie. Zasady inżynierii oprogramowania muzycznego to zaprojektować dobry interfejs i dostosować do niego kod niskiego poziomu.

Andre patrzy na to z innej strony -- pisze i mówi o kodzie niskopoziomowym i myśli, że to powinno wpływać na to, jak działają wyższe warstwy.

Przeczytałem je, po czym przeczytałem je ponownie, i w koñcu przeczytałem je po raz trzeci. Jeśli chcesz, zrobię streszczenie Twoich wypowiedzi tak, abyś mógł przeczytać, co napisałeś i przemyśleć to. Linus, możesz kręcić na wszystkie strony, ale Twoje wypowiedzi były jasne: chcesz, aby było tak i tak. Nie sądzę, że to przyznasz, nikt nie lubi wyjść na głupka, więc dajmy temu spokój.

Chciałbym, abyś w koñcu napisał, co, Twoim zdaniem, jest dobrym sposobem podejścia do problemów systemowych. Wyszedłeś od ,,projekt jest dobry'', doszedłeś do ,,projekt jest zły'', ale nie chcę Ci nic ujmować, tylko dowiedzieć się, co myślisz. Gdy już to *przemyślisz*, a nie jedynie napiszesz coś tam na kolanie.

Nie ja jedyny tak myślę. Ponieważ to Ty podejmujesz ostateczną decyzję, co zostanie włączone do jądra, wiele osób na tym świecie chciałoby wiedzieć, jak robić rzeczy ,,poprawnie'' z Twojego punktu widzenia.

I przemyślana wypowiedź, jak spowodować zmianę w jądrze Linuksa, byłaby dobrze odebrana.