Wygląda na to, że jest ich więcej ze względu na format changeloga.

Stare zmiany były określane jednolinijkowcami, a ja omijałem małe zmiany (np. takie pozycje jak ,,Usunięcie ostrzeżenia przy konwersji i-węzłów w /proc'' nigdy wcześniej nie pojawiały się w changelogu).

Poza tym, łączyłem różne pozycje od tej samej osoby, więc osiem łat do reiserfs tworzyłoby jedną pozycję (,,aktualizacja reiserfs''), a 20 pozycji od Jeffa w ten sam sposób też tworzyłoby jedną (,,aktualizacja sterowników sieciowych'').

Do tego ten tydzieñ spędziłem _wyłącznie_ na upewnianiu się, że pracuję poprawnie z BitKeeperem (na razie wygląda, że jest dobrze), więc na łączeniu spędziłem więcej czasu niż zwykle. Ale to się raczej uspokoi.

(Dobrą wiadomością jest to, że sądziłem, że na jakiś czas używanie BK spowolni moją pracę, ale tak się nie stało. Niektóre rzeczy wymagają teraz więcej wysiłku, ale jednocześnie inne rzeczy są _o wiele_ prostsze, więc...)

prawdę mówiąc, to nie Marcin nie umie pracować z Andre, to Andre cały czas pokazuje, że _zupełnie_ nie jest w stanie pracować z kimkolwiek.

Gdy ktoś przychodzi i próbuje wykonać trywialne i w oczywisty sposób poprawne czyszczenie kodu, które w ogóle nie zmienia jego semantyki, Andre stawia się i piłuje mordę, całkowicie ignorując fakt, że nawet nie zajrzał do tych łat.

Wszystkie bzdury, które Andre wykrzyczał na temat ,,bałaganu w IDE'' i ,,zmian czasów dostępu'' to KUPA GóWNA. Żadna z spośród tych łat, które widziałem nie zmieniała _nic_ istotnego, to były tylko zmiany kosmetyczne, żadna nie usunęła także _jakiejkolwiek_ właściwości.

Chłopaki, musicie zrozumieć, że to NIE Marcin jest tym złym w tym przypadku. Problemem nie jest Marcin, problemem jest to, że Andre nie może znieść nawet odrobiny krytyki i chciałbym zobaczyć choć _jedną_ osobę, która była w stanie współpracować z nim przez jakieś ostatnie pięć lat, gdy był opiekunem (nie mówię tu o kilku osobach, które były w stanie się opiekować własnymi podsterownikami _niezależnie_ od niego).

Andre, Twoje groźby, że nie będziesz się opiekował 2.5.x, są po prostu symptomem Twojej niezdolności do zaakceptowania faktu, iż inni najzwyczajniej w świecie wiedzą, co robią, nawet jeśli to, co robią, to zwykłe czyszczenie kodu bez żadnych zmian w semantyce.

Rik, _popatrz_ na łaty, zamiast brać słowo Andre za dobrą monetę.

Z całą pewnością masz jakiś wrzód na dupie, więc umywam ręce do czasu, gdy załatwisz to z Marcinem. Do zobaczenia przy 2.5.10. Nie będę komentował zmian, ponieważ chcesz czegoś, ja nie mam czasu by ci to dostarczyć, a ty jesteś zły z tego powodu.

Bardziej interesuje mnie stabilność rdzenia ATA/ATAPI, a następne w kolejce było wyłuskanie wszystkich kwestii związanych z fazami danych ATAPI, które wydają się sprawiać problemy.

Rozumiem, że chcesz dokonać kosmetycznych zmian, ale ja nie jestem na nie gotowy.

Będę zatem cierpliwy i poczekam aż wprowadzisz kosmetyczne zmiany, które chcesz, a następnie zobaczę co powinno być później ocalone.

To, co mnie w tym naprawdę wkurza to to, że gdy zazwyczaj jesteś po prostu mało komunikatywny, tym razem _kłamałeś_ w żywe oczy na temat łat na IRC i w poczcie elektronicznej - o tym, że powodują one uszkodzenie IDE itp. w związku ze zmianami czasów dostępu.

Nie było żadnych takich zmian w timingu, a za każdym razem, gdy pytano Cię, co konkretnie było _złego_ w łatach, nie odpowiadałeś.

