Kernel Traffic #146 For 17 Dec 2001

indent _nie_ rozwiązuje następujących problemów:

• pomyleñców, który myślą, że MojaZmiennaJestWiekszaNizTwojaZmienna jest dobrą nazwą zmiennej.
• pomyleñców, którzy definiują funckję z 42 argumentami, której treść to: return (foo == bar) ? TRUE : FALSE;
• pomyleñców, którzy dodają 1001-szą błędną implementację memcmp(), nazywają ją CostamPorownajGowienka i dołączają ją z komentarzem o rozmiarach 20x80.
• pomyleñców, którzy używają definiowania typów takich jak WORD, DWORD, BYTE, JESTEMIDIOTAZASTRZELCIEMNIE i innych w ten deseñ (no dobra, ostatniego wyraźnie nie napiszą - ale nie dlatego bynajmniej, że wynika to z reszty ich, ahem, kodu).
• pomyleñców, którzy używają notacji ,,węgierskiej'' bez dobrego powodu i dodają struktury, w których nazwy pól brzmią jak nazwy ulic w R'Lyeh
• pomyleñców, którzy wprowadzają wrappery na standardowe rzeczy w jądrze - takie jak, na przykład, typedef int Int32; i upiększają swoje wypociny ifdefami zależnymi od architektury.
• pomyleñców, którzy sądzą, że cpp jest Właśnie Tym i produkują gówno, które aż wykręca z obrzydzenia.

Super. Już to widzę. ,,foo inc.'' wypuszcza sterownik dla Linuksa na GPL i zostaje publicznie upokorzona na ,,linux source code hall of shame''. Idealnie. Nawet tu dochodzi do mnie śmiech z Redmond (a to 12000km stąd).

Informacja prasowa:

,,Jeśli wspierasz Linuksa, możesz zostać za to publicznie upokorzony. Nie rób tego.''

Dorośnijcie. Jest sporo rzeczy ważniejszych niż styl kodowania, który nie jest ,,kompatybilny z Alem Viro (TM)''.

Ech, czasem, czasem _naprawdę_ rozumiem gości od BSD, gdy nazywają społeczność Linuksową ,,bandą potarganych wariatów, którzy potrzebują mieć życie''. Gdyby tylko oni używali sensownych skryptów startowych. ;-)

Starasz się powiedzieć, że SUN traktował w ten sposób _KLIENTóW_ i firmy, które chciały obsługiwać SunOS 4.2.x? Jeśli tak, to już wiem do czego był im potrzebny SysV. Oczywiście, nikt by dłużej nie chciał BSD.

Jeśli wewnętrzna grupa deweloperów w SUNie tak się nawzajem traktowała, to także ,,potrzebowali zmiany''. :-)

Kwestia bezpieczeñstwa jest powszechnie akceptowanym problemem, który w większości przypadków ma powód i rozwiązanie.

Styl kodowania jest jednak bardzo osobistą rzeczą, która zaczyna się od pytania ,,czy powinniśmy używać tabulacji, czy nie?'' (Jakarta: Nie. Linux: Tak ...) i przez pytanie ,,Czy makro preprocesora jest dobre, czy nie'' dochodzi do nazw zmiennych (Al Viro: Nazwy, które mają więcej niż pięć liter, obsysają. :-) Java: Nazwy, które nie są samodefiniujące się, obsysają. Microsoft: nazwy bez notacji węgierskiej, obsysają) i tak dalej.

Naprawdę chcesz oceniać kod tylko po tym, że ktoś lubi owijać kod w makra preprocesora albo używa WIELKICH LITER w nazwach zmiennych?

Daj spokój. To jest _fundamentalnie_ inny problem niż problem producentów topiących się we własnych odchodach, gdy namieszają i ich sprzęt/program ma błąd bezpieczeñstwa. Kod, który uważasz za piekielnie obrzydliwy, może być opisany przez autora jako ,,łatwy do zrozumienia i rozwijania''. Jeśli on działa i nie ma błędów, to co? Tylko dlatego, że trudno nam go zrozumieć (porównaj to z ,,niezwykłymi procedurami w NTFS-ie'' (Jakoś tak to określił Jeff Merkey). Zdaje się, że cały czas dobrze działają.

Czy chcesz osądzać ,,brzydotę'' sterowników w jądrze? Które są okropne? Czy sterowniki Donalda Beckera są paskudne tylko dlatego, że (przynajmniej w 2.2) używa on własnych pomocniczych bibliotek pci? Czy sterowniki aic7xxx są brzydkie bo wymagają libdb? A może brzydota jest definiowana przez stwierdzenie, że ,,Nie podoba się Larremu i Alowi''? :-)

Objeżdżanie za styl kodowania jest tak samo bezsensowne, jak wkurzanie się na kogoś za to, że kibicuje innej drużynie sportowej. Nie ma jednego, powszechnie akceptowanego, stylu kodowania. Nawet w C.

Jądro ma powszechnie akceptowany styl kodowania, zarówno ten udokumentowany, jak i ten mieszczący się w tradycji. Używanie go bardzo bardzo ułatwia opiekę nad kodem. Wymuszanie go tam jest dobrym pomysłem, z wyjątkiem sytuacji specjalnych (nagłówki współdzielone z NT są jednym z przykładów).

Są także pewne całkiem miłe narzędzia, które wykonają pierwszą fazę przenoszenia ,,węgierskich'', ,,zNTowanych'' sterowników i zlinuksowanie ich.

Fakty z życia: wszyscy dajemy ciała przy przeglądaniu naszego kodu. Ty, ja, Ken Thompson, ktoś inny - zwykle nie zauważamy błędów w kodzie, który sami napisaliśmy. W zależności od umiejętności możemy to naprawić - istnieją techniki, które pomagają w takich wypadkach, ale to nie zmienia faktu, że przeglądanie kodu przez ludzi, którzy go nie pisali zwykle pokazuje błędy, których nie zauważaliśmy przez lata.

