Kernel Traffic #169 For 2002/06/03

There were 352 different contributors. 178 posted more than once. 159 posted last week too.

13 maj 2002 - 23 maj 2002 (33 posts) Subject: "ŁATKA obsługa wielowątkowych zrzutów pamięci dla jądra 2.5.14 (i 15)."

Mark Gross podesłał łatkę, w której zaimplementowano obsługę zrzutu pamięci z wielu wątków dla jąder 2.5.14 i 2.5.15. Wyjaśnił: "Testowaliśmy nasze dzieło na jądrze 2.5.14 używając kilku aplikacji z pthread zrzucających pamięć na skutek wysłania sygnału SIGQUIT i SIGSEV. Jednostkowy test był wykonany zarówno na dwu- jak i na czteroprocesorowych systemach. Potem wykonano kilka testów obciążeniowych, w których pliki ze zrzutem były wykonywane podczas gdy scheduler był obciążany testami porównawczymi chata, które uruchamiane były w trakcie tworzenia zrzutów pamięci. Ta implementacja wydaje się być całkiem stabilna przy zajętym schedulerze, YMMV."

Erich Focht zapytał w jaki sposób łatka obsłuży przypadek, w którym zawieszone wątki są w trybie jądra, co jest możliwe w jądrach 2.5. Kilka listów dalej odpowiedział Vamsi Krishna S.: " jeśli zdarzy się tak, że wątek wykonuje się w przestrzeni jądra podczas gdy inny wątek zrzuca właśnie pamięć (zbiera stan rejestru innych wątków gwoli ścisłości), to pobierzemy rejestr _trybu użytkownika_ tego wątku ze spodu jego stosu jądra. GDB pokaże wszystkie akcje aż do momentu, w którym wątek wejdzie w przestrzeń jądra, (int 0x80), eip będzie wskazywał na instrukcję, która będzie wykonywana po wołaniu systemowym (na adres powrotu)." Pavel Machek sądził, że znalazł w tym pewien problem. Opisał swój exploit: "Wątek 1 jest w jądrze i blokuje A. Potrzebujesz zablokować A, by zrzucić aktualny stan. Jeśli przesuniesz 1 do innej kolejki, to stracisz możliwość uzyskania A, a to spowoduje zakleszczenie." Ale Mark odpowiedział:

Każda oczekująca obsługa przerwania programowego, zadania z dolnej połowy i górnej połowy, dostają procesy bezpośrednio przez rzeczywisty procesor, nawet jeśli procesy ograniczane przez WE/WY mogły zostać przesunięte do innej kolejki. To jest tak, że tylko dla zawieszonych procesów czekających w kolejce przetwarzanie zatrzymuje się przy wołaniu try_to_wake_up aż do chwili, w której proces zostanie z powrotem przesunięty do kolejki wykonywanych.

Widzę jeden przypadek, w którym zdarzy się to, o czym mówisz i pojawi się to, gdy kod jądra (albo sterownik) podejmie blokadę, a potem będzie ją trzymał podczas wołania jednej z funkcji sleep_on, czekając na WE/WY.

Każdy sterownik, który trzyma blokadę podczas wołania sleep_on, nadużywa blokad i wymaga poprawienia.

Nikt nie powtrzyma twórcy sterownika przed nadużyciami blokad.

Jeśli znasz przypadek, o który trzeba się martwić, albo jeśli jest jakiś inny sposób, by znaleźć się w tarapatach przy przyjęciu naszego pomysłu to proszę, daj mi znać.

