Kernel Traffic #127 For 23 Jul 2001

By Zack Brown

Translated By:  Maja Królikowska

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

• Printer-Friendly Format
• Text Format
• XML Source
• Mailing List Stats For This Week
• Threads Covered

  1.	7 Jul 2001 - 17 Jul 2001	(13 posts)	Uogólnienie obsługi pliku wymiany w 2.5
  2.	16 Jul 2001	(8 posts)	Dodawanie pozycji HZ do /proc/sys/kernel
  3.	16 Jul 2001 - 17 Jul 2001	(4 posts)	e2fsck zawiesza się na 2.4.7
  4.	17 Jul 2001 - 18 Jul 2001	(12 posts)	Próby dokumentacji jądra
  5.	17 Jul 2001	(13 posts)	Informacja o cache dla procerów Duron

Mailing List Stats For This Week

We looked at 1498 posts in 6286K.

There were 538 different contributors. 237 posted more than once. 139 posted last week too.

The top posters of the week were:

• 50 posts in 124K by Alan Cox <alan@lxorguk.ukuu.org.uk>
• 36 posts in 139K by Jeff Garzik <jgarzik@mandrakesoft.com>
• 29 posts in 161K by Chris Wedgwood <cw@f00f.org>
• 28 posts in 79K by "David S. Miller" <davem@redhat.com>
• 26 posts in 108K by Andrea Arcangeli <andrea@suse.de>
• Full Stats

1. Uogólnienie obsługi pliku wymiany w 2.5

7 Jul 2001 - 17 Jul 2001 (13 posts) Subject: "RFC: Usunięcie obsługi pliku wymiany"

Summary By Zack Brown

People: Eric W. Biederman, Chris Wedgwood

Jeff Garzik zaproponował, że skoro każdy plik może być zmieniony w urządzenie blokowe przez loop, być może nie ma potrzeby explicite wspierać specjalnego przypadku plików wymiany. Zapropownował porzucić obsługę plików wymiany w 2.5 i zastąpić ją równoważną funkcjonalnością realizowaną przez loop.

Niektórzy goście sugerowali, że loop nie jest jeszcze dostatecznie stabilny by na niego liczyć w kwestii obsługi partycji wymiany. W innym miejscu Eric W. Biederman podjął dyskusję, czy kod związany z plikiem wymiany jest wciąż potrzebny. Powiedział:

Chris Wedgwood poprosił o potwierdzenie, że urządzania blokowe rzeczywiście będą przechodzić przez pamięć podręczną stron w 2.5, mówiąc, "Miałem nadzieję że tak, tak, by każde urządzenie blokowe było tylko obrazem odpowiedniego urządzenia znakowego w pamięci podręcznej stron, a to pozwoliłoby usunąć pamięć podręczną bufora i rzeczy związane z /dev/raw." . Eric odpowiedział (przyznając, że być może nie ma racji):

2. Dodawanie pozycji HZ do /proc/sys/kernel

16 Jul 2001 (8 posts) Archive Link: "ŁATA: /proc/sys/kernel/hz"

Summary By Adam Buchbinder

People: Rolf Fokkens, Ulrich Drepper, Andreas Jaeger

Rolf Fokkens przesłał krótką łatkę i napisał "Część oprogramowania (na przykład procps) wymaga stałej HZ w jądrze. Czasem jest ustalane po prostu przez zliczanie jiffies przez sekundę. Załączona łatka po prostu ,,publikuje'' stałą HZ w /proc/sys/kernel/hz." Ulrich Drepper zapytał:

Rolf powiedział, że to nie działa -- "pokazuje 100 choć zmieniłem to w jądrze na 1024. "

Andreas Jaeger powiedział "w twoim jądrze jest coś nie tak, sprawdź AT_CLKTCK" . Rolf stwierdził, że "dla niektórych architektur rzeczywiście _jest_ związek między CLOCKS_PER_SEC i HZ, ale dla niektórych go _nie_ ma. " [...] " Dla i386 ta relacja wyraźnie _jest_. Dla IA64 podejrzewam, że tej relacji _nie_ ma, jądro zakłada, że jest to _zawsze_ 100 HZ dla ia32. Dziwne." Na tym wątek zakoñczył się bez wyraźnej konkluzji.

3. e2fsck zawiesza się na 2.4.7

16 Jul 2001 - 17 Jul 2001 (4 posts) Archive Link: "2.4.7-pre6 nie potrafi zakoñczyć e2fsck"