Jeśli naprawdę nie wiesz tego z doświadczenia - nie _masz_ doświadczenia. Jest jeden cholernie dobry powód ujednolicania stylu w projekcie: przeglądanie go pomaga. Zgubiłem już rachubę błędów w sterownikach, które znalazłem po prostu grepując drzewo. Nawet na tym poziomie udaje się znaleźć tony błędów. I nie mam powodów wątpić w to, że autorzy tych właśnie sterowników naprawiliby je tak szybko, jak tylko by zobaczyli wymieniane błędy.

,,To mój kod i nie obchodzi mnie czy ktoś jeszcze może go przeczytać'' - tak by się każdy od razu bronił. Być może, z akademickiego punktu widzenia, to jest w porządku, ale w prawdziwym życiu jest po prostu nieakceptowalne.

Bardzo miło i elegancko jest ronić łzy nad biednymi, wymęczonymi firmami, które chciały dobrze i uszczęśliwiły wszystkich poprawnym, ale zupełnie nieczytelnym kodem, a teraz są upokarzane przez złośliwych niewdzięczników. Ładny obrazek, ale rzeczywistość jest inna. Kod jest _pełen_błędów_. To jest dana, niezależna od pochodzenia kodu. Jedyne pytanie to takie, jak szybko da się te błędy poprawić. A to bezpośrednio zależy od tego, ile wysiłku potrzeba by ten kod przeczytać.

Ponieważ udało mi się z niczego zrobić pełny stos sieciowy (to znaczy moje gówienko nie śmierdzi i jestem tu by Ci to powiedzieć :-))) sądze, że Twoje poglądy są dość bezpodstawne.

Od początkowej implementacji do chwili, gdy wszelkie blokady zniknęły z jądra przy każdym obciążeniu, doszliśmy rozwiązując trzy zadania:

1. Czy ten obiekt jest prawie w całości oparty na odczycie? Jeśli tak, to należy użyć specjalnych blokad, aby to wykorzystać. Zobacz linux/brlock.h - jest tam przykład takiego ,,specjalnego blokowania'', które wymyśliliśmy w celu optymalnej obsługi takich przypadków.

   Ta zmiana owocuje ZEROWĄ liczbą współdzielonych linii pamięci podręcznej, o ile początkowa analiza była poprawna.

2. Czy możemy rozdrobnić blokady tak, aby ludzie używający osobnych obiektów przez 99% czasu korzystali z różnych linii pamięci podręcznej?

   To nie oznacza ,,więcej blokad dla każdego obiektu'', raczej ,,więcej blokad strefowych''. Blokady na każdy łancuch hasza łapią się do tej kategorii i są bardzo efektywne przy każdym obciążeniu, jakie kiedykolwiek widziałem.

3. Czy to jest naprawdę sprawa każdego procesora z osobna? Przykładem są pamięci podręczne nagłówków SKB dla każdego procesora. Innym magazyny SLAB dla każdego procesora.

Inne źródło problemów ze skalowalnością nie ma nic wspólnego z robieniem podziałów lub nie. Wciąż możesz napotkać sytuację, w której wiele procesorów chce (na przykład) trzecią stronę libc.so :-) (próbuję powiedzieć, że w pewnych klasach sytuacji problem ma naturę sprzętową)

Szczerze mówiąc, po zastosowaniu #1 i/lub #2 i/lub #3 w miejscu, w którym pojawia się problem (musiałem to zrobić w przypadku stosu ipv4), nie zostaje wiele trudności. I nie widzę żadnych powodów do dodania większej liczby blokad w ipv4. Nie sądzę również, że przesadziliśmy z ich liczbą.

Podkreślam - uważam, że bieżąca implementacja ipv4 w Linuksie skaluje się o wiele lepiej od czegokolwiek pochodzącego od Suna. Z mojej perspektywy, starania Suna o skalowalność polegają na wciskaniu na siłę blokad per obiekt tam, gdzie coś niepokojącego dzieje się w czasie profilowania, nie biorąc pod uwagę niczego innego. Ich stos sieciowy jest naprawdę duży i tłusty. Na przykład, informacje o gniazdku TCP w Solarisie są prawie 4 razy większe od linuksowych (tak było, kiedy ostatni raz przeglądałem ich nagłówki). I jak wszyscy wiemy, całość ich implementacji leży na szczycie jakieś grubej infrastuktury (np. strumienie - STREAMS). (OK, w tym miejscu ktoś powienien pokazać realistyczny test sieciowy, pokazujący, że skalujemy się gorzej niż Solaris. Z przyjemnością powitam taką ripostę, ponieważ wynikła dyskusja skonczyłaby się zapewne jakąś naprawdę prostą poprawką).

Konkludując: myślę, że skalujemy się tak dobrze, jak możemy w miejscach, gdzie wykonaliśmy kawał roboty (czyli również w warstwie sieciowej) i nie jest to spowodowane ,,zbyt wielką liczbą blokad''.

Problematycznym obszarem skalowalności, w którym dobrego rozwiązania nadal nie widać, jest odszukiwanie nazw plików w drzewiastych strukturach danych, tj. w dcache w Linuksie. Wszystkie dostępy są oparte na drzewie, i każdy startuje z podobnych korzeni. Nie można więc blokować poszczególnych węzłów czy gałęzi, bo każdy przemierza te same ścieżki. Co więcej, nie możesz użyć ,,specjalnych blokad'' z punktu #1, ponieważ ta struktura danych nie jest nastawiona głównie na odczyt, ani głównie na zapis.

Należy zauważyć, że klastry SMP/cc nie rozwiążą tego problemu.