Jest różnica pomiędzy byciem trudnym we współpracy i byciem najzwyczajniej nieuczciwym, a Ty właśnie przekroczyłeś tę granicę.

"KŁAMIE, KŁAMIE! POWIEM MAMIE!"

Linus,

Dorośnijmy obaj!

Powtórzę to, co napisałem w prywatnym, tylko-do-Ciebie emailu: _każdy_ zarzut, który stawiałeś wobec tych łat, był w 100% nieprawdziwy.

Łata była nazwana ,,Czyszczenie IDE'' i takie czyszczenie zawierała. Nic więcej. Czasy dostępu się nie zmieniły, aczkolwiek głupie (dwukrotnie zduplikowane) funkcje, które je ,,obliczały'' zostały usunięte i zastąpione jednym obliczeniem w trakcie uruchamiania systemu.

Marcin nie tylko umieścił ,,czyszczenie'' w linii tematu, ale także wyjaśnił wszystkie zmiany, włączając w to zmiany czasów dostępu. Komentarz na początku maila z łatą mówi (na temat tej zmiany, która jest Twoim ulubionym celem):

3. Zastępuje funkcjonalność całkowicie identycznych funkcji system_bus_block() i ide_system_bus_speed() jedną prostą zmienną globalną: system_bus_speed. To pozwala na usunięcie dość dużej ilości kodu. Niestety to w sposób dość znaczny zwiększa objętość samej łaty...

a zawartość łaty zdecydowanie się zgadza z tym, co mówi Marcin.

Twoje lamentowanie na linux-kernel i na kanałach IRC jest zupełnie nieprawdziwie i świadczy o tym, że nie przeczytałeś wyjaśnienia _lub_ samej łaty. I wielokrotne pokazywanie tego nic nie zmienia.

Jak radzić sobie z pingwiniastym BK

Ten zestaw uwag jest przeznaczony głównie dla deweloperów jądra, zarówno tych pracujących cały czas nad jądrem, jak i tych, co robią to czasami, ale administratorzy i niektórzy użytkownicy mogą także znaleźć coś użytecznego. Zakładam tu przynajmniej podstawową znajomość z CVS-em, zarówno na poziomie użytkownika (z linii poleceñ), jak i na wyższym poziomie (model klient-serwer). Ponieważ autor zna się akurat na CVS, to operacje będą opisane przez podanie odpowiedników z CVS, albo przez podanie różnic w stosunku do operacji CVS.

Poniższy tekst -nie- jest pomyślany jako dokumentacja BitKeepera. W celu uzyskania stosownej dokumentacji należy zawsze posłużyć się poleceniami ,,bk help <polecenie>'' lub ,,bk helptool <polecenie>'' w Xach.

Założenia BitKeepera

BitKeeper jest systemem rozproszonym, bo taka jest natura Internetu. W przypadku kontroli wersji, oznacza to odejście od modelu klient-serwer i przejście do modelu rodzic-potomek... generalnie do modelu ,,każdy z każdym''. Z punktu widzenia dewelopera jest to także istotne zniszczenie wyobrażeñ o standardowym przepływie zmian, zatwierdzeñ i łączeñ fragmentów kodu. Będziecie zmuszeni zastanowić się jak najlepiej pracować pod kontrolą BitKeepera i troszeczkę pozmieniać niektóre rzeczy. W pewnym sensie jest zmiana bardzo istotna, bo pracę z BK można opisać jako wrzucanie zmian w pewien wir i czekanie na ich magiczne lądowanie w odpowiednich miejscach... zanadto wyprzedzam.

Zacznijmy się posuwać naprzód:
Każde drzewo źródeł z BitKeepera na dysku jest własnym repozytorium.
Każde repozytorium ma rodzica.
Każde repozytorium zawiera zestaw zbiorów zmian (changesets, w skrócie ,,csets'').
Każdy cset to zmienione pliki zebrane razem.

Każde drzewo jest repozytorium, zatem wszystkie zmiany są zatwierdzane w lokalnym drzewie. Jeśli zmiana jest wprowadzana i zatwierdzana, to wszystkie zmodyfikowane pliki są grupowane w pewną logiczną jednostkę - zbiór zmian. Patrząc ,,od środka'', BK łączy te zbiory zmian z drzewem, a takie zbiory zmian reprezentują różne, zbiegające i rozbiegające się drogi rozwoju kodu. Zbiory zmian stanowią całą siłę systemu.