Zarówno Pavel jak i Andi Kleen mieli wątpliwości co do stwierdzenia Marka, że żaden sterownik nie powinien utrzymywać blokady w trakcie wołania sleep_on(). Jak to powiedział Andi: "To jest prawda dla blokad z aktywnym oczekiwaniem (spinlock), ale nie dla semaforów. Warstwa zarządzania pamięcią oraz warstwa vfs używają semaforów i przysypiają wisząc na na nich, używają tego także niektóre inne podsystemy (na przykład sieć)." On, Mark i kilku innych gostków podyskutowali jeszcze na ten temat przez parę wiadomości. Na początku Mark był ciągle nieprzekonany, że problem istnieje, ale po chwili zaczął dostrzegać pewne obszary, które wymagałaby poprawienia. Podesłał nową łatkę i napisał:

Po przeprowadzeniu dochodzenia doszedłem do wniosku, że down_write(current->mm->mmap_sem) w elf_core_dump służy ochronie wykładających się aplikacji wielowątkowych przed zrzucaniem zepsutych i prawdopodobnie nielegalnych danych mm, pojawiających się na skutek akcji innych, ciągle działających procesów wątku.

Ponieważ w mojej łacie mamy te procesy zawieszone na kolejce, nie potrzebujemy zajmować dłużej semafora w elf_core_dump.

A jednak; zauważyliśmy inny potencjalny problem dla maszyn 4+ procesorowych z trzema lub więcej procesami z tej samej grupy wątków wchodzącymi do zawieszonych wątków w mniej więcej tym samym momencie. W tcore_suspend_threads, pomiędzy zwolnieniem blokad i wołaniem set_cpus_allowed, jeden z pozostałych wykładających się wątków może przesunąć takie zadanie, znajdujące się w set_cpus_allowed, do kolejki, zanim uda się mu powrócić. (to jest złe)

Wprowadziłem poprawkę dotyczącą tej możliwości przez wykonanie down_write/up_write na current->mm->mmap_sem w zasięgu tcore_suspend_threads. Takie rozwiązanie daje dodatkową korzyść, bo zatrzymuje operacje pamięci wirtualnej dla tej grupy wątków, zanim nie zostanie zawieszony proces całej grupy.

Uaktualniona łatka tcore została przetestowana na 2- i 4-procesorowych systemach z i386, zrzucano pamięć aplikacji używjących pthread z 300+ procesami wątków, w trakcie działania testów porównawczych. ,,Wydaje się'' być stabilne.

To wyraźnie naprawia problemy, które ludzie mieli z łatką; odbyła się też szybka dyskusja na temat integracji i różne rozmowy na temat możliwych problemów, które mogą się pojawić.

W pewnym momencie Mark wspomniał, że ma nadzieję, że wkrótce łata zadziała także dla jąder 2.4.

17 maj 2002 - 29 maj 2002 (8 posts) Subject: "[ŁATA] wykorzystanie starzenia się stron, do zmniejszenia pamięci podręcznej."

Ed Tomlinson zaprezentował łatkę i oświadczył: "Nigdy nie podobał mi się sposób, w jaki rozwiązano kurczenie pamięci podręcznej w taflach (ang. slab). To jest próba zrobienia tego lepiej." Benjamin LaHaise poklepał Eda po plecach i powiedział: "Dzięki! To powinno znacznie pomóc przy równoważeniu VM dzięki możliwości dynamicznego podkręcania parametrów tafli zamiast użycia magicznych wartości w kodzie. Czy myślałeś o przeniesieniu tej łatki do 2.5? Przydałoby się to przetestować w 2.5 przed włączeniem do 2.4" Kilka dni później Ed odpowiedział wysyłając zaktualizowaną wersję łatki.

20 maj 2002 - 24 maj 2002 (28 posts) Subject: "Łaty dla systemu limitów dyskowych"

W trakcie dyskusji prowadzonej nad kilkoma nowymi łatami dla quoty, Linus Torvalds zaproponował usunięcie pewnej części kodu, która odpowiada za wsteczną zgodność ze starszymi wersjami jądra. Zapytał: "Czy istnieje _jakikolwiek_ powód, aby używać przestarzałych rzeczy, jeżeli rozwiązaniem jest tylko uaktualnienie wersji narzędzi?" A Alan Cox dodał: "Większość ludzi już używa 2.4 z narzędziami quoty i 32bitowym uid, więc nie jest to wielki przełom. Quota z oficjalnego jądra jest zupełnie nieprzydatna w świecie rzeczywistym, więc ten problem jest rozwiązywany w drzewach dystrybutorów Linuksa."