Blokada dcache_lock uwidacznia się wyraźnie przy dużych obciążeniach w obecnym Linuksie. I tak samo źle będzie się to objawiać na klastrach SMP/cc. Klastry SMP/cc to dużo gadania typu ,,zrób z tego specjalny system plików i skaluj go tak, jak chcesz'', ale ja próbuję pokazać, to jeden z problemów dla którego dzisiaj nie ma ,,ewidentnego rozwiązania''.

Jeśli LLNL nie był zbyt zakręcony twoją propozycją, to w tej chwili ja bym ich nie obwiniał. Ponieważ z informacjami które mam teraz, myślę, że twoje twierdzenie o potencjale tego są iluzoryczne.

Naprawdę chciałbym, żeby ktoś wytknął mi błąd, ponieważ sprawa blokowania ścieżki wyszukiwania plików daje mi do myślenia, już od jakiegoś czasu.

Inne, co zauważyłem, to że zmiany skalowaności SMP, które pomagają w przypadku 8, 16, 32, 64 procesorów, prawie nigdy nie krzywdzą przypadku 4 czy 2. Ostatecznie, jak bodajże Ingo ostatnio wykazał, niektóre prace nad SMP poprawiły nawet pracę przy jednym procesorze.

Hej, to nie jest błąd, to jest taki BAJER!

Czy wiesz co, w całym układzie słonecznym, z tego co wiemy, jest najbardziej złożonym cudem techniki?

Zgadnij co - to nie Linux, to nie Solaris i nie twój samochód.

To Ty. I ja.

I pomyśl skąd tak naprawdę się wzięliśmy - nie dzięki skomplikowanemu projektowi.

Jasne. ,,zwykłe szczęście''.

Tak, głupie szczęście, ORAZ:

• wolnodostępność i _wzajemne_zapładnianie_ przez współdzielenie ,,kodu źródłowego'', który biolodzy nazywają DNA.
• raczej słabo wybaczające środowisko użytkownika, które szczęśliwie wymienia kiepskie wersje nas na te lepiej działające i w ten sposób wybierające przodowników (biolodzy często nazywają to ,,przeżywaniem lepiej przystosowanych'')
• masowy, nieukierunkowany, równoległy rozwój (,,próby i błędy'')

Jestem śmiertelnie poważny: my, istoty ludzkie, _nigdy_ nie byliśmy zdolni do powtórzenia czegoś bardziej skomplikowanego niż my sami, a naturalna selekcja zrobiła to zupełnie bezmyślnie.

Doceñcie siłę przetrwania najlepszych jednostek.

I NIGDY nie myślcie błędnie, że umiecie zaprojektować coś lepszego niż osiągnięcie z masowego stosowania brutalnej metody prób i błędów ze sprzężeniem zwrotnym. To bardzo, bardzo pomoże waszej inteligencji.

Zupełnie uczciwie, Sun jest skazany. I nie ma to nic wspólnego z ich technicznymi doświadczeniami ani z ich stylem kodowania.

Nie zapominaj o tym, że 2.4 jest pierwszym jądrem od czasu 1.2, dla którego udało Ci się osiągnąć stabilność przy dużych obciążeniach.

Zarówno 2.0 jak i 2.2 nie były stabilne do chwili, w której Alan je przejął, a linia 2.4 autorstwa Alana była stabilna 4 miesiące wcześniej niż Twoja.

Wydaje mi się, że już nieźle udowodniłeś jak dobrze działa losowy rozwój.

Linus wciąż ignoruje, odrzuca i włącza konfliktujące ze sobą łatki. Linia -ac, od 2.4.9-ac czy coś z poprawkami Rika, które chciał dać Linusowi przeszło przez testy Red Hata. Coś koło 2.4.16 przechodzi je teraz.

To nie miało nic wspólnego z tym, że VM był zepsuty, a wszystko z tym, co zaaplikował Linus. Wygląda na to, że nowy VM jest wydajniejszy przy małych obciążeniach (co jest dobre), ale poprzedni VM wcale nie był złej jakości i nie był źle zaprojektowany.

Linus odrzucał nawet łatki poprawiające komentarze w kodzie VM, które to komentarze odnosiły się do starego zachowania. A z kompletnego braku dokumentacji VM wnioskuję, że odrzucił również komentarze i dokumentację od Andrei.

Kierowana ewolucja - czyli ewolucja, która ma ściślej określone cele, szybsze karanie za błędy, działa w skali dziesiątek lub setek lat, nie dziesiątek tysięcy. Spójrz na hodowlę psów, albo lepiej na inwentarz domowy, gdzie zaledwie kilka dekad potrafi zrobić wielką różnicę.

Wiara, że ewolucja jest z konieczności powolna, jest totalnie bezpodstawna.

JEDNAKŻE, wiara, że _zbyt_ duże ukierunkowanie jest złe, z pewnością nie jest bezpodstawna; wykazuje problemy z projektem, które nie pojawiają się przy mniejszej kontroli. Ponownie, zbyt agresywna hodowla psów powoduje złą charakterystykę, zwłaszcza w przemyśle drobiowym.

Trzeba zdać sobie sprawę, że powyższe stworzenia są o wiele bardziej skomplikowane niż Twój program, i gdzie, ze względów historycznych, człowiek nie mógł właściwie wpływać na nic, poza selekcją.

Możliwość wpływu nie tylko na selekcję, ale również na _mutacje_, bezpośrednio skraca czas o kilka rzędów wielkości.

W skrócie, Twój komentarz o ,,niestosowności'' pokazuje tylko, że albo jesteś niedoinformowany o zmianach biologicznych, albo (co bardziej prawdopodobne) jest tylko odruchową reakcją bez _myślenia_.