Musicie się przyzwyczaić do tego, że do pracy potrzebne wam będzie wiele kopii źródeł; to jest następna, po zbiorach zmian, ważna rzecz. Niektórym ludziom przyzwyczajenie się do tego jest -naprawdę- kłopotliwe. Oddzielne drzewa kodu źródłowego są sposobem, w jaki można podać BitKeeperowi równoległe drogi rozwoju, zarówno te główne, jak i poboczne. To co w CVS-ie byłoby gałęziami, staje się oddzielnymi projektami; w terminologii BitKeepera [heh albo Gwiezdnych Wojen] nazywa się je ,,klonami''.

Klony i zbiory zmian to narzędzia, z których bierze się większość siły BitKeepera. Jak już wcześniej wspomniałem, każdy klon ma rodzica - drzewo użyte jako źródło w trakcie tworzenia nowego klona. W układzie CVS-a rodzic byłby zdalnym serwerem w Internecie, a potomek lokalną kopią tego zdalnego drzewa.

Gdy uda się ustalić wspólną podstawę, z której powstały dwa drzewa źródeł -- wspólnego przodka -- wtedy można łatwo łączyć zbiory zmian pomiędzy tymi dwoma drzewami. Włączanie zmian do drzewa to operacja ,,pull'' i jest ona analogiczna do ,,cvs update''. Wykonanie ,,pull'' ściąga ze zdalnego repozytorium wszystkie zbiory zmian, których nie ma lokalnie i łączy je. Wysyłanie zmian z jednego drzewa na drugie to ,,push''. Operacja ,,push'' wysyła wszystkie zmiany w lokalnym drzewie, które nie są obecne w zdalnym i je włącza.

Te podstawowe założenia pozawalają pokazać pierwsze przykłady:

1. bk clone -q http://linux.bkbits.net/linux-2.5 linus-2.5
   Ściągnij do lokalnego katalogu główne drzewo jądra 2.5, nazywając je ,,linus-2.5''. Opcja ,,-q'' wyłącza wyświetlanie listy plików w trakcie ściągania.

2. bk clone -ql linus-2.5 alpha-2.5
   Stwórz osobne drzewo źródeł dla architektury Alpha AXP. Opcja ,,-l'' wskazuje, że zamiast kopiowania danych użyte zostaną twarde dowiązania, jako że oba drzewa znajdują się na lokalnym dysku. Można także zamienić powyższe na ,,bk lclone -q ...''

   Każde drzewo można sklonować tylko -raz-. Po sklonowaniu drzewo żyje sobie długo na dysku będąc aktualizowane przez operacje push i pull.

3. cd alpha-2.5 ; bk pull http://gkernel.bkbits.net/alpha-2.5
   Ściągnij zmiany z repozytorium ,,alpha-2.5'', których nie ma w repozytorium lokalnym i włącz je do drzewa zmian.
4. bk -r co -q
   Ponieważ każde drzewo jest repozytorium, to wszystkie pliki muszą być z niego wyciągnięte zanim znajdą się w swoich standardowych miejscach w drzewie źródeł.

5. bk vi fs/inode.c                                # przykładowa zmiana ...
   bk citool                                       # wprowadzenie zmiany przy użyciu narzędzia pod X 
   bk push bk://gkernel@bkbits.net/alpha-2.5       # przesłanie zmiany 

   Typowy przykład ciągu zmian, który zastąpi analogiczną sytuację przy użyciu CVS:

   vi fs/inode.c
   cvs commit

Ponieważ ma to być tylko szybkie wprowadzenie do BK, aby uzyskać bardziej dogłębne podręczniki, demonstrację na żywo i dokumentację odwiedź stronę http://www.bitkeeper.com/

Sposób pracy nad jądrem przy użyciu BK

Ostatnie jądra serii 2.5 są obecnie dostępne przez ,,bk clone $URL'' i ,,bk pull $URL'' pod adresem http://linux.bkbits.net/linux-2.5 W ciągu kilku tygodni URL powinien się zmienić na jakiś na kernel.org.