Jan Kara poinformował, iż wysłał łatkę do Linusa usuwającą zbędny kod, a Marcin Dalecki zasugerował: "Jeśli możemy zrobić to dla quoty, może dałoby się usunąć też IPC_OLD. Ten kod jest teraz baaaardzo przeterminowany, ponieważ IPC_OLD i tak nie było zgodne ze standardem." Ale Alan odpowiedział:

Dodatkowy kod praktycznie nic nie zajmuje, zapewniając działanie starych systemów, a i stare Xfree86 nadal działa z nowymi jądrami. Po co usuwać?

Jeżeli chcesz budować matematyczną doskonałość i mały ultra czysty SO, to rób to. Niemniej jednak Linux musi działać w rzeczywistym świecie, a nie w szczęśliwym i niczego nieświadomym świecie, pełnym czystej matematycznej elegancji.

Marcin odpowiedział: "Złudnym jest myślenie, że nadal możesz uruchomić *tak stare* binaria a.out na nowoczesnych jądrach." Ale Christoph Hellwig włączając się, dodał: "Jasne, że możesz. Nawet ostatnie wydanie OpenLinux (z 2.4.13-ac), dla zaoszczędzenia miejsca używa instalatora bazującego na libc4/a.out. Nie zapominając o starych binariach Quake1 z jakiegoś CD RedHat 4.x, które uruchamiam od czasu do czasu :)" Marcin był pod wrażeniem tego, iż to, co usłyszał rzeczywiście działa, Alan doradził mu, aby sprawdził swoje racje zanim coś powie. Alan dodał: "To sięga poza Libc4. W tej chwili mamy prawie 100% wsteczną zgodność z libc 2.2.2. Wcześniejszy libc nie działa, bo porzuciliśmy pewne bardzo dawne i brzydkie wersje niektórych funkcji systemowych."

W tym miejscu Christoph zwrócił uwagę: "Dla 2.5 mam plany co do przestarzałych funkcji systemowych w zależności od CONFIG_COMPAT_*, to umożliwi kompilację dużego i spasionego jądra zachowującego kompatybilność oraz małych jąder bez niej. (np. dla urządzeń wbudowanych). Tak naprawdę, to mamy strasznie dużo śmieci, które mogą zostać usunięte dla konfiguracji, gdzie są nowe narzędzia w przestrzeni użytkownika." Marcinowi i Alanowi spodobał się ten pomysł, a Alan dodał: "W przypadku urządzeń wbudowanych będziesz chciał też zrobić opcję konfiguracyjną usuwającą warstwę urządzeń blokowych i temu podobne. Myślałem nad kilkoma opcjami wewnątrz menu konfiguracyjnego jak np. ,,Doskonała konfiguracja dla małych/wbudowanych urządzeń'' CONFIG_SMALL."

Linus Torvalds ogłosił 2.5.17 i było całe mnóstwo dyskusji na ten temat. W jednym z podwątków Marcin Dalecki wysłał łatę, która całkowicie usuwała interfejs /dev/port. Agitował:

Jest bezużyteczny przy portach wymagających dostępu 4-bajtowego.
Można to samo osiągnąć używając capabilities, suidów i takich tam.
w __m68000__ nie jest nawet zaimplementowany, a w większości architektur poza i386 jest ,,zaimplementowany'' w sposób zupełnie nie dbający o kwestie endianowości.
Nie jest standardem.
seek() + dostęp do port jest niebezpieczny pod względem wielokrotnego i współbieżnego użytku.
Nic go nie wykorzystuje.

... i tak dalej, i tak dalej ...