Ewolucja biologiczna wciąż działa i ma się dobrze, i nie potrzebuje milionów lat aby dokonać zmian. W rzeczy samej, większość paleontologów uważa zmiany wynikłe wskutek katastrof naturalnych za zadziwiająco szybkie, zważając na _brak_ ,,inteligentnego kierowania''.

Oczywiście, ta sama ewolucja faworyzuje ,,stabilne'' formy życia (rekiny i wiele zwierząt wodnych nie zmieniły się zbytnio od milionów lat). Nie dlatego, że ewolucja jest powolna, ale po prostu dobre formy życia działają dobrze w swoim otoczeniu, i jeśli otoczenie nie zmienia się radykalnie, mają bardzo mało nacisków, na które muszą reagować.

Zmiany nie są automatycznie ,,dobre''. W rzeczy samej, jest wiele powodów _przeciwko_ zmianom, o czym często zapominamy w technologicznym świecie. Powolność ewolucji, przy braku powodów do ewoluowania, jest _dobrocią_, nie uderzeniem przeciwko niej.

Bądźmy szczerzy, i przyznajmy, że nie został zaprojektowany.

Jasna sprawa, że jakiś projekt był - UNIX czyni szablon dla systemu. Co więcej, ułatwia ludziom komunikację, bo ludzie mają mentalny _model_ wyglądu systemu, co ułatwia dyskusję nad zmianami.

Ale to tak jak mówić, że masz zamiar zbudować samochód z czterema kołami i światłami - to prawda, ale diabeł tkwi w szeczegółach.

I wiem lepiej od wszystkich, że to co wyobrażałem sobie 10 lat temu, nie ma _nic_ wspólnego z dzisiejszym Linuksem. Z pewnością nie ma tu przemyślanego projektu.

Dalej będę twierdził, że nikt inny nie ,,zaprojektował'' Linuksa bardziej niż ja, i nie wątpię, że wiele osób się z tym nie zgodzi. Urósł. Urósł z wieloma mutacjami - a ponieważ mutacje były mniej niż losowe, były szybsze i bardziej kierowane niż cząsteczki alfa w DNA.

Zaufaj mi, nigdy nie był.

Pójdę dalej, stwierdzam, że _żaden_ duży projekt programistyczny, który odniósł sukces na szerszym rynku (w przeciwieñstwie do nisz) nie przeszedł przez wszystkie miłe cykle, o których uczą na zajęciach z Informatyki. Czy _kiedykolwiek_ słyszałeś o jakimkolwiek projekcie, który zaczął się od przemyślenia co jest potrzebne, poprzez rygorystyczną fazę projektu, aż do fazy implementacji?

Marzenia.

Oprogramowanie ewoluuje. Nie jest projektowane. Pytanie tylko, jak ściśle _kontrolujesz_ ewolucję, i jak otwarty jesteś na zewnętrzne źródła mutacji.

A próba zbyt silnego kontrolowania ewolucji zabije Cię. Nieuniknienie i skutecznie. Zawsze. W biologii i w przypadku programu.

Amen.

Rzekłbym, że to lepiej, ponieważ mutacje (pojedyncze łatki) przechodzą przez bardzo _drobne_ sito, zanim znajdą się w ,,oficjalnych'' źródłach. Mamy do czynienia z populacją jąder (każdy deweloper ma kilka, dystrybucje również, inni, ...), tylko to, co przetrwa otrzymuje szansę włączenia.

Jasne, to nie jest jedyny sposób, w jaki Linux posuwa sie do przodu. Ale odgrywa ważną rolę w sukcesie ,,Udostępniaj wcześnie. Udostępniaj często. Bierz łatki zewsząd.''

Ta, racja, Linus. Powinniśmy wszyscy iść do domów, zebrać stado małp i kazać im uderzać w klawisze. Będą pracować tak samo dobrze, a wg. Twojego rozumowania osiągną sukces szybciej i nie będą marnować czasu na projekty.

Nie mogę uwierzyć w te brednie które rozsiewasz, myślę, że Ty również nie wierzysz. Jeśli jest inaczej, potrzebujesz przerwy. Dajmy ludziom eksplorować, niech oprogramowanie ewoluuje, to jest dobre. Ale ktoś musi trzymać wszystko na oku.

Jeśli to nieprawda, to przyznaj się, Linus. Nie jesteś potrzebny i *Ty* to właśnie udowodniłeś. Nie możesz mieć dwóch rzeczy naraz. Albo jesteś tu z jakiegoś powodu, albo nie. Więc jak? Spierasz się, że nie jesteś ważny. Osobiście się nie zgadzam, myślę, że Linux byłby kupą psiego łajna bez Ciebie. Jeśli Ty się nie zgadzasz, wycofaj się i zobaczymy co się stanie.

O, absolutnie.

Chciałbym, żeby więcej osób zdało sobie z tego sprawę. Niektórzy uzmysławiają sobie to dopiero, gdy są naprawdę wkurzeni na mnie i mówią ,,Goñ się, mogę to zrobić po swojemu''. I wiesz co? Oni też mają rację, nawet jeśli dochodzą do tych konkluzji ze złych, wg mnie, powodów.

Powód, dla którego zajmuję się Linuksem to nie to, że czuję się ,,potrzebny''. Robię to, bo to lubię, i przypadkiem uważam, że jestem w tym lepszy niż większość. Może niekoniecznie lepszy od wszystkich wokół, ale wystarczająco dobry, i z pozycją społeczną, która czyni mnie nieprzebijalnym.

Ale ,,niezastąpiony''? Dorośnij Larry. Przypisujesz mi zbyt wiele.

I dlaczego powinienem wycofać się tylko dlatego, że nie jestem niezastąpiony? Czy Ty jesteś wymagany do przedłużenia istnienia ludzkości? Myślę, że nie, chociaż oczywiście możesz się nie zgodzić. Czy powinieneś się więc ,,wycofać'' ze swojego życia tylko dlatego, że ściśle rzecz biorąc nie jesteś naprawdę potrzebny?