Duża część pracy z BitKeeperem polega na dobrej organizacji różnych drzew na lokalnym dysku oraz organizacji przepływu zmian pomiędzy tymi drzewami i drzewami zdalnymi. Jeśli ktoś chciałby graficznie zobrazować związki w pożądanym układzie drzew BK, to powinien wyjść mu graf typu wiele do wielu, podobny do tego:

            linux-2.5
                |
       merge-to-linus-2.5
         /    |      |
        /     |      |
vm-hacks  bugfixes  filesys   personal-hacks
      \       |      |          /
       \      |      |         /
        \     |      |        /
         testing-and-validation

Ponieważ ,,bk push'' wysyła wszystkie zmiany, których nie ma w docelowym drzewie i ponieważ ,,bk pull'' otrzymuje wszystkie zmiany, których nie ma w drzewie źródłowym, potrzebujemy zapewnienia, że dokładamy tylko zmiany specyficzne dla pożądanego drzewa, a nie wszystkie zmiany z drzew rodziców. Na przykład przesuwanie zmian z drzewa testing-and-validation nie byłoby najprawdopodobniej dobrym pomysłem, gdyż przesunęłoby to wszystkie zmiany z drzew vm-hacks, bugfixes, filesys i personal-hacks do drzewa docelowego.

Jedna osoba, w większości przypadków, pracuje nad jednym ,,tematem'' w jednym momencie - albo nad vm-hacks, albo nad bugfixes, albo nad filesys, trzymając te zmiany w trakcie pracy osobno, w odrębnych drzewach, a łącząc je z innymi zmianami tylko w przypadku przesuwania ich ,,w górę'' (do drzew Linusa lub innych opiekunów jądra), albo ,,w dół'' (do własnego drzewa z sumą zmian, takiego jak pokazane wyżej testing-and-validation).

Warto zauważyć, że część tego podziału jest nie tylko rekomendowaną praktyką, tak naprawdę [przynajmniej teraz] jest -wymuszana- przez BitKeepera. BitKeeper wymaga, żeby zbiory zmian były utrzymywane w pewnym porządku, dlatego też ,,bk push'' wysyła wszystkie zmiany w lokalnej kopii, których nie ma w zdalnym drzewie. To oddzielenie na pierwszy rzut oka wygląda trochę na marnowanie miejsca na dysku, ale bardzo pomaga w sytuacji, gdy dwie niezwiązane ze sobą zmiany mogą ,,zatruć'' ten sam obszar kodu, albo idą w tym samym kierunku, czy też z każdego innego ze standardowych powodów, dla których tworzy się różne gałęzie rozwoju.

Małe gałęzie rozwoju (klony) mogą się pojawiać i znikać:

-------- A --------- B --------- C --------- D -------
          \                                  /
           -----gałąź rozwojowa krótkoterm.--

Długoterminowe gałęzie zrównoleglą drzewo (lub drzewa), a łączenie będzie odbywało się co jakiś czas. W tym pierwszym przykładzie wykonujemy pull z drzewa (pull oznaczone jest przez ,,\'') co pewien czas, tak jak to zdarza się, gdy śledzimy zmiany w czyimś drzewie, nigdy nie umieszczając w nim własnych zmian:

-------- A --------- B --------- C --------- D -------
          \                       \           \
           ----gałąź długoterminowa ------------------

Znacznie częstszy przypadek przy rozwoju jądra Linuksa; długoterminowa gałąź z okresowymi włączeniami zmian z powrotem do głównego drzewa (push oznaczono przes "/"):

-------- A --------- B --------- C --------- D -------
          \                       \         / \
           ----gałąź długoterminowa -----------------

Przesyłanie zmian Linusowi

Przesyłanie zmian Linusowi to pewnego rodzaju sztuka, liczy się też tu styl. Ponieważ jądro Linusa jest aktualnie w pełni zintegrowane z rozproszonym systemem BitKeeper, to pojawiło się kilka wstępnych warunków właściwego przesyłania zmian. Wszystkie te warunki wynikają z użytkowania BK, są bardzo ogólne. W chwili kiedy wszyscy staną się ekspertami od BK, z powodzeniem mogą optymalizować ten proces (zakładając oczywiście, że Linus się na to zgodzi).