I w końcu, rozmiar jądra z nim:

   text    data     bss     dec     hex filename
1480587  243280  259628 1983495  1e4407 vmlinux

rozmiar jądra bez niego:

[root@kozaczek linux]# size vmlinux
   text    data     bss     dec     hex filename
1480229  243184  259628 1983041  1e4241 vmlinux

Co oznacza oszczędzenie 454 bajtów :-).

Paul Mackerras i David S. Miller uważali, że to jest świetny pomysł, ale było trochę speklulacji, czy Marcin zostanie zbluzgany z góry na dół za taką sugestię. Kilka godzin później, kilka osób wyraziło zdziwienie z powodu braku oczekiwanej wojny na bluzgi. Ale w pewnym momencie Alan Cox wytknął: "Interfejs /dev/port jest używany przez kilka aplikacji i w szczególności jest od zawsze w uniksach na x86. Na platformach takich jak ARM jest nędznie zaimplementowane, bo było by tam jedynie częścią /dev/mem i akceleratorem dla mmap przy emulacji wejścia/wyjścia w przestrzeni użytkownika." Marcin zrobił wielkie oczy, gdy to przeczytał; sądził, że /dev/port był całowicie wymyślony na potrzeby Linuksa. Ale Alan kontynuował: "Interfejs /dev/port jest obecny w wielu starych unicesach na x86, a także w takich systemach, jak Minix." A gdzie indziej zdecydowanie zaprotestował przeciwko temu pomysłowi. W tym momencie temperatura dyskucji zaczęła szybko rosnąć, dopóki Paul Rusty Russel nie zasugerował, aby przedyskutować całę kwestię na zbliżającym się Kernel Summit. To w zasadzie zamknęło podwątek.

Jednakowoż w innym miejscu Linus Torvalds wtrącił się do dyskusji mówiąc, że nie ma nic przeciwko pozbyciu się /dev/port. Wyjaśnił: "Zrobiliśmy tak tylko dlatego, że było tak w Miniksie, ale nie było to nawet zgodne z Miniksem (sądzę, że Minix wspierał 2- i 4-bajtowy dostęp przez wywoływanie 2- i 4-bajtowych read/write, czego kod Linuksa nigdy nie robił)." Dodał: "Do wszystkich: jeśli kiedykolwiek używaliście /dev/ports, odezwijcie się _teraz_." Alan odrzekł:

Odzywam się. Wysłałem już listę przykładów na linux-kernel. iopl i ioperm nie są tak przenośne, jak /dev/port. ioperm/iopl są też nieprzydatne dla różnych języków skryptowych, narzędzi javowych, które starają się nie używać JNI itd.

Widziałem użycie /dev/port w różnych narzędziach napisanych w javie, pythonie, perlu, czy nawet tcl.

Inne przykłady to libieee1284, programator pic 16x84, hwclock, stare kbdrate, /sbin/clock na komputerach bez /dev/rtc.

Nie wszystko na świecie to x86, nie każda aplikacja chce być tylko dla Linux/x86, czy używać dziwacznych funkcji systemowych.

Często używam tego jako alternatywy do #include <asm/io.h>, które uznałeś za nielegalne. Rozumiem, że <sys/io.h> jest już pełnoprawną alternatywą, ale na wielu platformach nie ma <sys/io.h>, na przykład Jes strasznie płakał, gdy poprosiłem go o dodanie tego do ia-64. Ale jeśli zdecydujesz się wyrzucić /dev/port, mogę bez tego żyć. Solaris może, to i my możemy.

Widziałem lamentowanie, że outl nie jest zaimplementowane dla write(fd, &my_int, 4) i sądzę, że ten koleś miał trochę racji. Ale jeśli tego chciał, powinien podesłać łatkę.