Czy kieruję pewnymi sprawami? Tak. Ale, szczerze, robi tak wielu innych. Alan Cox, Al Viro, David Miller, nawet Ty. A także wiele firm, które są częścią ewolucji, świadomie czy nie. I wszyscy użytkownicy, którzy są de facto ,,testem przystosowania do przetrwania'' dla Linuksa.

I tak, wierzę w to co mówię.

Najbardziej uderzające jest to, że rozwój Linuksa może _wygladać_, jakby był zorganizowany.

Tak, ludzie czytają literaturę, ale jest to trochę zwodnicze. Najważniejsze są detale takie, jak limity czasowe kontroli zapchania łącza TCP - to bardzo _ważne_ detale, ale mówimy o kilkuset liniach spośród 20 _milionów_.

I nie, nie twierdzę, że reszta jest ,,losowa''. Ale _twierdzę_, że nie ma wspólnych celów, i większość rozwoju przebiega z bardzo losowych przyczyn - czyjeś szczególne zainteresowania lub podobne sprawy.

To ,,kierowana mutacja'' na mikroskopijnym poziomie, i z bardzo małym makroskopowym kierunkiem. Jest pełno indywidualistów z jakimś ogólnym pojęciem, jaki ma być system (a ja jestem oczywiście jednym z nich), ale w ostatecznym rozrachunku jesteśmy bandą ludzi bez spójnej wizji.

I to jest DOBRE.

Silna wizja i pewna ręka brzmią dobrze na papierze. Ale nigdy, _przenigdy_ nie spotkałem osoby (włącznie ze mną) której bym ufał i wiedział, że jest właściwą osobą na dłuższy okres.

Zbyt silna wizja może Cię zabić - przejdziesz przez krawędź, utwierdzony w przekonaniu o ścieżce przed Tobą.

Polegałbym raczej na ,,ruchach Browna'', gdzie mnóstwo mikroskopijnych kierowanych poprawek posuwa system powoli w kierunku, o którym żaden z indywidualnych deweloperów, nigdy by nie pomyślał.

I mocno wierzę, że aby zrobić wszystko _dobrze_, potrzebujesz grupy programistów, która będzie trochę dziwna i losowa.

Wracając do oryginalnego stwierdzenia - gdzie Larry stawia na piedestale Sunowską ekipę inżynieryjną za jej ograniczenie horyzontów i ścisłą kontrolę - i do stwierdzenia, że Linux jest lepszy ,,przez przypadek'': naprawdę wierzę, że to jest ważne.

Problemem z ,,ograniczeniem i ścisłą kontrolą'' (albo ,,projektem'') jest to, że owszem, dotrzesz z punktu A do B o wielę prostszą drogą, z mniejszym wydatkiem energii, ale jak U DIABŁA chcesz wiedzieć, gdzie właściwie chcesz skoñczyć? My nie wiemy, że B jest naszym celem.

Większość deweloperów nie zna nawet _pośrednich_ celów, nie mówiąc już o ostatecznym. Posiadanie kogoś, kto pokaże ci ,,jedyną słuszną ścieżkę'' może być bardzo miłe w ukoñczeniu projektu, ale mam takie silne odczucie, że o ile ,,jedyna słuszna droga'' czasami koñczy się właściwie (a z inteligentnym przywódcą może być _prawie_ właściwa), to co jakiś czas jest to zdecydowanie zła droga.

I jeśli poruszasz się w pojedynczym pliku, w tym samym kierunku, musisz popełnić tylko jedną pomyłkę, aby zginąć.

Z drugiej strony, jeśli idziesz we wszystkich kierunkach naraz, może nie dojdziesz do miejsca gdzie _myślałeś_ że chcesz dojść, ale nigdy nie zrobisz naprawdę fatalnych pomyłek, bo zawsze musisz usatysfakcjonować wiele _różnych_ opinii. Otrzymujesz bardziej zbalansowany system.

To jest to, co rozumiem przez hodowlę, a problem z UNIXem polega na tym, że tradycyjnie firmy zajmują się jedną niszą.

(Firmy linuksowe też celują w nisze, ale raczej celują w _różne_ nisze, więc efektem koñcowym jest ,,wiele różnych kierunków'', co jest tym, co myślę, że chcesz przetrwać).

Podstawowymi powodami, dlaczego tak się dzieje, są następujące, specjalne warunki na naszej planecie:

• ludzki mózg ma ograniczoną pojemność, zarówno jeśli chodzi o ,,przechowanie danych'' jak i ,,moc obliczeniową''.
• sam świat, przynajmniej tak, jak go teraz rozumiemy, jest niezaprzeczalnie losowy. (wygląda na to, że ta losowość jest główną siłą napędową ,,porządku'')
• ta planeta ma ograniczone zasoby, więc ,,przetrwanie najlepiej przystosowaniego'' jest wciąż główną siłą napędzającą ,,życie''.
• nie znamy i nie rozumiemy zasad naszego świata, a technologia układów scalonych (która pozwala na istnienie systemów operacyjnych) jest już na krawędzi (a często poza nią) tego, co fizyka jest w stanie wyjaśnić. Po prostu nie znamy przełomów (lub cegieł w ścianie wydajności), które wydarzą się za rok, dwa czy pięć lat. Nie wiedzieliśmy 50 lat temu że coś takiego jak ,,SMP'' stanie się czymś powszechnym w dzisiejszym świecie. Mam na mysli, że często nie wiemy, co wydarzy się w kolejnej minucie.