1. Upewnij się, że twoje drzewo zostało sklonowane z drzewa linux-2.5 tworzonego przez Linusa. Jeśli twoje drzewo nie ma takiego przodka, to trudno będzie polegać na wymianie zbiorów zmian między tymi drzewami.

2. Zwróć uwagę na tekst z jakim potwierdzasz zmiany. Informacja, która dołączana jest do każdego zbioru zmian będzie wiecznie obecna w ich historii i jest używana przez Linusa w celu dokładnego podsumowywania zmian w każdej łacie pre. Pamiętaj, że ta informacja występuje tam pozbawiona kontekstu, zatem

   ,,poprawka dotycząca zmian w nowym schedulerze''

   byłaby zbyt niejasna, ale

   ,,poprawka w architekturze mips64 dotycząca nowego switch_to() w schedulerze, semantyka TIF_xxx''

   wygląda znacznie lepiej.

   Możecie i powinniście używać polecenia ,,bk comment -C<rev>'' w celu aktualizacji i poprawek w tekście dołączanym do zatwierdzanych zmian. Takie postępowanie może być bardzo wygodne w trakcie pracy: ubogie, krótkie opisy podczas pracy, które zostają poprawione przy użyciu ,,bk comment'', przed wykonaniem ,,bk push'' w celu przesłania zmian.

3. Załączajcie dostępny z Internetu URL, tak żeby Linus mógł wykonać z niego ,,pull'', w następujący sposób:

   Pull from: http://gkernel.bkbits.net/net-drivers-2.5

4. Załączajcie podsumowanie i wynik ,,diffstat -p1'' dla każdego zbioru zmian, który będzie ściągnięty, gdy Linus wykona ,,bk pull''. Autor może automatycznie wygenerować te podsumowania, używając ,,bk push -nl <parent> 2>&1'' i uzyskując wykaz wszystkich oczekujących na wysłanie zbiorów zmian wraz z towarzyszącymi im komentarzami.

   Pokazanie Linusowi co tak naprawdę mu się ściągnie po wykonaniu ,,bk pull'' redukuje czas potrzebny na przesianie tych zmian po ich pojawieniu się na jego lokalnej maszynie.

   WAŻNE: Jedną z cech BK jest to, że twoje repozytorium nie musi być aktualne, żeby Linus mógł dostawać zmiany. Utrzymywanie w miarę świeżego repozytorium jest pewną grzecznością, pozwalającą zmniejszyć ilość potencjalnej pracy Linusa przy włączaniu.

5. Dziel swoje zmiany. Każda sytuacja na linii opiekun<->Linus może być inna, więc uznaj to za ogólną poradę. Autorzy zmian dzielą je zgodnie z ich ,,tematami'' zanim włączą je do drzewa Linusa. Tworzy się specjalne drzewa, istniejące tylko w charakterze ,,kolejek'' zmian, które są równolegle przesyłane Linusowi. Przykład takich drzew to:

   net-drivers-2.5 -- utrzymywanie sterownika sieciowego
   vm-2.5 -- zmiany związane z VM
   fs-2.5 -- zmiany związane z systemem plików

   To pozostawia Linusowi więcej wolności we włączaniu zmian. Mógłyby on (na przykład) wykonać ,,bk pull'' dla drzew vm-2.5 i fs-2.5 żeby włączyć ich zmiany, ale wstrzymać net-drivers-2.5, bo zmiana ta wymaga dłuższej dyskusji.

   Niektórzy opiekunowie mogą uznać, że pojedyncze drzewo dla Linusa jest odpowiednie do przekazywania mu zbiorów zmian z BK.

Najczęściej Odpowiadane Pytania

1. Jak zmienić adres poczty elektronicznej pojawiający się na liście zmian?
   A. Gdy uruchamiasz ,,bk citool'' lub ,,bk commit'' nadaj zmiennym systemowym BK_USER oraz BK_HOST wartości takie jak pożądana nazwa użytkownika oraz nazwa komputera/domeny.