Marcin odpowiedział: "na przykład, jeśli ktoś chce użyć /dev/port na jakimś wolnym i eksperymentalnym sprzęcie. Dlaczego po prostu nie" [...] "skopiluje tego jako *oddzielnego* modułu z urządzeniem znakowym? To jest linux - masz źródła, więc ich użyj. Jeśli chcesz oszukiwać względem abstrakcji systemów operacyjnych - zrób to sam! Nie ma wymagania, które mówiłoby, że to ma być w głównym jądrze na zawsze, gdzie przyciąga wzok ludzi, którzy używają tego w miejcach, gdzie nie powinni tego robić, takich jak ustawianie opóźnień klawiatury, czy manipulacja ustawieniami zegara." Ale Linus odparł:

Marcin, to nie jest produktywne podejście.

Tak, przy otwartym oprogramowaniu możesz zrobić, co chcesz.

JEDNAKŻE, jest duża liczba zalet posiadania tego w oficjalnym jądrze; na tyle duża, aby się nią przejmować: jak myślisz, dlaczego MS odniósł sukces komercyjny?

To jest istotne, aby _nie_ zmuszać ludzi do robienia jakichś wykręconych sztuczek dla poszczególnych architektur (czy problemów), nawet jeśli są w stanie. Ponieważ takie sztuczki znacznie zmiejszają ogólną używalność kodu.

Upraszczając, mówienie ,,możemy żyć bez tego'' jest bezwartościowe samo w sobie. Musisz jeszcze dodać ,,i nikt w sposób sensowny tego nie oczekuje''.

Ale to raczej nie jest przypadek /dev/ports. Więc zostaje.

21 maj 2002 - 23 maj 2002 (11 posts) Subject: "Jądro 2.2 kernel - łaty Ext3 & Raid"

Jon Hedlund zdawał się pamiętać ostrzeżenia, aby nie używać ext3 razem z RAID w jądrach 2.2; ale używał juz kombinacji ext3 i RAID 1 bez żadnych problemów już przez ponad dziewięć miesięcy. Spytał, czy to normalne, czy może miał wyjątkowe szczęście? Andread Dilger odrzekł: "Miałeś wyjątkowe szczęście. Nie pamiętam dokładnego scenariusza, ale chodziło o coś w rodzaju odtwarzania pliku dziennika podczas odtwarzania RAID po padzie systemu. Wtedy będziesz miał na dysku zapisane śmieci." Stephen C. Tweedie dodał:

Dokładnie --- kod synchronizacji raid w 2.2 używa zwykłych buforów pamięci podręcznej, co objawia się w zaszeregowaniu do zapisu czystych buforów. To wszystko odbywa się za plecami ext3 i nie jest dozwolone --- zaburza wymagną przez ext3 kolejność zapisu i uwalnia kod wykazujący błąd w kodzie ext3 sprawdzającym poprawność zapisu.

Możesz tego uniknąć, ale synchronizacja raid w ext3 w 2.2 po prostu nie jest bezpieczna. Jeśli poczekasz z montowaniem ext3, aż synchronizacja się wykona, nic złego się nie stanie.

Powinno działać w 2.4.

Gdzie indziej Mike Fedyk przyznał się do tego ostrzeżenia przez używaniem obu łat razem i zasugerował:

Na Twoim miejscu przetestowałbym daną konfigurację na jądrze 2.4. O ile w grę nie wchodzi jakiś binarny sterownik, który nie ma wersji dla 2.4, raczej nie ma co pozostawać przy 2.2.

Ta konfiguracja jest niebezpieczna dla 2.2, a ja używałem raid1 i raid5 z ext3 bez żadnych problemów, nawet na zdegradowanych tablicach (oczywiście tak krótko, jak to możliwe).

Ale Stephen wtrącił: "Właściwie, to musisz zmienić jeden ze sprzecznych #definów na coś nieużywanego i to zadziała. Gdy to zrobisz, programowy raid0 i tryb liniowy będą bardzo fajnie działać z ext3 na 2.2, jedynie synchronizacja po padzie przy raid1 i radi5 jest niebezpieczna." Później zmienił zdanie mówiąc, że ta poprawka działa tylko dla RAID 0.