z powodu tych fundamentalnych problemów rozwój ,,technologii'' staje się bardzo, bardzo nieprzewidywalny. Mamy tylko 5 miliardów szarych komórek i brak możliwości aktualizacji. Projekty programistyczne takie, jak Linux są już na tyle skomplikowane aby przekroczyć ich możliwości. Wydajność ludzkiego mózgu plus pęd ku czemuś lepszemu (pociągany przez ludzkie potrzeby) powoduje, że tysiące ambitnych ludzi pracuje równolegle nad różnymi częściami Linuksa.

kilka wyjaśnieñ:

• gdybyśmy znali wszystkie zasady tego świata i wiedzieli jak jest zastosować we wszelkich szczegółach, wtedy na tę Gwiazdkę zbudowalibyśmy ,,idealny scalak'' i nie było już by potrzeby czegokolwiek innego, nigdy.
• jeśliby ludzki mózg (i palce) nie miał ograniczeñ, wtedy wymyślilibyśmy ,,idealny system operacyjny'' od podstaw i napisali go w 2 minuty.
• i jeśli świat nie byłby losowy, to prawdopodobnie na tej planecie niczego by nie było, nigdy.

ale prawda jest taka, że my, ludzie mamy spore ograniczenia, nie rozumiemy tego losowego świata, więc nieuniknienie będziemy mieć sporo zabawy pisząc losowe kawałki linuksowego (lub innego) kodu przez najbliższe lata.

w rzeczy samej, większość książek informatycznych to świecący przykład ograniczeñ ludzkiego mózgu i jak małą i bezużyteczną część świata potrafimy dokładnie wyjaśnić ;-)

szczerze, byłbym *bardzo* zawiedziony, gdyby było możliwe przewidzenie przyszłości, i gdyby można było zrobić wystarczająco idealny system, który nie wymagałby zmian w najbliższej przyszłości. Byłbym bardzo zawiedzioną i znudzoną osobą, bo ktoś przewidziałby co się stanie i moglibyśmy tylko głupio podążać za tym wielkim planem. Ale prawda jest taka, że ten wielki plan nie istnieje. Jedną z ekscytujących rzeczy w tworzeniu systemu operacyjnego jest to, że nigdy nie wiemy co jest za rogiem.

Całość znana jako Linux, może wygladać uporządkowanie na mikro-poziomie (ten świat też *ma* jakieś zasady wewnątrz chaosu), ale po prostu *nie może* być niczym lepszym niż losowość na poziomie makro (długoterminowym). Więc lepiej przyznajmy to i dostosujmy się do tego.

A ktoś, kto wie lepiej, wie coś, co jest warte tuzina nagród Nobla.

Po przygotowaniu mojego wystąpienia na temat CBQ/HTB (http://ds9a.nl/cbq-presentation), udało mi się w koñcu zrozumieć, jak CBQ i filtry tak naprawdę działają. I zapisałem to. Sprawdźcie Linux Andvanced Routing & Shaping HOWTO, bardzo się zmieniło!

Zwłaszcza ta część jest bardzo nowa, sprawdźcie czy nie ma błędów i niejasności:

http://ds9a.nl/2.4Routing/HOWTO//cvs/2.4routing/output/2.4routing-9.html

Na dobry początek udało mi się rozpracować 'split' i 'defmap'. Nie ma żadnej innej strony w sieci, która by poprawnie mówiła, co te rzeczy robią.

Jeszcze jedno -- czy *ktokolwiek* rozumie, jak działają tablice haszujące w filtrze tc i wie, co one robią? Później chciałbym dostać trochę pomocy względem rzeczy związanych z nadzorem filtrów tc.

Jeśli zatem rozumiecie, jak te rzeczy działają, skontaktujcie się ze mną.

Dzięki Andreasowi Steinmetzowi i Davidowi Sauerowi, tablice haszujące tc są również udokumentowane. Dzięki!

Popatrzcie tu:

http://ds9a.nl/2.4Routing/HOWTO//cvs/2.4routing/output/2.4routing-12.html

A później ,,Filtry haszujące do bardzo szybkiego masowego filtrowania''.

Skoñczyłem także dokumentować wszystkie parametry dla TBF, CBQ, SFQ, PRIO, bfifo, pfifo i pfifo_fast. Wszystkie kolejki z jądra Linuksa są teraz opisane w Linux Advanced Routing & Shaping HOWTO, które to HOWTO znajdziecie pod adresem:

http://ds9a.nl/2.4Routing

Chcę to wysłać na LDP i Freshmeat jakoś w przyszłym tygodniu i *naprawdę chciałbym*, aby ludzie, którzy mają pojęcie o tym (tak, mówię o Was: ANK & Jamal 8) ), to przeczytali.

To HOWTO szybko staje się dość autorytatywnym źródłem informacji o sterowaniu ruchem w linuksie (google przy szukaniu 'Linux Routing' znajduje tę stronę), więc mogłoby być poprawne! Zatem, jeśli będziecie mieli trochę czasu, sprawdźcie części, na których się znacie. Spodziewam się, że są błędy.

Linus, nadszedł czas, aby przekształcić jądro 2.5 tak, aby wykorzystywało kbuild 2.5. Chcę to zrobić w kilku krokach, żeby było to mniej bolesne dla architektur, które nie zostały jeszcze objęte konwersją.

2.5.1 Półstabilne jądro, bio zaczyna działać.

2.5.2-pre1 Dodanie kodu kbuild 2.5, cały czas wykorzystującego Makefile-2.5. i386, sparc, sparc64 mogą używać kbuild 2.4 lub 2.5, ale wersja 2.5 jest zalecana. ia64 może używać wyłącznie kbuild 2.5. Inne architektury muszą cały czas używać kbuild 2.4. Czekamy 24 godziny na jakieś poważne problemy i wtedy --

