|
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 |
Table Of Contents
| 1. | 13 Jan 2002 - 21 Jan 2002 | (212 posts) | Fundamentalne zmiany w obsłudze sterowników w 2.5 |
| 2. | 16 Jan 2002 - 19 Jan 2002 | (9 posts) | Maksymalna liczba procesorów w systemach SMP |
| 3. | 17 Jan 2002 - 24 Jan 2002 | (23 posts) | Stan 2.5 |
| 4. | 17 Jan 2002 | (3 posts) | Porządki w mtrr.c |
| 5. | 18 Jan 2002 - 23 Jan 2002 | (14 posts) | Problemy z kernel.org |
| 6. | 24 Jan 2002 | (1 post) | Reorganizacja Configure.help |
Introduction
Jadę na krótkie wakacje w odludne miejsce, więc przez dwa następne tygodnie nie będzie Kernel Traffic. Postaram się opisać cały ruch z listy w następnym odcinku.
Mailing List Stats For This Week
We looked at 2171 posts in 9467K.
There were 616 different contributors. 302 posted more than once. 206 posted last week too.
The top posters of the week were:
1. Fundamentalne zmiany w obsłudze sterowników w 2.5
13 Jan 2002 - 21 Jan 2002 (212 posts) Subject: "wykrywanie urządzeń ISA -- eleganckie rozwiązanie"
People: Alan Cox, Eric S. Raymond
W trakcie dyskusji Alan Cox powiedział, że: "Jeśli wszystko potoczy się zgodnie z planem, to w 2.5 nie będzie takiej rzeczy, jak ,,wkompilowane'' sterowniki. Gdy initramfs będzie już trzymał te ,,wkompilowane'' moduły, nie będzie to potrzebne." Eric S. Raymond odparł:
A to niespodziewajka. Niekoniecznie zła, ale...
Alan, czy Ty *w* *ogóle* *zdajesz* *sobie* *sprawę*, jak bardzo musiał być skompilowany silnik dedukcyjny CML2, ponieważ opcje były trzystanowe, a nie takie jak w logice dwuwartościowej? Jeśli ten plan się powiedzie, to będę w stanie wyrzucić co najmniej 20% kodu, z którego większość to jakieś skomplikowane dziwolągi, co znacznie poprawi możliwość opieki nad tym kodem. I będę mógł się pozbyć tej okropnej flagi ,,vitality'', która przypuszczalnie jest najgorszym wrzodem na języku.
Łorany... więc jak szybko to może się stać?
Alan odparł: "Zajmiemy się tym, gdy cała reszta initramfs będzie już działać. Nawet jeśli nie, to można zmusić do działania przypadek z lsmod, ponieważ jest to tylko sprawa wstawienia nazw do segmentu tak, aby konsolidator mógł sprawdzić kolejność ich ustawienia." Eric powiedział:
Plum. Dzięki temu, interfejs do CML będzie działał lepiej w niektórych podbramkowych sytuacjach. I jego zachowanie będzie łatwiejsze do zrozumienia.
Podpisuję się pod tym. To będzie dobra zmiana; lubię, gdy mogę poprawiać różne rzeczy, *wy*rzucając takie dziwolągi z mojego kodu.
Odbyła się dyskusja na temat słów Alana. Jedni byli zachwyceni, inni byli przeciw. Najwyraźniej nie wszyscy zrozumieli prawdziwe konsekwencje i ramifikacje tej zmiany. Te konsekwencje nie zostały jeszcze w pełni przedstawione w tym wątku, ale sądzę, że w niedalekiej przyszłości będzie to jedna z bardziej kontrowersyjnych zmian.
2. Maksymalna liczba procesorów w systemach SMP
16 Jan 2002 - 19 Jan 2002 (9 posts) Subject: "ile procesorów obsługuje linux w SMP?"
People: Thomas Duffy, Ralf Baechle
Barry Wu spytał, ile procesorów jest w stanie obsłużyć Linux, a Thomas Duffy wyjaśnił: "jest 32-bitowa maska cpu, co oznacza, że 32 to absolutne maksimum, chociaż Ralf Baechle rozszerzył to do 64, aby być w stanie obsłużyć 2000 SGI, ale, tak naprawdę, to linux działa sensownie jeszcze na 8 procesorach, a potem -- lepiej nie mówić... to zależy jeszcze od obciążenia... sądzę, że 4 procesory Ci wystarczą." Ralf Baechle poprawił: "Kanoj i ja sprawiliśmy, że da się uruchomić na 128. Jednakowoż skalowalność była przerażająca przy 32 procesorach, a przy 128 -- szkoda słów..." , ale dodał: "4 procesory w chwili obecnej działają całkiem zacnie."
3. Stan 2.5
17 Jan 2002 - 24 Jan 2002 (23 posts) Subject: "[Stan 2.5] 17 Stycznia 2001"
People: Guillaume Boissiere, Erik Mouw, Jose Luis Domingo Lopez, Hans Reiser, Alan Cox
Guillaume Boissiere ogłosił:
Już kilka razy widziałem na tej liście ludzi zastanawiających się, jakie zmiany zaszły w 2.5 i w jakim stadium są prace. Pogrzebałem trochę w archiwum i ułożyłem listę rzeczy, na temat których dyskutowano / nad którymi pracowano przy 2.5 przez ostatni rok.
Jest ona w tym momencie zapewne niekompletna i pełna błędów, ale z chęcią ją poprawię, jeżeli wyślecie mi email.
Mam nadzieję, iż jest ona przydatna. Dobrej zabawy!
Kilka osób zauważyło, że JFS (pozycja 12) pochodzi tak naprawdę od IBM, a nie od SGI. Russell King wskazał także inną właściwość 2.5, w której 'serial.c' miałoby przejść restrukturyzację. Dave Jones dodał, iż do 2.5 dojdzie skalowanie zegara/napięcia zasilania CPU (wobec czego Erik Mouw zaoferował (w związku z kodem ARM) "Podstawowa obsługa jest stabilna. Musimy znaleźć ładniejszy sposób na pobieranie zmiennych z czasem dostępu do pamięci, ale jest to tylko problem przy inicjalizacji, który możemy rozwiązać później." ). Jose Luis Domingo Lopez również odpowiedział na początkowy post Guillaume'a:
Świetnie!!! Uważam, iż ta ,,lista TODO'' była bardzo potrzebna. Pozwólcie, że zasugeruję kilka rzeczy, które powinny znaleźć się w 2.5.x gdzieś w przyszłości, i które uważam za ważne:
Są też inne interesujące rzeczy, których jednak nie śledzę zbyt dokładnie, a które mogłyby być dostępne gdy 2.5.x będzie rozwijane, ale niekoniecznie.
To są, w moim przekonaniu, najważniejsze rzeczy, które _mogłyby_ być częścią przyszłego 2.6.0, jeśli ich opiekunowie uważają, że to dobry pomysł.
W tym momencie, Hans Reiser zapytał, " Czy słyszeliście może cokolwiek, na temat terminu, w którym Linus zamierza zamrozić kod? Przypuszczam, że 30 września to o wiele za wcześnie na wydanie 2.6. Pamiętam ile czasu zajęło to przy 2.4 i po prostu zakładam, że z 2.6 będzie tak samo. Przy jakimkolwiek tempie, nie ma sposobu, aby skończyć pracę przed wrześniem: to co się dzieje to dogłębne przepisywanie. Kod wygląda teraz o wiele lepiej niż ten stary..., ale jest to całkowicie nowy kod." Alan Cox odparł:
Jeżeli Linus powie wrzesień, zamrozi we wrześniu i wyda kod na gwiazdkę, będę bardzo zaskoczony. Jeżeli powie wrzesień, zamrozi w maju i wyda kod w grudniu następnego roku -- uznam to za normalne.
Osobiście, chciałbym zobaczyć jak prostują się sprawy związane z blokowym WE/WY. Niezbędne kawałki VM zrobione, uaktualnienia sterowników urządzeń i wrześniowe zamrożenie. Uważam, że jest to możliwe i myślę, że wynikowe jądro będzie dużo dużo lepsze dla ludzi z ponad 1GB RAM, o tyle lepsze, iż warte robienia czystego wydania w tym momencie.
Hans odpowiedział, "Zachęćmy go, aby dał nam jakieś ostrzeżenie, na przykład 60 dni ostrzeżenia. Zachęćmy go również do zamrożenia kodu VM i VFS jako pierwszych, nie ostatnich (na szczęście, chyba zgadza się z nami w tej sprawie). Nie zamierzam powiedzieć ani słowa na temat momentu, w którym spodziewałbym się zamrożenia, z wyjątkiem tego, że nie będziemy gotowi przed wrześniem/grudniem, ponieważ w końcu mam trochę czasu, aby zaprojektować rzeczy poprawnie i tak też zrobię. Jeśli zamrozi kod w okolicach września, będziemy mieli dla niego eksperymentalny Reiser4."
4. Porządki w mtrr.c
17 Jan 2002 (3 posts) Subject: "[patch] pozbywanie się suser/fsuser na dobre, część pierwsza"
People: David Weinehall, Dave Jones
David Weinehall powiedział: "To już w końcu czasy 2.5 i najwyższa pora na wiosenne porządki." Wysłał łatę, która poprawia kilka różnych rzeczy; jednym z plików dołączonych do tej łaty był arch/i386/kernel/mtrr.c, odnośnie którego Dave Jones powiedział: "Moim zdaniem, ten plik w szczególności wymaga czegoś więcej, niż tylko wiosennych porządków. Podczas gdy dodawano dodatkowe wsparcie dla różnych sobowtórów MTRR, robił się on coraz bardziej niechlujny, aż stał się taką breją, jaką mamy obecnie. Prawdziwe porządki w tym pliku widnieją na mojej liście TODO od miesięcy. Mam nadzieję, że zajmę się tym podczas 2.5. " David zerknął tam ponownie i zgodził się całkowicie.
5. Problemy z kernel.org
18 Jan 2002 - 23 Jan 2002 (14 posts) Subject: "problem z kernel.org..."
People: H. Peter Anvin, Stephan von Krawczynski, Larry McVoy, H. Peter, Craig I. Hagan
H. Peter Anvin zgłosił:
kernel.org dziś rano przestał udostępniać większość usług. Niestety port zarządzania systemem na nowym serwerze nie został podłączony od czasu zainstalowania nowego serwera, więc nie możemy zdalnie stwierdzić w czym problem.
Staram się dotrzeć do ludzi w ISC żeby podłączyli ten port i żebyśmy mogli przywrócić normalny stan systemu.
W innym miejscu, w temacie: kernel.org działa teraz jedynie w trybie ,,mirrors only'', napisał:
Ponieważ wygląda na to, że rozwiązanie problemu z kernel.org zajmie trochę czasu, przeniosłem system kernel.org w tryb ,,mirrors only''. To znaczy, że serwery lustrzane mogą być aktualizowane, ale użytkownicy nie mogą nic zrobić poza otrzymaniem ich listy.
Ten problem z kabelkami jest niefortunną konsekwencją tego, że musieliśmy uruchomić serwer kernel.org w znacznie krótszym czasie niż to planowano początkowo w grudniu. Jeśli tylko uda się rozwiązać ten problem, to taki rodzaj kłopotów nie powinien się powtórzyć.
W innym miejscu, na temat: Czy ktoś mógłby trzymać drugie kernel.org?, napisał:
Ostatnie kłopoty, które mieliśmy na kernel.org, bardzo podkreślają problemy, które występują, gdy nie ma łatwego fizycznego dostępu do systemu. Ta sytuacja aż błaga o pytanie, czy nie moglibyśmy ustanowić kolejnego pierwotnego kernel.org; to pomogłoby nie tylko zmniejszyć obciążenie na każdej z dwóch maszyn, ale także dawać sobie łatwiej radę z awariami.
Czy ktoś zna może jakąś organizację, która chciałaby udzielić miejsca drugiemu serwerowi kernel.org? Taka organizacja musi wiedzieć, że oczekiwany ruch to około 25 Mbit/s stałego ruchu i do 40-100 Mbit/s ruchu w szczycie (to można regulować w zależności od dostępnych zasobów.)
Jeśli tak, to proszę o kontakt ze mną...
Stephan von Krawczynski zaproponował: " Mam odrobinę inną propozycję, która może być interesująca. Lata temu robiliśmy projekt DNS, który pozwalał rozdzielić domenę na kilka _różnych_ ip, w zależności od adresu ip _pytającego_. Możecie znać taką technikę z akamai (to córka MS). Tak naprawdę zaimplemetowaliśmy to i puściliśmy testowo lata temu, ale nie znaleźliśmy zainteresowanego klienta (tak naprawdę tylko naprawdę wielcy klienci _mogą_ być w ogóle tym zainteresowani, a my nie mieliśmy ,,powiązań''). Jednakże wciąż mamy wiedzę i może zostać ona użyta, by pomóc kernel.org, jeśli jesteście zainteresowani. Podstawowy pomysł polega tu na rozdzieleniu kosztu działania kernel.org na wiele miejsc. Te umiejscowienia to mogą być (na przykład) providerzy, którzy mogą mieć w tym pewien strategiczny interes. Można też rozpocząć projekt GNU, który pozwoli rozproszyć serwery lustrzane kernel.org - mam tu na myśli sytuację, w której każdy provider, mały czy duży, może mieć swój własny serwer lustrzany i _tylko_ jego klienci (w zależności od IP lub ich AS) będą mogli go używać. W chwili, gdy nastąpi istotna awaria na pierwotnym serwerze, ludzie nie będą otrzymywali _nowych_ stron, a kernel.org będzie sam przeglądał zakres IP z ,,przymocowanym'' serwerem lustrzanym."
W innym miejscu, Larry McVoy zasugerował H. Peterowi: " Wyceniliśmy to " (wymagania H. Petera co do pasma) "ostatnio i sądzę, że najtańsze czego możesz się spodziewać to $6500/miesiąc za połączenie 25Mbit. To nie jest ogromna suma pieniędzy, ale to wystarczy by pokazała się ona na ekranach radarów w formie linii, to $80K na rok, więc wymagałaby jednak jakiegoś usprawiedliwienia." H. Peter odpowiedział, "Nie mam wątpliwości. W podobny do tego sposób pewnie dobrze jest pokazać ludziom, ile jest wart dar ISC na rzecz kernel.org ... " Larry odpowiedział:
Bez żartów. Nie miałem pojęcia, że oni to utrzymują, to bardzo miło z ich strony.
Czy masz jakiekolwiek statystyki, w których pokazane by było, jaki procent ściągania to są całe jądra, a jaki tylko łaty? Jeśli główna część ruchu to całe jądra, to myślę, że mógłbym zaproponować pewne usprawnienie całości.
H. Peter nie odpowiedział, ale Craig I. Hagan zaproponował: "W tym przypadku ustanowienie hierarchii cache'owania (np. NLANR) mogłoby pomóc."
W innym miejscu na temat: kernel.org z powrotem online..., H. Peter napisał: "kernel.org z powrotem działa i został podłączony tak, że można nim zdalnie zarządzać, więc mamy nadzieję, że uda nam się uniknąć problemów w przyszłości. Otrzymałem także sporą liczbę ofert utrzymywania drugiego serwera; Będę potrzebował trochę czasu, by przez nie przebrnąć i zdecydować, która jest dla nas najlepsza. Najogólniej, wolałbym, aby nowe miejsce wyglądało możliwie najbardziej podobnie do istniejącego, to znaczy miało dedykowany serwer, najlepiej tego samego typu."
W jeszcze innym miejscu, na temat: kernel.org: wyjaśnienie sytuacji, napisał:
Nie mogłem nie zauważyć poruszenia, jakie pojawiło się w związku z tym, że kernel.org nie działał w zeszłym tygodniu i chciałem wyjaśnić przyczynę zamieszania:
W szczególności, ta chwila nieaktywności *nie* była spowodowana awarią w nowym serwerze Compaqa. Martwi mnie trochę, że takie głosy krążą, bo to źle odbija się na darczyńcy, który ofiarował nam całkiem fajną maszynę.
Historia błędu, w przybliżeniu, przedstawia się następująco:
W grudniu, po powtarzających się problemach, najprawdopodobniej spowodowanych wiekiem ówcześnie używanego sprzętu, postanowiliśmy wymienić maszynę. Na początku planowaliśmy użyć nowego serwera w charakterze maszyny produkcyjnej po świętach, ale, gdy stara maszyna zaczęła naprawdę padać, zdecydowaliśmy się podłączyć go wcześniej.
ISC było bardzo przyjazne i pomogło nam umieścić go w bardzo krótkim terminie, nie zważając na kilka problemów logistycznych. Jednym z tych problemów był brak skonfigurowanego portu do karty zarządzania nowym serwerem. Wynikiem tej sytuacji było to, że nie mieliśmy z nim połączenia.
W ostatni piątek rano, jądro działające na serwerze, najwyraźniej przestało obsługiwać procesy przestrzeni użytkownika; szczegóły są nieznane, faktem było, że pingi i TCP SYN otrzymywały odpowiedzi, ale nie udawało się przepchnąć żadnych faktycznych danych. Co więcej, ponad 95% pakietów było gubionych, jakkolwiek maszyna nie przestawała odpowiadać na pingi, zanim nie została odłączona od zasilania i włączona z powrotem, co stało się w niedzielę.
Ponieważ nie zrozumiałem się z ekipą ISC, nie mogliśmy odłączyć zasilania od maszyny aż do niedzieli (nie podniosła się po wyłączeniu) i nie mogliśmy podłączyć portu do zarządzania aż do poniedziałku. Jak tylko podłączono port zarządzania, przywrócenie maszyny do życia zabrało 5 minut.
Na końcu chciałbym podziękować wielu ludziom i organizacjom, które złożyły ofertę utrzymywania serwera kernel.org w taki, czy inny sposób. Zamierzam ocenić wszystkie możliwości, a celem tej oceny jest uzyskanie przynajmniej jednego dodatkowego serwera, o ile to się uda. Jeśli tak, to na pewno będę wolał próbować uzyskać sprzęt identyczny z tym, który mamy obecnie.
Daniel Phillips zapytał, która wersja jądra działała w piątek, a H. Peter odpowiedział, że 2.4.16.
Koniec wątku.
6. Reorganizacja Configure.help
24 Jan 2002 (1 post) Subject: "2.5.3-pre5 - aktualizacje konfiguratora"
People: Linus Torvalds
Linus Torvalds ogłosił:
Z powodu prywatnej wojny na bluzgi dotyczącej opcji konfiguracyjnych i ich zachowania, właśnie się złamałem i zrobiłem jedną rzecz, o którą bardzo długo prosiłem innych - podzieliłem ogromny, nieporęczny plik ,,Configure.help'' na wiele mniejszych, które opisują konkretne opcje.
Podział był w dużej mierze zautomatyzowany, dzieliłem przecież plik o 25. tysiącach linii na prawie 100 mniejszych plików. Umiejscowienie ich także zostało całkiem zautomatyzowane i, tak naprawdę, to przesunięto każdy element do tego samego katalogu, w którym znajduje się pytanie konfiguracyjne, którego dotyczy dany element pomocy (a gdy pytanie powtarzało się w wielu miejscach, to także pomoc była powielana).
Ta operacja powinna _znacznie_ ułatwić posiadanie takich rozwiązań, jak opcje konfiguracyjne zależne od architektury, opcje, o których reszta świata nie chce nic wiedzieć i które nie są dla niej interesujące.
[ Zautomatyzowanie podziału pokazało też, że niektóre pytania są czasem dziwnie umiejscowione. Zrobiona została minimalna liczba przesunięć, tak by poprawić najgorsze nieprawidłowości, ale mam nadzieję, że w przyszłości uda nam się bardziej logicznie to zorganizować. ]
Jednakże, chciałbym poprosić opiekunów wszystkich narzędzi konfiguracyjnych, sterowników i architektur by sprawdzili, że elementy pomocy do ich konfiguracji wciąż istnieją i wydają się działać. Ze wszystkich narzędzi tylko podstawowy skrypt ,,make config'' był uaktualniany tak, by wiedział o zmianach w położeniu plików, zatem menuconfig/xconfig po prostu nie będą teraz umiały odnaleźć plików pomocy.
O! Architektury inne niż x86 być może także potrzebują poprawek w menu konfiguracyjnym, bo ja zrobiłem tylko niezbędną edycję z ,,przesunięciem elementów wspólnych dla architektur do init/Config.in'' (by nie powielać wszystkich wiadomości pytanie/pomoc, które są wspólne dla wszystkich architektur) i jestem całkowicie pewien, że struktura menu nie przeniosła się poprawnie.
Inne zmiany wydają się być zawarte w łacie (szczęśliwie nie codziennie sprzątasz w największym pliku w całym archiwum), załączony jest ChangeLog, więc można zobaczyć, co jeszcze się zdarzyło.
Nie było odpowiedzi.
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. |