Również Tomas Szepe odpowiedział Mike'owi, zgłaszając zastrzeżenia do rekomendacji użycia jądra 2.4, które nie bardzo nadaje się na procesory Sparc 32, z powodu błędów, które niedawno ujrzały światło dzienne. Ale David S.Miller odparł: "Było kilka łat, które rozwiązywały ten problem, możesz zaaplikować je własnoręcznie lub pobrać z bieżącego drzewa BK 2.4.x Marcelo." Po krótkiej pracy, Tomas zaoferował:

A to dla wszystkich osób, które nie mogą zainstalować BK:

Wszystkie zmiany związane z sparc32/sparc64 od 2.4.19-pre8 w jednym diffie i poprawione ręcznie są pod adresem http://linux.bkbits.net:8080/linux-2.4/ChangeSet@-3w?nav=index.html

Wszystko co mogę powiedzieć o funkcjonalności załatanego jądra -- skompilowało się na moim sparc32. Zamierzam je przetestować w następnym tygodniu, gdy będę wymieniał dyski w serwerze.

22 maj 2002 - 26 maj 2002 (4 posts) Subject: "[RFC/PATCH] lvm sanitation in 2.5"

Anders Gustafsson ogłosił, "Rozpocząłem czyszczenie lvm. Załączona łata obejmuje pierwsze kroki. Usuwa większość funkcjonalności, ale podstawowe rzeczy cały czas są i w tej chwili używam takiego jądra z /home i /var na lvm. Struktury vg_t/lv_t.. są teraz dostępne w dwóch wersjach, jedna jest eksportowana do przestrzeni użytkownika (i powinna zostać niezmienna w miarę upływu czasu) i jedna dla przestrzeni jądra, z rzeczami, które powinny być ukryte przed przestrzenią użytkownika (struct block_device, dev_t itp.). (to pozwala także na większą elastyczność przy zmianach w sterowniku bez zmian w interfejsie przestrzeni użytkownika." Alexsander Viro, widząc to, był bardzo zadowolony i dał kilka wskazówek do dalszej pracy. A Joe Thornber powiedział Andersowi:

Ostatniego lata rozpocząłem podobny proces, jeśli chcesz obejrzeć moją pracę, znajdziesz ją w cvs oznaczoną jako 'experimental' (cvs co -d :pserver:cvs@tech.sistina.com:/data/cvs -r experimental LVM). Jest tam *wiele* zmian, w szczególności wydzieliłem interfejs ioctl do osobnego pliku i w dużej części go przepisałem. Sądzę, że znacznie wyczyściłem też funkcje mapujące.

Wkrótce jednak uwidoczni się to, że końcowy wynik ciągle będzie zbyt ubogi ze wzlędu na szokujący interfejs ioctl. Stąd projekt LVM2, nad którym pracuje cały zespół przez ostatnie 9 miesięcy. Być może zatem pytanie powinno brzmieć: ,,czy to już czas, by przejść z LVM1 na LVM2 w jądrach 2.5?''.

To tak tylko, byś był świadomy, że niezależnie od tego jak bardzo uprzątniesz LVM1, ludziom nie będzie się to podobało - musisz wygrać zarówno z niedoskonałym projektem jak i z kiepskim kodem.

Cześć, pracujemy nad aktualizacją bkbits.net i gdy tylko będziemy gotowi przełożymy dyski z jednego komputera do drugiego. Chcemy to zrobić jeszcze dziś, więc lepiej uaktualnijcie swoje drzewa teraz. Linus nic nie robił od wczoraj, więc to jest przypuszczalnie najlepsza pora.

Efektem ubocznym jest to, że dostaniemy dodatkową maszynę jako awaryjną, więc następnym razem będziemy mogli robić takie rzeczy za Waszymi plecami i nawet tego nie zauważycie.