2.5.2-pre2 Usunięcie kodu kbuilda 2.4, zmiana nazwy Makefile-2.5 na Makefile. Wersje dla i386, ia64, sparc, sparc64 mogą się kompilować z wykorzystaniem kbuild 2.5. Wersje na inne architektury nie będą się kompilować, dopóki nie zostaną przekształcone do kbuild 2.5. Grupa kbuild może pomóc przy konwersji, ale nie mając dostępu do odpowiednich maszyn, nie możemy przetestować tego. Użytkownicy tych architektur, do momentu przekształcenia, mogą pozostać przy 2.5.2-pre1.

Wykonanie zmiany w dwóch krokach powoduje powstanie platformy, gdzie będzie działać zarówno kbuild 2.4, jak i 2.5. To pozwoli innym architekturom na równoległe testowanie starego i nowego kbuilda przy konwersji, co wydaje mi się dość użyteczne.

Konwersja z CML1 na CML2 przyjdzie później -- w 2.5.3 lub 2.5.4.

Linus, czy to jest akceptowalne?

Specyfikacja do języka CML1 istnieje i jest zapisana w pliku, konkretnie w Documentation/kbuild/config-language.txt w drzewie jądra. Jest narzędzie (mconfig), które wykorzystuje parser wygenerowany przez yacc, który implementuje poprawnie i w pełni tę specyfikację. Jest również parę paskudnych skryptów w drzewie jądra, które lepiej lub gorzej sobie radzą z parsowaniem tego języka. Jest jeszcze trochę innych narzędzi, o których wiem niewiele, a które również rozumieją ten język.

Wszystkie te narzędzia wymagają jedynie środowiska wykonawczego określonego w LSB i nie potrzebują żadnych dodatkowych i śmiesznych języków skryptowch. I nie potrzebują pośredniej, binarnej reprezentacji konfiguracji.

Po raz kolejny zacytuję Linusa ze szczytu dotyczącego jądra 2.5: ,,Python nie jest problemem.'' Używając tego typu argumentów czynisz sobie więcej szkody niż pożytku, przynajmniej do momentu, gdy Linus zmieni zdanie.

