|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
GNUe Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
linux-kernel FAQ | zapisz się na linux-kernel | archiwa linux-kernel | kernelnotes.org | Nawigator po źródłach Linuksa LxR | Wszystkie jądra | Porty jądra Linuksa | Dokumentacja do jądra | Encyklopedia Garego: jądro Linuksa | #kernelnewbies
Table Of Contents
| 1. | 30 Jun 2001 - 5 Jul 2001 | (8 posts) | Obsługa 64-Bitowego bloku |
| 2. | 4 Jul 2001 | (1 post) | Stan CML2 |
| 3. | 4 Jul 2001 - 6 Jul 2001 | (5 posts) | Łączenie zmian w serii -ac z jądrami Linusa |
| 4. | 4 Jul 2001 - 5 Jul 2001 | (4 posts) | Problemy z archiwum listy |
| 5. | 6 Jul 2001 - 7 Jul 2001 | (4 posts) | Stan ext3 |
| 6. | 9 Jul 2001 - 10 Jul 2001 | (28 posts) | Limity pamięci dla procesów |
| 7. | 10 Jul 2001 - 11 Jul 2001 | (4 posts) | Reaktywacja przeniesienia Linuksa na sparc32 |
| 8. | 10 Jul 2001 - 11 Jul 2001 | (4 posts) | Nieudana kompilacja ESS137x |
Introduction
Chciałbym powitać Johna Guthrie w naszym gronie. Jego pierwszy kawałek może jest niewielki, ale jest to wątek, który nieumyślnie przegapiłem i tylko dzięki spostrzegawczości Johna znalazł się on w KT w tym tygodniu. W tym tygodniu powrócił także Adam wykonując kawałek bardzo dobrej roboty.
Mailing List Stats For This Week
We looked at 908 posts in 3534K.
There were 370 different contributors. 156 posted more than once. 130 posted last week too.
The top posters of the week were:
1. Obsługa 64-Bitowego bloku
30 Jun 2001 - 5 Jul 2001 (8 posts) Archive Link: "[RFC][PATCH] Przymiarka do obsługi 64 bitowego bloku"
Summary By Zack Brown
People: Ben LaHaise
Ben LaHaise poinformował o łacie i oznajmił: " Poniżej pierwsza przymiarka do uczynienia limitu wielkości bloku konfigurowalnym do 64 bitów na maszynach x86, oraz zawsze 64 bitowym na maszynach 64 bitowych. Sprawdzanie nie zostało jeszcze zakończone, ale dużą jego część mamy już z głowy." [..] "Następujące powinny już obsługiwać 64 bity: nbd, loop, raid0, raid1, raid5." Podał odnośniki do dwóch witryn http://people.redhat.com/bcrl/lb/ oraz http://www.kvack.org/~blah/lb/. Dodał: "Koszmarne fragmenty: musiałem dodać libgcc.a aby spełnić wymagania 64 bitowego dzielenia. Tak, to do bani, ale RAID potrzebuje jeszcze trochę informacji zanim będę mógł całkowicie usunąć 64 bitowe dzielenie. Zostanie to naprawione." Chris Wedgwood zaproponował kilka zmian do libgcc.a aby je troszkę upiększyć, a Ben odparł: "Chcę się całkowicie pozbyć zależności od libgcc. To właśnie oznacza ,,Zostanie to naprawione''. Jeżeli chcesz przyśpieszyć proces, wyślij łatę. Do tego czasu, jest to Wystarczająco Dobre do celów testowych."
W innym miejscu, Ragnar Kjarstad bardzo się ucieszył z pracy Bena, pytając czy LVM także obsługuje już 64 bity. Ben odpowiedział zagadkowo: "Hmmm, wstrzymam się od komentarzy na temat LVM." Ragnar oczekiwał wyjaśnień, więc Ben wytłumaczył:
Naprawianie LVM nie znajduje się na liście moich priorytetów. Ten kod aż prosi się o przepisanie, a także łamie kilka podstawowych zasad planowania jakie powinien spełniać dobry kawałek kodu w warstwie blokowej. Powinien on mianowicie: 1) przewidywać współpracę z 64 bitowymi wyrównaniami, 2) nigdy nie używać mnożenia, dzielenia ani modułu na numerach bloku, oraz 3) nie alokować struktur pamięci, które są indeksowane przez numery bloków. LVM zawalił we wszystkich trzech punktach -- a jest to tylko to co udało mi się zauważyć po szybkim, 5 minutowym przejrzeniu kodu. Wybacz, ale LVM jest z założenia bezużyteczne. Będzie nadal działało na 32 bitowych urządzeniach blokowych, ale jeżeli spróbujesz pójść dalej, to się sypnie. Zważywszy na to, musimy się upewnić, że pady te będą pełne gracji a wydarzą się zanim użytkownik będzie miał okazję stracić jakiekolwiek dane.
Ale na szczęście istnieją alternatywy takie jak ELVM, które starają się naprawiać błedy na podstawie doświadczeń wyniesionych z poprzednich lekcji. Zważywszy na to, myślę że w cyklu 2.5 będziemy w niezłej formie.
Koniec Wątku (tm).
2. Stan CML2
4 Jul 2001 (1 post) Archive Link: "Stan CML2"
Summary By John Guthrie
People: Eric S. Raymond
Eric S. Raymond ogłosił:
Główna część CML2 jest w dobrym stanie. Od połowy kwietnia nie wystąpiły już żadne poważniejsze błędy. Ostatnia wersja (1.6.9) jest przystosowana do 2.4.6 i ac24 i dodaje lepszą kontrolę typów w wyrażeniach w czasie kompilacji (dziękuję Danielowi Junglasowi za pomoc przy tym).
Jest parę drobiazgów, które zostały do poprawienia w interfejsie xconfiga, ale nie wydają się one pojawiać w trakcie normalnych operacji ze zbiorem reguł kompilacji jądra Linuksa. Są one w pełni opisane w pliku TODO.
Nie było ostatnio żadnych uwag od beta-testerów na temat szybkości; majowe podstrajanie przyniosło efekt. Prośby, które dostaję dotyczą głównie drobnych zmian w interfejsie użytkownika.
CML2 wygrywa kolejny raz. Goście z Webmachines używają go do konfigurowania dystrybucji Linuksa, którą upychają we flash ROMach swoich urządzeń sieciowych. Lekko poprawiona wersja plików z regułami kompilacji z Webmachines jest dostępna jako przykład na stronach projektu CML2.
Na murach lochów w przygodowej wersji CML2 można od czasu do czasu napotkać zabawne grafitti. Znajdźcie wszystkie wkomponowane dowcipy i wygrajcie wartościową nie-nagrodę.
CML2 jest gotowy.
3. Łączenie zmian w serii -ac z jądrami Linusa
4 Jul 2001 - 6 Jul 2001 (5 posts) Archive Link: "Jądra Linusa a jądra AC"
Summary By Zack Brown
People: Alan Cox
John Weber spytał jak sprawdzić które części jąder -ac zostały włączone do jąder Linusa Torvaldsa. Tim Waugh zaproponował użycie diff. W pewnym momencie Alan Cox zauważył, "Łączenie serii jąder -ac i Linusa nie odbywa się zgodnie z numeracją wersji serii -ac. To czyni zmiany trudniejszymi do określenia."
4. Problemy z archiwum listy
4 Jul 2001 - 5 Jul 2001 (4 posts) Archive Link: "Archiwa listy nie działają"
Summary By Zack Brown
People: David Balazic, Erik Mouw
David Balazic zauważył:
Zauważyłem, że 4 z 5 wymienionych w FAQ archiwów LKML ostatnio nie działa.
Są one wymienione w FAQ LKML pod adresem http://www.tux.org/lkml/ :
Teorie spiskowe ?
Erik Mouw dodał odnośnik do http://www.geocrawler.com/lists/3/Linux/35/0/, pisząc, "Tutaj znajduje się jeszcze jedna, która jest uaktualniana w czasie rzeczywistym, ale nie ma wątkowania. " Havard Kvalen podał odnośnik do archiwum, które wydawało się działać. Samuli Kaski zwrócił uwagę na proste archiwum.
(ed. [Zack Brown] Najlepsze archiwum jakie udało mi się znaleźć to archiwum znajdujące się pod pierwszym odnośnikiem z listu Davida. Jeśli ktokolwiek znajdzie lepsze, proszę dać mi znać.)
5. Stan ext3
6 Jul 2001 - 7 Jul 2001 (4 posts) Archive Link: "ext3-2.4-0.9.0"
Summary By Zack Brown
People: Andrew Morton
Andrew Morton ogłosił:
Aktualizacja systemu plików z księgowaniem, ext3, dla jąder 2.4 jest dostępna pod adresem
http://www.uow.edu.au/~andrewm/linux/ext3/
Łaty są przygotowane dla 2.4.6-ac1 i 2.4.6.
Zmiany od 0.0.8 obejmują:
Ostatnia zmiana jest prawdopodobnie najbardziej znacząca - zapobiega możliwym padom systemu i rozpadowi systmu plików przy dużych obciążeniach.
6. Limity pamięci dla procesów
9 Jul 2001 - 10 Jul 2001 (28 posts) Archive Link: "Jaka jest prawda na temat ograniczeń RAMu w 2.4?"
Summary By Adam Buchbinder
People: Adam Shand, Andi Kleen, Brian Gerst
Adam Shand wyjaśnił, " Tu, gdzie właśnie zacząłem pracować, uruchamiamy duże procesy w celu symulacji. " [...] "Obecnie używamy Solarisa ze względu na ograniczenia ilości RAMu, którą może adresować pojedynczy proces w Linuksie. " Wysłał dwa pytania:
Kontynuował, przysyłając wyniki swoich obserwacji na ten temat, mówiąc, że informacje te nie pochodzą z pewnego źródła:
Dodał, że wszystkie informacje jakie otrzyma na ten temat zostaną umieszczone na jego stronie.
Andi Kleen odpowiedział, że stała __PAGE_OFFSET może być ustawiona tak by podnieść limit RAMu na pojedynczy proces i że arch/i386/vmlinux.lds musi zostać zmienione (nie powiedział jak). Dodał też swoje przemyślenia, "Twoje symulacje zatrzymują się na 2.3GB prawdopodobnie dlatego, że alokacja pamięci przy użyciu funkcji malloc rozbija się na dzielonych bibliotekach (sprawdź /proc/<pid>/maps). Można to ominąć mówiąc mallocowi aby używał mmap bardziej agresywnie (patrz: dokumentacja malloca w info libc) albo ,,przesunąć w górę'' dzielone biblioteki przez zmianę stałej TASK_UNMAPPED_BASE w jądrze."
Gdzie indziej, Rik van Riel powiedział, że limit 3GB na proces jest limitem sprzętowym. Brian Gerst wyjaśnił także, że rozszerzenia PAE pozwalają na użycie "64GB FIZYCZNEJ pamięci. Procesor może nadal używać tylko 4GB pamięci WIRTUALNEJ na proces, która musi być dzielona pomiędzy przestrzenią użytkownika, a przestrzenią jądra. Linux dzieli ją w proporcji 3:1. "
Pojawiło się kilka sugestii na temat rozszerzenia części przypadającej na tryb użytkownika, ale zgodzono się, że mogłoby to doprowadzić do niestabilności i nieakceptowalnego zachowania. W pewnym momencie Jesse Pollard poprosił o dokumentację dotyczącą możliwości adresowania przez procesory Intel, a Jonathan Lundell podał odnośnik do Intel's Pentium III reference manuals.
7. Reaktywacja przeniesienia Linuksa na sparc32
10 Jul 2001 - 11 Jul 2001 (4 posts) Archive Link: "Jądro 2.4.6 nie kompiluje się na Sparcu"
Summary By Adam Buchbinder
People: Fabrizio Gennari, Doug McNaught, Peter Zaitcev, Alex Buell
Fabrizio Gennari zgłosił problemy z kompilacją 2.4.6 na Sparcu. " Wydaje się, że w pgalloc.h pewne identyfikatory są zarezerwoane na makra, a gdzie incziej te same identyfikatory służą za nazwy funkcji." Dodał, że ten sam problem zgłaszał na liście Alex Buell 9 maja.
Doug McNaught odpowiedział, "Jądra 2.4.X obecnie nie kompilują się i nie działają na Sparc32, ponieważ nie ma opiekuna dla tej plaftormy." Peter Zaitcev podesłał odnośnik do dość sporej łaty jego autorstwa, która " kompiluje się, ale nie działa zbyt dobrze. Może posłużyć za dobry początek, jeśli chesz naprawić sparc(32)."
Alex Buell odpowiedział, że zajmie się tą łatką jak tylko wróci z urlopu. Tymczasem zapytał, "czy ktoś w UK mógłby ofiarować SparcStation 20 z podwójnym SM61s (albo nawet lepiej, SM71s) z 24-bitowym framebufferem, żebym mógł się upewnić, że SMP działa na sun4m." Nie było odpowiedzi.
8. Nieudana kompilacja ESS137x
10 Jul 2001 - 11 Jul 2001 (4 posts) Archive Link: "nieudana kompilacja es1370/1371"
Summary By Adam Buchbinder
People: Martin A. Brooks
Martin A. Brooks zgłosił błąd kompilacji sterowników (dźwiękowych) zarówno es1370 jak i es1371 dla jądra 2.4.6-ac2:
es1371.o(.text+0x587c): multiple definition of `gameport_register_port'
es1370.o(.text+0x5670): first defined here
Alexander Griesser podesłał łatę zapobiegającą podwójnemu definiowaniu symboli, Martin zgłosił, że łata jest dobra i wątek się na tym zakończył.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0. |