2. Jak używać znaczników / jak uzyskać diff między dwiema wersjami jąder?

   A. Przekaż używane przez Linusa znaczniki poleceniu ,,bk export''.

   Zbiory zmian są utrzymywane w porządku ich rozwoju, zatem jest dość łatwo uzyskać ,,migawkę'', która zaczyna się i koñczy w dowolnym momencie. Linus umieszcza znaczniki na każdej wersji finalnej i wersji pre, zatem można użyć następujących dwóch przykładów:

   bk export -tpatch -hdu -rv2.5.4,v2.5.5 | less
   # tworzy patch-2.5.5
   bk export -tpatch -du -rv2.5.5-pre1,v2.5.5 | less
   # daje zmiany między pre1 a wersją finalną

   Znacznik jest po prostu aliasem pewnego konkretnego zbioru zmian... a ponieważ zbiory zmian są uporządkowane, to znacznik jest tylko markerem pewnego momentu (albo konkretnego stanu drzewa).

Cóż, zakładając, że napisze ci, iż jest pewien problem, uruchom po prostu ,,bk undo -r <rev>..'' w celu usunięcia zbioru łat, które mu się nie podobają (taka jest teoria). Jeśli została zrobiona duża liczba zmian po <rev>, to zostaną one wszystkie usunięte (nie ma możliwości usunięcia pojedynczego CSET ze środka drzewa). Potem należy powtórzyć zmiany w sposób, który pasuje Linusowi i przesłać nowy CSET.

Możesz także dodać poprawkę do tego samego drzewa i mieć nadzieję, że zaakceptuje on oba CSETy, ale sądzę, że Linus nie chce zaśmiecać swojego drzewa sekwencjami <łatka>+<poprawka>, woli pojedynczo: <łatka>, która jest od razu właściwa.

W niektórych przypadkach lepiej chyba zapisać zmiany w <rev> jako diff, ściągnąć nowe drzewo BK od Linusa, ponownie nałożyć łatki oraz poprawki i wygenerować z tego nowy CSET.

Nie jest to doskonałe, ale takie jest życie.

Jeśli chcesz tylko co pewien czas przesyłać pojedyncze CSETy Linusowi lub Dave'owi Jonesowi (czyli należysz do kategorii, do której należy większość), to zawsze możesz przesłać CSET pocztą elektroniczną, zamiast udostępniać drzewo. Przeszukaj archiwum l-k, może znajdziesz mój skrypt ,,bksend'', który ładnie formatuje takie listy.

Jedną z korzyści używania BK w porównaniu z pojedynczymi łatami, nawet w tej sytuacji, jest to, że jeśli twoje drzewo nie jest dokładnie tą wersją drzewa, którą ma Linus, to BK CSET będzie wiedziało względem której wersji drzewa były wygenerowane zmiany i pozwoli Linusowi łatwiej je nakładać i rozwiązywać konflikty.

Możesz utworzyć drzewo dostępne publicznie; jeśli tego potrzebujesz sprawdź odnośnik Hosting na naszych stronach. Takie, publicznie dostępne drzewo, może być przygotowane na wiele sposobów, z różnymi poziomami bezpieczeñstwa, przeczytaj ,,bk help bkd'', aby uzyskać informacje.

Zaletą umożliwienia wykonywania mu operacji ,,pull'' jest to, że nie będziesz miał tych samych danych dwa razy w twoim drzewie BK, które miałbyś, gdybyś wysyłał mu diffy i potem ściągał te same diffy od niego. To jest SZCZEGóLNIE WAŻNE, jeśli masz zmiany nazw (a utworzenia/usunięcia są pewnego rodzaju zmianą nazwy) w swojej łacie.

Jeśli sytuacja wygląda tak, że stworzyłeś od podstaw drzewo, specjalnie w celu przesyłania jakichś rzeczy Linusowi i nie masz zamiaru używać go w żadnym innym celu, to możesz przesyłać mu zwykłe diffy i wyrzucić drzewo, gdy dowiesz się, że Linus już je zaakceptował.

Repozytorium z Linuksem 2.4 na linux.bkbbits.net zostało osierocone krótko po stworzeniu. Czy jest jakaś szansa, aby w sposób ciągły pojawiały się tam zmiany?

Sądzę, że dobrym pomysłem byłoby automatyczne umieszczanie tam zmian od razu po tym, jak Marcelo wrzuci nową wersję pre, jako część procedury powiadamiania na kernel.org (czy to jest możliwe, Peter?).