Poprosiłem, aby nikt nie dotykał rzeczy związanych z I2O w 2.5. ponieważ planuję przeprowadzić tam poważną operację, a potrzebowałem popracować jeszcze nad 2.4 zanim zanurzyłem się w 2.5.

Stan 2.4.19pre8-ac5 jest następujący:

Warstwa i2o_pci została radykalnie oczyszczona i powinna być już skończona zarówno dla 32, jak i 64 bitów.
Warstwa i2o_block została w połowie przepisana tak, aby radzić sobie z błędami w firmware, a warstwy WE/WY radzą sobie z blokami 64K i większymi.
i2o_core powinno być w miarę czyste.
Warstwa i2o_scsi jeszcze nie jest oczyszczona względem 64 bitów i cały czas używa starego kodu eh. Wymaga tyle samo pracy, co inne sterowniki scsi plus dodatkowo kilka wskaźników do 32-bitowych pól wiadomości wymaga poprawienia.

Na 32-bitowym x86 kod jest znów stabilny i działa i na moim DPT, i na AMI Megaraid, i na kartach, które obsługiwał wcześniej. Strategia cache'owania bloków jest teraz konfigurowalna.

Do zrobienie pozostaje jeszcze mapowanie pci oraz znalezienie wszystkich pozostałych baboli dla 64-bitowych architektur, ale, jeśli ktoś z i2o czuje potrzebę, to podstawowy kod jest teraz już w stanie, w którym można go przenieść do 2.5.

Oczyszczenie SCSI dla 64 bitów i zrobienie mapowania PCI to kwestia czasu. Nie są to jednak dla mnie teraz priorytetowe zadania (przynajmniej do momentu, gdy AMD Hammer trafi na masowy rynek).

27 maj 2002 - 29 maj 2002 (21 posts) Subject: "Jeszcze raz o błędzie SRMMU w 2.4"

W trakcie dyskusji Tomas Szepe nie był w stanie znaleźć dowodu na to, że łata została faktycznie zaaplikowana. Nie mógł znaleźć go przy użyciu webowego interfejsu do drzewa BitKeepera. David S. Miller odpowiedział:

Repozytorium BK, którego możesz użyć, dostępne jest pod URL-em:

bk://linux.bkbits.net/linux-2.4

Rzeczy webowe są cały czas uaktualniane ręcznie i dlatego są non-stop nieaktualne.

Ale w pewnym momencie David Woodhouse podał odnośnik do własnego interfejsu webowego do BitKeepera i powiedział: "Te strony są uaktualniane przez crona i dlatego, o ile nic się nie zepsuje, nigdy nie są bardziej nieaktualne niż o godzinę (w stosunku do bk//linux.bkbits.net/linux-2.4)."


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

Kernel Traffic #169 For 2002/06/03

By Zack Brown

Translated By: Krzysztof Wilczyński , Maja Królikowska and Paweł Kot

1.	13 maj 2002 - 23 maj 2002	(33 posts)	Obsługa wielowątkowych zrzutów pamięci dla 2.5 i 2.4
2.	17 maj 2002 - 29 maj 2002	(8 posts)	Zwiększanie zrównoważenia pamięci wirtualnej
3.	20 maj 2002 - 24 maj 2002	(28 posts)	Wsteczna zgodność
4.	20 maj 2002 - 27 maj 2002	(153 posts)	Status /dev/port
5.	21 maj 2002 - 23 maj 2002	(11 posts)	Stan ext3 i RAID w 2.2
6.	22 maj 2002 - 26 maj 2002	(4 posts)	Czyszczenie LVM
7.	24 maj 2002	(1 post)	Repozytorium BitKeepera leży (i kwiczy)
8.	24 maj 2002	(1 post)	Stan I2O w 2.5 i 2.4
9.	27 maj 2002 - 29 maj 2002	(21 posts)	Dyskusja o BitKeeperze