Summary By Adam Buchbinder

People: Gianluca Anzolin, Andrea Arcangeli

Gianluca Anzolin zgłosił problem z 2.4.7-pre6aa1: "e2fsck /dev/hda3 nigdy się nie koñczy, nie mogę nawet zatrzymać procesu przy pomocy CTRL+C. Alt+SysRQ działa i podaje, że liczba nieaktywnych i zajętych stron się zwiększa, podczas, gdy liczba aktywnych i czystych stron się zmniejsza. " Andrea Arcangeli zaproponował, aby wycofał łatkę 40_blkdev-pagecache-5. Później Andrea wytłumaczył to dokładniej:

Andrea załączył dwulinijkową łatkę. Kurt Garloff zgłosił, że miał wcześniej taki sam problem, ale ta łatka go rozwiązała. Wątek zakoñczył się w tym miejscu.

4. Próby dokumentacji jądra

17 Jul 2001 - 18 Jul 2001 (12 posts) Subject: "Dokumentacja jądra"

Summary By Zack Brown

People: Charles Samuels

Charles Samuels przesłał URL do dokumentacji, którą opracował, aby dostarczyć opisów API do różnych funkcji jądra. Poprosił o pomoc, w tym zawierającą informację o wszystkich ,,eksportowanych'' funkcjach. Ignacio Vazquez-Abrams zasugerował używanie DocBooka w miejsce czystego XML-a, ale Charles odpowiedział, "DocBook nadaje się bardziej do książek, z rozdziałami i wszystkim takim. Używałem go wcześniej, jest przyjemny, ale myślę, że nie do tego celu. Poza tym, dane z XML-a są umieszczane w tymczasowych bazach MySQL-a dla ułatwienia wyszukiwania, sortowania i podobnych rzeczy i sądzę, że byłoby to trudniejsze z docbookiem. " Wichert Akkerman zauważył, że DocBook może być XML-em, ale nie było odpowiedzi.

W innym miejscu Crutcher Dunnavant zauważył, że jest już prowadzony projekt dokumentacji API jądra. Przedstawił też własną dokumentację opisującą dobre nawyki przy rozwijaniu jądra. Dodał, że pomoc byłaby mile widziana i że należy być świadomym, że dokument jest jeszcze w bardzo wczesnej fazie. John Levon dodał jeszcze odnośnik do istniejącej dokumentacji API .

5. Informacja o cache dla procerów Duron

17 Jul 2001 (13 posts) Archive Link: "2.4.6-ac5 podaje złą informację o cache dla procesorów Duron w /proc/cpuinfo"

Summary By Adam Buchbinder

People: Christian Borntreger, David Balazic, Ketil Froyn, David Woodhouse, Alan Shutko

David Balazic, używający 2.4.6-ac5 na procesorze AMD Duron 700, zgłosił, że z /proc/cpuinfo wynika, że posiada on 64K cache, podczas gdy wie on, że Duron ma 192K cache: 64 L1 I, 64 L1 D, 64 L2 unified.

Christian Borntreger napisał " Jeśli się nie mylę starsze Durony miały błąd. zgłaszały zły rozmiar cache. " Ale David zauważył, że: "Komunikaty jądra w czasie bootowanie nie mają problemu ze znalezieniem właściwej informacji o wielkości cache. " Innym razem Christian wyraził przypuszczenie, że do /proc/cpuinfo zgłaszany jest tylko cache drugiego poziomu. David odpowiedział, że "powinno być więc "L2 cache size:" Zatem w każdym wypadku jest to błąd." Na tym skoñczył się ten fragment wątku.

W innym miejscu odbyła się debata nad prawidłowym skrótem ,,kilobajtów''. Ketil Froyn zaproponował, aby popatrzeć na acronymfinder.com, mówiąc jednocześnie, że właściwymi skrótami są: "'K' dla 1024, 'k' dla 1000 i 'B' dla bajtów, a 'b' dla bitów" . David Woodhouse powiedział, "Właściwym prefiksem oznaczającym wielokrotoność 1024 jest 'Ki'" , i wysłał łatkę, która zmieniała te skróty. Kilka listów dalej Alan Shutko stwierdził, że 'Ki' jest " rozsądnym nowym standardem, który jednak nie został przyjęty, bo wiele ludzi uważa, że mówienie ,,Kibibajt'' jest głupie."

Sharon And Joy