Jeśli nie ma sposobu na zautomatyzowanie tego, to zgłoszę się na ochotnika i będę robił uaktualnienia, ale w tym celu potrzebowałbym praw zapisu do repozytorium.

Parę użytecznych materiałów:

http://www.bitkeeper.com/cvs2bk.html

http://www.bitkeeper.com/Test.html

http://news.linuxprogramming.com/news_story.php3?ltsn=2002-02-21-001-06-DT-HT

Ostatnia pozycja to artykuł Jeffa, całkiem niezły.

Dodatkowo, jeśli chcesz, jeden z nas może wejść na IRC i w trakcie, gdy ty będziesz przeglądał demonstrację, odpowiedzieć na twoje pytania.

Obiecałem już marcelo, że przygotuję mu jakieś repozytoria, jedno z utrzymywanym przez Jeffa drzewem marcelo-2.4 i parę z łatami do połączenia z 2.4.

Potem poprowadzę marcelo przez proces włączania łat przy użyciu bitkeepera (a raczej pozwolenia bitkeeperowi zająć się tym wszystkim) oraz ogólnie zaznajomię marcelo z ważnymi poleceniami bitkeepera i niektórymi skryptami zewnętrznymi.

Najważniejszą rzeczą jest to, że musisz obserwować zmiany nazw w łatach. bk import -tpatch to obsługuje, gołe łaty tego nie potrafią. Jeśli nie zauważysz zmian nazw, to życie będzie obsysało, ponieważ jeden plik będzie wykasowany w twoim drzewie, a może nie być jeszcze wykasowany w innym. Jeśli inne osoby pracują na starym drzewie, a ty od nich coś wyciąniesz, to zrobione przez nich łaty trafią do usuniętego pliku. One tam są, ale dość bezużyteczne, jeśli chciałeś je mieć w pliku z nową nazwą.

Musimy dopracować rzeczy, tak by można było używać bk import -temail albo czegoś podobnego i jest to połączenie skryptów Linusa z obecnym kodem. Linus? Skrypty?

Moje skrypty znajdują się na master.kernel.org:/home/torvalds/BK/tools, jednakże nie przejmowałem się ich czyszczeniem, mimo że powinny być wyczyszczone (chodzi o sprawy takie jak parsowanie emaili, które psuje się ze względu na MIME i/lub ciąg ,,^From '' w ciele wiadomości itp.).

Narzędzia te zawierają wszystkie skrypty, które pozwalają przygotowywać changelogi, nakładać łaty z listów elektronicznych itp.

Wymagają one najnowszego bitkeepera, który przyjmuje komentarze i informacje od użytkownika przy ,,bk import -tpatch''.

(Tia, ,,master'' nie jest otwartą maszyną, ale Marcelo, Rik, Jeff i inni mogą się na nią dostać, a jeżeli ktoś chce przenieść te narzędzia gdzie indziej, może to oczywiście zrobić).

Oto pierwotna łata implementująca jakąś wersję szeregowania NUMA na łacie schedulera K3 Ingo do 2.4.17. To jest BARDZO wczesna wersja kodu, która pokazuje kilka kwestii, które muszą zostać przedyskutowane/przeanalizowane dokładnie. Łata została przygotowana raczej jako punkt wyjścia dla tej dyskusji, niż jako gotowe rozwiązanie. Łata została przygotowana dla systemu NUMA opartego na i386, do którego mam dostęp. Nie będzie działać na innych architekturach. Jednakże jedynym zależnym od architektury kodem jest inicjalizacja niektórych specyficznych dla NUMA struktur danych do szeregowania. Z tego powodu nie powinno być większych problemów z rozszerzeniem tego na inne architektury.

Oto, co robi łata:

• Tworzy ,,zbiory cpu'', które stanowią zbiory procesorów, dla których zadania mogą zostać uszeregowane. Procesory w tych zbiorach powinny mieć coś wspólnego, jak lokalna pamięć, dzielony cache, itp.
• Generalnie, gdy wykonanie zadania rozpoczyna się w danym zbiorze cpu, pozostaje w tym zbiorze. Kod równoważący obciążenie ze schedulera K3 jest wykorzystywany do rozkładania obciążenia pomiędzy procesorami w zbiorze.