Jeśli chcesz się ponownie zająć sprawą ratowania CML1, najlepiej pokaż, jak w CML1 można zrobić następujące rzeczy: (a) automatyczne wykonywanie zamierzonych efektów ubocznych przy zmianie symbolu, (b) zagwarantowanie, że użytkownik nie może wygenerować konfiguracji, która narusza niezmiennik stanu, (c) unifikację drzewa konfiguracji tak, aby odpowiedniki plików arch/* nie miały problemów, gdy do jądra zostanie dodana jakaś, niezależna od architektury cecha.

W zasadzie to ja nie mam problemu z CML2. Zgadzam się, że CML1 jest dość ograniczony i widzę zalety powstania nowego języka.

Mam jedynie zastrzeżenia do innych pomysłów, które zostały wprowadzone, aby zmienić zachowanie reguł konfiguracyjnych, które nie są bezpośrednio związane ze zmianami w języku.

Chciałbym mieć pewność, że wprowadzenie CML2 nie spowoduje włączenia kontrowersyjnych zmian w zachowaniu konfigu, które mają uszczęśliwić Ciocię Klocię, podczas gdy te zmiany powinny być poddane pod indywidualną rozwagę, a nie przedstawiane, jako ukoñczone dzieło.

Jeśli nie mogę mieć jednego bez drugiego, wolę nie mieć nic -- CML1 być może obsysa, ale nie obsysa _aż_ tak.

Ale sądzę, że możemy Ci w tej kwestii zaufać -- nieprawdaż?

Reguły są niemal identyczne (ale zapisane w innym języku). Problem był przy konwersji reguł: esr znalazł wiele błędów: te błędy powinny zostać poprawione, więc i reguły się zmieniły.

Również przy konwersji reguł znalazłbyś błędy: np. zła składnia zależności, zła implementacja, ...

Nie sądzę, aby esr zmieniał reguły, które nie sprawiają problemów, z jednym wyjątkiem: wszystkie nieudokumentwane reguły, będą automatycznie zależne od CONFIG_EXPERIMENTAL. Nie podoba mi się to, ale rozumiem, czemu podjął taką decyzję.

Zapamiętaj: Pliki config.in zawierają wiele błędów i nie znajdziesz ich przy pomocy automatycznych narzędzi.

ta zmiana nie jest sztywna. Zakomentuj tę deklarację w głównym pliku reguł:

condition nohelp on EXPERT

i to przywróci stare zachowanie.

Każde nowe jądro wymagało nowych narzędzi, 2.2 szczególnie wielu, 2.4 także kilku, więc to jest właściwie tylko jedno wymagane narzędzie więcej.

Obecne dystrybucje już zawierają Pythona 2 i przypuszczalnie, w momencie, gdy Python 2 będzie potrzebny do skonfigurowania Linuksa 2.5 czy 2.6, wszystkie będą.

Ups. Nie miałem zamiaru tego nikomu jeszcze mówić, ale skoro wysunąłeś ten argument, czuję że muszę stawić temu czoła...

Gdy CML2 udowodni swoją przydatność w 2.5, mam zamiar zwrócić się do Marcelo i namawiać go, aby zaakceptował CML2 w 2.4, motywując to tym, że zrobienie tego znacznie ułatwi opiekę nad jądrem. To jest przyczyna, dla której śledzę obie ścieżki po rozdziale zestawu reguł, więc będzie to łatwa podmiana zarówno dla Marcelo, jak i dla Linusa.

Nie rób tego! Stabilne jądro powinno być stabilne również w odniesieniu do narzędzi do budowania. Gdy Marcelo poprawi kilka istotnych z punktu widzenia bezpieczeñstwa systemu błędów, użytkownik będzie chciał przebudować jądro i okaże się, że musi zainstalować kilka nowych pakietów (komputery z 2.4 są już popularne, python2 -- nie tak bardzo), aby zabezpieczyć jądro i nie będzie szczęśliwy.

To jest przykład, ale lepsza zarządzalność spowoduje poważne problemy dla nowych użytkowników jądra.

Marcelo,

po dłuższej dyskusji, która odbyła się poza listą, wychodzi na to, że wyodrębnienie przypadków specjalnych w printk, jest przypuszczalnie najlepszym sposobem rozwiązania następującego problemu.

Problem polega na tym, że butujący procesor ładuje sterowniki konsoli i jest w stanie odwołać się do nich przy pomocy printk(), ale procesory aplikacyjne, w tym samym czasie, nie są w stanie wywołać printk(), ponieważ mapowanie sterownika urządzenia konsoli nie jest jeszcze wykonane. Odwrócenie tego wewnątrz kodu butującego ia64 jest skomplikowane i delikatne. Przypuszczalnie problem istnieje również na innych platformach, ale to jeszcze nie wyszło na jaw.

Tak więc, łata definiuje zależne od architektury makro `arch_consoles_callable()', które, jeśli nie zdefiniowane jest równoważne `1', tak aby wpływ na inne platformy (oraz jednoprocesorowe ia64) był żaden.

Nie, jeśli nie masz dostępu do konsoli, aby wypisać komunikat :)

Ja po prostu wolałbym widzieć takie rzeczy poprawione w kodzie zależnym od architektury, zamiast mnożyć specjalne przypadki w ogólnym kodzie.

Jedynie specyficzne dla architektury problemy powinny być rozwiązywane w kodzie specyficznym dla danej architektury.

Nie jestem przekonany, czy ten problem należy do tego gatunku. Być może jest, a jeśli tak, to będę zadowolony naprawiając to w kodzie ia64.

Ja mogę to wyjaśnić. Stary rdzeñ devfs wybaczał istnienie podwójnych wpisów, czego nowy rdzeñ nie robi (przekazuje teraz błędy EEXIST).

Istnieją pewne, zepsute skrypty inicjujące (wzorowane na dawno już przestarzałym skrypcie rc.devfs), które wrzucają kupę i-węzłów do /dev, przed ładowaniem różnych modułów. Sterowniki, które są po tym ładowane, nie będą więc mogły stworzyć swoich wpisów w devfs (ponieważ stare wpisy wciąż istnieją).

Nie stanowi to problemu dla urządzeñ w /dev, ponieważ urządzenia tworzone w przestrzeni użytkownika wciąż będą pracować. Zaowocuje to tylko ostrzeżeniem. Jest to natomiast potencjalny problem dla katalogów, jeżeli wszystkie wymienione warunki zostaną spełnione:

• skrypty inicjalizacyjne tworzą katalog w /dev
• sterownik ładuje się i próbuje utworzyć taki sam katalog (niepowodzenie)
• sterownik tworzy wpis urządzenia w tym katalogu, używając uchwytu, uzyskanego podczas tworzenia katalogu
• wpisy urządzeñ, które sterownik próbuje utworzyć, nie były stworzone przez skrypt inicjalizacyjny (np. proces od-tarowania).

Jest to niezmiernie rzadki przypadek. Zazwyczaj, jeżeli ,,odtwarzasz'' pewne i-węzły, będziesz przywracał zarówno pojedyñcze wpisy urządzeñ, jak i nadrzędne katalogi (w innym wypadku -- jaki jest sens odtwarzania?). Więc, w tym przypadku, wpisy urządzeñ, których chce używać użytkownik, wciąż tam będą (stworzone przez skrypt inicjalizacyjny) i będą pracować poprawnie. Pojawi się tylko kupa ostrzeżeñ.

Być może, w zależności od sterownika, wpisy urządzeñ, które próbował stworzyć, mogą się pojawić w katalogu /dev, zamiast w zamierzonym podkatalogu. Mimo, iż jest to być może bałaganiarskie, nie jest tak naprawdę szkodliwe.

Wątek ten został zapoczątkowany z powodu raportu o dwóch błędach. Pierwszy z nich to nieszkodliwe ostrzeżenia o podwójnych wpisach. Nic się nie zepsuło.

Drugi błąd był spowodowany niewłaściwym plikiem konfiguracyjnym devfsd, który sprawił, iż katalogowi zostały nadane złe prawa dostępu. Z tego powodu Roman myślał, że nowy rdzeñ devfs psuje te rzeczy. Jak pokazałem powyżej, możliwość zepsucia jest minimalna, wynika z przestarzałego skryptu.

Generalnie, jeżeli tarujesz i roz-tarowujesz i-węzły, bierzesz cały katalog i odkładasz go ponownie. Nawet partycjonowanie jest rzadkim przypadkiem, ponieważ zazwyczaj instalujesz nowy dysk (tym samym -- nie masz nic do ,,odtworzenia'') i dopiero wtedy partycjonujesz. I nawet przestarzały rc.devfs zapisywał tylko i-węzły, które się zmieniły, nie wszystkie.

Jednakże, jeżeli to Cię interesuje, mogę wysłać Ci łatę, która efektywnie przywraca stare zachowanie dla katalogów. To tylko sprawa łapania właściwej blokady, zmiany flagi i zwrócenia innego wpisu. Ale zdecydowanie chcę pozostawić komunikat z ostrzeżeniem. Chcę, żeby zabolało to trochę zepsute, lub całkowicie przestarzałe konfiguracje.

Kto jest opiekunem sterownika?

Spróbuj myśleć od mojej strony: mogę nie mieć sprzętu, lub czasu, aby przetestować wszystkie łaty, które do mnie trafiają.

Proszę Was, wysyłajcie tego typu zmiany sterowników ludziom, którzy znają szczegóły specyficzne dla sprzętu.

Jeżeli kod i810 nie ma opiekuna, będę rad, dołączając kod do 2.4.18pre i czekając na raporty. Jednak nie włączę go do 2.4.17.