• Rozkładanie obciążenia występuje także pomiędzy granicami zestawów procesorów. Takie równoważenie obciążenia może wystąpić:

  • w momencie wykonania. To jest oczywisty wybór, ponieważ w tym momencie możemy po prosty wyrzucić przestrzeñ adresową zadania i utworzyć nową. Wykonujące się zadanie jest przenoszone do najmniej obciążonego zbioru procesorów.
  • gdy procesor zaczyna się nudzić. W tym momencie szukamy innego zadania z danego zbioru procesorów do uruchomienia. Jeśli nie ma żadnego zadania dla tego zbioru, próbujemy przejąć zadanie z najbardziej obciążonego zbioru.
  • w określonych przedziałach czasu, gdy procesor się nudzi. W schedulerze K3, kod zegara stwierdza, że procesor się nudzi i próbuje znaleźć mu coś do roboty. Najpierw sprawdza inne kolejki zadañ do wykonania wewnątrz tego samego zbioru procesorów. Jeśli nic nie znajduje, próbuje przejąć zadanie z najbardziej obciążonego zbioru.
  • w określonych przedziałach czasu, gdy procesor jest zajęty. To też jest uruchamiane przez kod przerwañ zegara. Wówczas, najzwyczajniej w świecie próbuje przenieść zadania z najbardziej obciążonego zbioru procesorów do najmniej obciążonego zbioru.

  W większości przypadków, balansowanie obciążeniem zbiorów procesorów jest wykonywane w tych samych momentach co rozkładanie obciążenia pomiędzy procesorami w schedulerze K3. Jedynym wyjątkiem jest przemieszczanie zadañ w momencie rozpoczęcia ich wykonania. Te różne formy równoważenia obciążenia pomiędzy zbiorami procesorów są w łacie objęte #define'ami, dzięki czemu łatwo je włączać i wyłączać do eksperymentowania.

Rzeczy, których brakuje w łacie:

• Wykrywanie topologii. Do stworzenia zbioru procesorów, gdy już wiemy, ile jest procesorów w systemie, wywoływana jest procedura numa_sched_init(). Wewnątrz tej funkcji zakodowane są na sztywno wartości wykorzystywane do określenia liczby procesorów na zbiór i ,,odległości'' pomiędzy zbiorami. Oczywiście tworzenie zbiorów procesorów będzie oparte o informację o topologii, która jeszcze nie jest dostępna w tej chwili. Dodatkowo, powinna być dostępna obsługa (albo przynajmniej rozumienie) niesymetrycznych i wielopoziomowych topologii.
• Zadania powinny mieć przypisany ,,domowy'' zestaw procesorów. Krótkotrwałe wykonywanie zadania na zdalnym procesorze powinno mieć miejsce jedynie, aby wykorzystać nudzące się procesory. Zadania powinny się wykonywać na zdalnych procesorach jedynie przez krótki odcinek czasu. Większość czasu wykonywania zadania powinna mieć miejsce na domowym zbiorze procesorów. Długie wykonywanie zadania na zdalnym zbiorze procesorów pociągnie za sobą konieczność przeniesienia pełnego zadania, co obejmuje także przenoszenie/kopiowanie pamięci z nim związanej.
• Dzielenie szeregowanych danych. W architekturze NUMA, struktury danych powinny być kopiowane do lokalnej pamięci procesorów, które będą często ich używać. Dlatego rzeczy takie, jak kolejki zadañ do wykonania i zbiory procesorów nie powinny być tablicami.
• Lepsze określanie, które zadania kwalifikują się do wykonywania zdalnie/migrowania. W tej chwili wykorzystywany jest istniejący kod w load_balance(). Najprawdopodobniej to będzie wystarczające.

co najmniej dwa zespoły w Niemczech pracują nad tym

odnośniki:

http://os.inf.tu-dresden.de/index.xml.de

http://i30www.ira.uka.de

Gałąź stabilnych jąder L4/Fiasco jest utrzymywana przez TU w Dreźnie i jest dostępna pod adresem:

http://os.inf.tu-dresden.de/L4/LinuxOnL4/.

Mimo że pan Torvalds nie wydaje się być zachwycony pomysłem mikrojądra, ta praca nie jest wykonywana w bólach dzięki stałemu technicznemu nadzorowi w pewnych aplikacjach, dotyczących głównie systemów rozproszonych, włączając w to architekturę NUMA.