Kernel Traffic #175 For 2002/07/15

There were 388 different contributors. 176 posted more than once. 126 posted last week too.

Miles Lane spytał się, czy jest jakiś sposób, by, gdy laptop jest zasilany z baterii, przemontował automatycznie system plików z ext3 na ext2. Kilka osób stwierdziło, że nie jest to możliwe i spytało Milesa, po co mu to. Andrew Morton zastanawiał się na głos: "Czy to z powodu zbytnio-przyspieszających-dysków, gdyż w takim wypadku można problem rozwiązać ustawiając odstęp pomiędzy zapisami na dysk na odpowiednio dużą wartość." Miles potwierdził, że właśnie dlatego wspomniał o tym, po czym spytał się, czy jest jakiś sposób, by wartość tego odstępu zmieniała się automatycznie przy zmianie źródła zasilania na baterie. Andrew odpowiedział: "Jeśli warstwa APM/ACPI potrafi zawiadamiać środowisko użytkownika o zmianach, to tak, jest to coś, co można zrobić przy pomocy ich skryptów wspomagających." Pavel Machek włączył się do rozmowy: "ACPI powinno być w stanie przekazać te informacje. Prosiłbym o przesłanie tej łaty Linusowi, jako że wygląda dla mnie bardzo użytecznie." Gdzie indziej kilka osób omawiało różne szczegóły implementacji, a Stephen C. Tweedie stwierdził, że doda tę poprawkę do drzewa, jak tylko wróci z Ottawa Linux Symposium.

Dan Sturtevant spytał się: "Wiem, że w linuksie na x86 strona w przestrzeni użytkownika jest wielkości 4K, a w przestrzeni jądra -- 4M. Te dwie wielkości wyglądają na ograniczenia architektury intela (przynajmniej tak mi się wydaje). Czy ktoś zna jakiś sposób, by zwiększyć rozmiar strony w przestrzeni użytkownika powyżej 4K? Czy są jakieś łaty na zmianę rozmiary strony w przestrzeni użytkownika na 4M?" Kilka wiadomości niżej Peter Svensson wytłumaczył: "Procesory x86 na poziomie sprzętu mogą używać stron o rozmiarach 4K lub 4M. Strony 4M są zastrzeżone dla jądra ze względu na różne problemy" ... "strony 4M są przydatne przy minimalizacji chybień tlb, które to mogą być kosztowne przy niektórych algorytmach." Wskazał Danowi wcześniejszą dyskusję na liście o temacie: Czy zarządzanie pamięci w jądrach 2.4 na dużych maszynach zostało naprawione? Steven Cole także dał odnośnik do strony 2002 Ottawa Linux Symposium, która to zawierała wszystkie referaty w formie pliku PDF. Ostrzegł, że całość ma 631 stron i wskazał strony 573-593 jako traktujące o tym temacie.

Gregory Giguashvili spytał, dlaczego Linux nie jest w stanie automatycznie wykrywać wszystkich konfiguracji sprzętowych. Po kilku nieporozumieniach związanych z użytymi przez niego słowami wyjaśnił, co miał na myśli, a Jesse Pollard wyjaśnił:

Większość wymiennych/odłączalnych taśm/skanerów/dysków jest na USB.

Jeśli tak jest w twoim przypadku - tak, mogą być zarządzane automatycznie.

Musisz skonfigurować demona USB i sterowniki. Po jednorazowym wykonaniu tej czynności wszystko powinno dziać się automatycznie. W zależności jednak od dysku (twardy dysk, system plików, pozwolenie na dostęp) pojawiają się dodatkowe komplikacje.

Nie wszystko POWINNO być możliwe automatycznie. Na przykład - obejście ograniczenia dostępu do dysku może pozwolić użytkownikowi stacji roboczej na naruszenie polityki bezpieczeństwa ustalonej dla twardego dysku. To samo można powiedzieć o taśmie, bądź o dyskietce. Takie polityki NIE SĄ implementowalne wewnątrz jądra (przynajmniej nie w przenośny sposób).

To jedna z przyczyn, dla której automatyczne montowanie niekoniecznie jest pożądane. Polityka taka nie może być obsługiwana (czy nawet identyfikowana) przez jądro.

Jednak skanery i drukarki są bardziej neutralne - nie przechowują danych, do których dostęp jest w jakiś sposób chroniony. Przynajmniej nie w Stanach Zjednoczonych. Te urządzenia są zazwyczaj dostępne zaraz po podłączeniu. (Chociaż wciąż pracuję nad uruchomieniem mojego skanera/drukarki HP G55 - jest rozpoznawany przez podsystem USB zaraz po podłączeniu).

Sądzę, że w innych krajach skanery muszą umieć znakować dane, w celu identyfikacji źródła. (nie zapobiega to podrabianiu, ale to kwestia bardziej polityczna).

Możemy to robić dla niektórych typów urządzeń. Nie tylko w trakcie uruchamiania systemu, ale również przy podłączaniu urządzeń w trakcie pracy. Opcja w jądrze nazywa się CONFIG_HOTPLUG, sygnalizuje przestrzeni użytkownika, że coś się zmieniło i mówi co.

Nie jest zadaniem jądra decydowanie, co zrobić (np. przyłączasz skaner USB, może chcesz załadować odpowiednie moduły jądra, włączyć KDE i kooka, zeskanować i zapisać do /tmp/pr0n; albo zignorować to podłączenie, bo skaner jest hałaśliwy i zostawisz go do skanowania w nocy, jako zadanie crona). Dlatego podejmujemy takie wybory w przestrzeni użytkownika. To zazwyczaj jakiś demon uruchamiany jako /sbin/hotplug (chociaż możesz zmienić nazwę korzystając z /proc). Przykładowe skrypty można zdobyć z http://linux-hotplug.sf.net/, gdzie znajduje się również wiele dokumentacji na ten temat.

załączona łatka dodaje właściwość, która była umieszczona dosyć wysoko na ,,schedulerowej'' liście życzeń: implementuje ona w bezpieczny sposób funkcjonalność SCHED_IDLE. Inną, pożądaną przez społeczność funkcjonalnością schedulera, było wsadowe szeregowanie zadań, traktujące w sposób ,,cache-friendly'' niskopriorytetowe, wsadowe, przywiązane do jednego procesora, w 100% nieinteraktywne zadania. Nowe, domyślne zachowanie SCHED_BATCH implementuje obie te funkcjonalności.

istniejące już łaty implementujące SCHED_PATCH, pomimo swojej prostoty, miały jedną poważną wadę, która nie pozwalała na integrację z algorytmem szeregowania; jeżeli nieuprzywilejowany proces SCHED_IDLE używał normalnych funkcjonalności jądra, mogło to prowadzić do przejęcia krytycznych zasobów procesu jądra, takich jak semafor głównego katalogu. Nie ma wtedy gwarancji, że proces zostanie dopuszczony do wykonania, więc alokując krytyczne zasoby, potencjalnie na zawsze - mógłby spowodować zablokowanie innych procesów także starających się o dostęp do tego krytycznego zasobu. Ta właściwość, będąc źródłem miękkich blokad nawet podczas zwykłego użycia, mogłaby prowadzić do wykorzystania SCHED_IDLE jako podstawy exploitów DoS.

jak wskazuje rozmiar łaty, nie istnieje łatwe rozwiązanie tego problemu. Podstawową ideą jest identyfikacja wywłaszczeń w przestrzeni użytkownika za pomocą dodatkowych wywołań schedulera: jedyną bezpieczną możliwością wywłaszczenia procesu w przestrzeni użytkownika jest stan, gdy proces jest wywłaszczany w ,,czystej'' przestrzeni użytkownika - w takim przypadku niskopoziomy kod procesu jądra wywołuje funkcję schedule_userspace(), zamiast schedule(). W każdym innym -- proces musi czekać w ,,zwykłej'' kolejce algorytmu szeregowania zadań, by zagwarantować natychmiastowe wykonanie kodu znajdującego się w przestrzeni procesu jądra systemu. Co więcej, procesy w trybie wsadowym potrzebują obsługi, gdy przychodzi do nich sygnał, w przeciwnym przypadku np. unicestwienie ich nie byłoby możliwe.

inne właściwości: SCHED_BATCH zmienia o wiele więcej, np. przyznawane kwanty czasu w trybie wsadowym - domyślna wartość takiego kwantu przy SCHED_BATCH to 1.5s. Wartości priorytetu (nice) także odgrywają rolę przy szeregowaniu zadań typu SCHED_BATCH - wskazują procentowy udział procesu SCHED_BATCH w alokacji wolnego czasu procesora. Jeżeli proces SCHED_BATCH wykonuje się w przestrzeni procesu jądra systemu, wtedy wartość nice jest używana jako zwyczajny priorytet przy wywłaszczaniu innych, nie-SCHED_BATCH procesów.

innymi słowy: zawsze, gdy proces typu SCHED_BATCH wykonuje się w przestrzeni procesu jądra systemu, jest on traktowany jak proces o szeregowaniu typu SCHED_NORMAL, co gwarantuje terminowe wykonanie kodu w przestrzeni procesu jądra. Kiedy zaś proces znajduje się w trybie SCHED_BATCH wtedy przesuwany jest on do wsadowej kolejki procesów a jego wykonanie może być opóźnione w sposób nieokreślony.

Dystrybucja czasu procesora jest uproszczoną wersją wersją algorytmu szeregowania procesów, znanego z trybu SCHED_NORMAL. Procesy SCHED_BATCH są szeregowane zgodnie z algorytmem roundrobin, czas procesora jest rozdzielany w oparciu o wartość parametru nice. Wykonanie zadań typu SCHED_BATCH, które wykorzystały przydzielony im czas procesora jest zawieszane dopóty, dopóki wszystkie inne procesy w trybie SCHED_BATCH nie wykorzystają przydzielonego im czasu procesora. Następnie wszystko zaczyna się od początku. Procesy o szeregowaniu typu SCHED_NORMAL, SCHED_RR i SCHED_FIFO wywłaszczają procesy typu SCHED_BATCH w trybie natychmiastowym. Wszystkie te nowe funkcjonalności charakteryzują się złożonością typu O(1). (Wskaźnik interaktywności odnosi się również do procesów typu SCHED_BATCH, ale tylko wtedy, gdy proces wykonuje się w przestrzeni procesu jądra systemu. To także daje nam gwarancję, że sztuczne podnoszenie priorytetu procesu nie może zostać dokonane poprzez wchodzenie/wychodzenie procesu do/z trybu SCHED_BATCH.

na architekturze SMP istnieją kolejki wsadowe dla każdego procesora - to pozwala w razie potrzeby na użycie setek/tysięcy procesów SCHED_BATCH. Został użyty nowy, niezależny algorytm dystrybucji obciążenia: procesy typu SCHED_BATCH zapełnią procesor w zależności od ,,10 sek. historii bezczynności procesora''. Im bardziej bezczynny procesor, tym więcej procesów może przetworzyć. Ważenie służy do sprawiedliwego podziału mocy obliczeniowej. Algorytm dystrybucji obciążenia uwzględnia również użycie pamięci podręcznej i próbuje zredukować niepotrzebne operacje wymiany procesów (Rozkład obciążenia, tak jak w przypadku procesów SCHED_NORMAL, nie jest typu ,,twardego'' - mogą zaistnieć pewne statystyczne rozbieżności w kwestii dystrybucji obciążenia w celu zmniejszenia ogólnej złożoności i zawiłości algorytmu)

(aby ujrzeć wieloprocesorowe (SMP) równoważenie obciążenia procesów typu SCHED_BATCH w akcji, uruchom wiele procesów SCHED_BATCH na maszynie SMP, a równomiernie zapełnią wszystkie dostępne procesory. Wtedy odpal jeden procesorożerny proces typu nie-SCHED_BATCH - po kilku sekundach wszystkie procesy typu SCHED_BATCH ,,wyniosą'' się na pozostałe procesory, a pojedynczy proces typu nie-SCHED_BATCH zajmie ,,swój'' procesor w 100%)

(notka projektowa: z początku próbowałem zintegrować szeregowanie procesów typu SCHED_BATCH z istniejącym algorytmem oraz równoważeniem obciążenia typu SCHED_NORMAL, ale zarzuciłem tę ideę. Pomimo, że działało to dla algorytmu szeregującego systemu czasu rzeczywistego, SCHED_BATCH okazał się całkiem inny - w 100% ortogonalny dla innych domen. Np. algorytm rozkładu obciążenia procesów typu nie-SCHED_BATCH *nie może* w żaden sposób zależeć od algorytmu rozdzielania procesów typu SCHED_BATCH na poszczególne procesory. Algorytmy podziału czasu procesora także muszą być od siebie odseparowane. Co za tym idzie, jeżeli kolejki i stany są od siebie odseparowane, to oznacza, że mogą rezydować na osobnych (i uproszczonych) strukturach danych

załączam także setbatch.c, który jest prostym narzędziem do zmiany polityki szeregowania procesów SCHED_BATCH dla zadanego identyfikatora procesu (PID). Bezpośrednią metodą użycia funkcjonalności jest ustawienie właściwości SCHED_BATCH dla bieżącej powłoki

./setbatch $$

i uruchomienie różnych poleceń z naszej powłoki o właściwości SCHED_BATCH - wszystkie potomne procesy będą dziedziczyły właściwość SCHED_BATCH

obciążenia generowane przez procesy typu SCHED_BATCH nie są uwzględniane w parametrze load average - co jest rozwiązaniem w stosunku do procesów wrażliwych na zmiany load average, takich jak sendmail

poprawa wydajności po zastosowaniu funkcjonalności SCHED_BATCH jest praktycznie niezauważalna. Istnieje pewien koszt wywołania funkcji wywłaszczających znajdujących się w entry.S. Poza tym, kod obsługi SCHED_BATCH aktywuje się jedynie podczas stanu niezajętości systemu, np. wtedy, gdy chcemy przełączyć się na proces bezczynny

łatka została przetestowana na architekturze x86. Systemy nie-x86 będą działać z zaaplikowaną łatką, lecz procesy typu SCHED_BATCH, będą w rzeczywistości ,,wisiały''. Aby zmusić je do działania, architektura musi wywołać schedule_userspace(), zamiast schedule(), podczas gdy kod działający w prawdziwej-przestrzeni-użytkownika jest wywłaszczany.

załączona łatka została stworzona dla jądra 2.5.24 i została przetestowana na systemach zarówno wielo-, jak i jedno-procesorowych, ale pamiętajcie, że jest to pierwsza wersja łatki, więc mogą pojawić się różne, nieprzewidziane rzeczy w jej działaniu. Łatka może także zostać ściągnięta z mojej strony domowej łatek ze schedulerem:

http://redhat.com/~mingo/O(1)-scheduler/batch-sched-2.5.24-A0

Pojawiło się zaledwie kilka komentarzy na ten temat. Nicholas Miell miał kilka pytań na temat zgodności łatki Ingo ze standardami IEEE, ale odpowiedzią na jego zastrzeżenia był pomysł, aby rozwiązać to w przestrzeni użytkownika. Pomimo tego, Nicholas przestrzegł: "Pamiętaj, że, być może, pewnego dnia osoba szukająca funkcjonalności SCHED_BATCH w jądrze systemu będzie zdziwiona brakiem implementacji polityki szeregowania typu SCHED_OTHER i będzie prosiła Cię o wyjaśnienia, możesz też zrobić notkę w źródłach, o tym, że obecnie SCHED_OTHER to SCHED_NORMAL i w ten sposób wyeliminować wszelkie wątpliwości." Ingo zastosował się do tej rady.

Bill Davdsen zapytał, co wstrzymało implementację schedulera O(1) w 2.4. Wskazał, że jak na razie w kilku dystrybucjach takie rozwiązania są już używane bez żadnych informacji o niewłaściwym działaniu. Ingo Molnar odpowiedział: "cóż, łatka ma juz prawie 6 miesięcy. Nowy algorytm szeregowania procesów zmienia ,,serce'' jądra i jest czymś, co raczej nie powinno pojawić się w stabilnym drzewie jądra, szczególnie teraz, gdy jądro zaczęło ewoluować do stanu, który możnaby nazwać stabilnym... " Bill zauważył, że dotychczas było kilka poważnych ingerencji w podsystem pamięci wirtualnej jądra 2.4, które mogły w jeszcze większym stopniu osłabić stabilność, niż nowy algorytm szeregowania. Nikt na to nie odpowiedział.

Gdzie indziej, Tom Rini wskazał, że obecne jądro 2.4 to 2.4.19-rc1 i jakakolwiek poważna zmiana mogłaby uniemożliwić przekształcenie go w oficjalne 2.4.19. Powiedział także, że obecne drzewo 2.4 nie było przewidziane do aplikowania tak dużych zmian, ponieważ jest to, przynajmniej teoretycznie, stabilne drzewo. Bill odpowiedział:

Od 2.5 stan zamrożenia wersji jądra nie jest planowany, aż do czasu zupełnej ,,klapy''. Sądzę, że możesz przyjąć, iż pojawią się kolejne wersje po 2.4.19... Od kiedy zostało to przetestowane, jak żadna inna rzecz w stabilnej wersji jądra, wydaje się, że istnieje pewien powód, aby odłożyć to na rok, zakładając wydanie 2.6 w ciągu sześciu miesięcy od zamrożenia.

Stabilne, nie znaczy umierające, mamy już działający VM Andrei, który ma DUŻE szanse na dziwaczne zachowanie na sprzęcie o innej długości słowa. Trzymanie pod kloszem wydajności przez kolejny rok i próbowanie wtedy odseparować inne, niezamierzone funkcjonalności z 2.5 z jakiegokolwiek możliwego wydania schedulera, wydaje się ograniczaniem stabilności 2.6.

Tom powiedział, że istotnym jest zakończenie powolnego ,,czołgania'' się jądra i że zmiana schedulera na wersję O(1) będzie dużym wydarzeniem. Zbyt dużym jak na serię 2.4. Chwilę później dodał: " Nie sądzę, by małe opóźnienia, wywłaszczanie czy też O(1) mogłyby znaleźć się w 2.4. Dopóki Ingo, który jest twórcą tego wszystkiego, nie zmieni zdania, co do nieaplikowania tych łatek w 2.4, tak się prawdopodobnie nie stanie. " Gdzie indziej, Ingo skomentował:

to może być ,,kandydat;; do włączenia, jak tylko potwierdzi swoją stabilność i odporność (w opinii testerów i deweloperów) w taki sam sposób i w takim samym wymiarze, jak to się stało w jądrem 2.4 - ale to potrzebuje czasu i obecności w dystrybucjach i drzewach takich jak -ac. To może się też nigdy nie wydarzyć podczas ,,trwania'' jądra 2.4

Należy także zauważyć, że scheduler O(1) nie jest łatką dla poprawy bezpieczeństwa lub stabilności systemu, tak jak nie jest to sterownik, który umożliwia uruchomienie sprzętu dotychczas nieobsługiwanego w obecnych 2.4. Podsystem pamięci wirtualnej był specjalnym przypadkiem, ponieważ większość ludzi twierdziła, że poprzedni był mocno spieprzony i nawet pomimo opinii niezgadzających się z łatką, obecny podsystem pamięci wirtualnej wygląda obecnie całkiem nieźle - mamy także cały czas niezłą korelację pomiędzy VM w 2.5 i VM w 2.4. Z drugiej strony obecny algorytm szeregowania w 2.4 nie wkurza 99% społeczności linuksowej, wiec mamy wybór, czy zostawić ,,solidny i pewny'' obecny scheduler, czy też przenieść się na ,,trochę lepszy, ale ciągle młody algorytm''.

jeżeli, powiedzmy, 90% społeczności linuksowej zaakceptuje scheduler O(1) i w ciągu roku lub dwóch lat nie będzie żadnej, większej dystrybucji linuksowej (włączając w to, oczywiście Debiana) bez schedulera O(1) [co, w rzeczy samej, dzieje się obecnie] to ta funkcjonalność mogłaby zostać włączona do 2.4. Ale, na razie, jak sądzę, większość użytkowników jądra 2.4 używa standardowego schedulera.

Bill odpowiedział, że scheduler o złożoności O(1) udowodnił, że jest przynajmniej tak samo dobry jak ten oficjalny, ale Ingo wtrącił: " taka jest Twoja opinia, jeżeli będzie to opinia 90% społeczności linuksowej, wtedy porozmawiamy."

Bill Davidsen zasugerował, żeby 2.7 pojawiło się, jak tylko Linus opublikuje 2.6; napisał: "Sądzę, że deweloperzy będą z dumą opiekować się 2.6 i będą pragnąć, by była to platforma dla ,,kolejnej wielkiej rzeczy''. A ich kod może być zawsze wstrzymywany dla 2.7, zanim nie zaczną jasno myśleć na temat 2.6, myśleć, czy jest on naprawdę potrzebny. Większość deweloperów jest dumna z tego, co udało im się zrobić w niedawnej przeszłości i wymagane poprawki nie będą oczywiście problemem. Jeśli zapewni się sensowny proces wypuszczania wersji -rc, to nie powinno być żadnych dużych błędów wynikających z rozpoczynania czegoś nowego." Dave Jones odpowiedział: "Niestety, mogą pojawić się ludzie, którzy będą myśleć następująco: ,,naprawię to dobrze w 2.7, a potem przeniosę do poprzedniej wersji, a w tym czasie 2.6 nie będzie szybciej naprawiane. Ludzie, którzy zanurzą się w rozwijaniu 2.7 i porzucą 2.6 na rzecz tych, którzy naprawdę troszczą się o stabilność jądra są największą troską Linusa, jeśli dobrze to zrozumiałem na kernel summit." Rob Landley odparł:

Dlaczego pozostawianie stablizacji ludziom, którym zależy na tej stabilizacji byłoby złą rzeczą? Pierwsze dziesięć wersji 2.4 było przepięknym kontrprzykładem dla teorii rozwoju oprogramowania mówiącej, żeby ,,postawić kamienny mur przed nowymi pomysłami, by przyspieszyć poprawki''. Rewia zmian stanu danej cechy oprogramowania od zamrożonego przez rozpuszczający się, rozmokły do rozchlapanego w połowie cyklu rozwoju także nie okazała się specjalnie efektywna.

Linus nie jest taki dobry w opiekowaniu się jądrami, często to zresztą pisał na tej liście. Jądro Linusa wyznacza kierunki ewolucji systemu, co nie zmienia faktu, że nie umiał on ustabilizować obsługi pamięci wirtualnej w 2.4.0, co udało się Alanowi Coxowi. (W sumie lepiej niż w głównym drzewie.) Jeśli Linus przekazałby stabilną serię Alanowi tuż po 2.4.1 biorąc miesięczny urlop, a potem otwierając nową gałąź, do której dokładałby dość wybiórczo, patrząc na to, od kogo i co dostaje, różne cechy, to czy komuś się wydaje, że więcej czasu zajęłoby ustabilizowanie 2.4, niż to się stało? (Czy łatki bio Jensa naprawdę musiały czekać na ustabilizowanie się VM? Czy Jens pomógł ustabilizować VM w 2.4?)

Już żyjemy w świecie wielu drzew jądra Linuksa, każde z nich ma innego opiekuna, który jest dobry w innych rzeczach. Linus jest błyskotliwym architektem, który jest świetny w codziennym wyskubywaniu najlepszych pomysłów z gęstej warstwy kremu, który tworzony jest przez zgodnie z prawem Sturgeona (to znaczy, że 90% z tego to śmieci. przyp. tłum.) Jeśli zaprezentuje się mu cztery sposoby zrobienia czegoś, to lepiej niż ktokolwiek inny zauważy ukryty piąty. Ale mówienie ,,nie'' w taki sposób, żeby promować stabilność, to już inna umiejętność i ostatnio Linus długo pozostawał w stanie mówienia ,,nie'' i podobało mu się niewykorzystywanie łat stabilizujących VM przygotowywanych przez ówczesnego opiekuna VM. A zamrażanie pewnych cech nie było w przeszłości znacząco efektywne dla produkowania szybko stabilnych jąder.

,,Stabilizujący podział'' rozwijanych serii mógłby być zrobiony w ramach eksperymentu, podczas następnego ,,rozmaczania cech systemu''. Opiekunowie, którzy specjalizują się w stabilizowaniu kodu (Ty, Alan i Marcelo wszyscy wykonujecie wspaniałą robotę w tym kierunku; to nie jest powszechna umiejetność, ale nie jest tak rzadka, jak cecha błyskotliwego architekta, takiego jak Linus) mogą wydzielić drzewo, w którym będzie mozna dokonywać jedynie poprawek i które może, ale nie musi zostać 2.6 i zobaczyć jak to zadziała.

Jeśli to zadziała, to świetnie, jeśli nie, to w porządku. Już opiekujecie się odgałęzieniami drzewa Linusa, a Alan opiekuje się jednym takim odgałęzieniem od drzewa Marcelo. Red Hat i SuSE także utrzymują swoje własne odgałęzienia. Istnienie takich podziałów, z kompetentym opiekunem i własną bazą użytkowników, nie jest z gruntu groźne dla reszty świata. Przekazywanie łat z jednego drzewa do drugiego i nie zajmowanie się resztą, póki nie będzie włączona to to, co Ty i Alan i tak robicie normalnie, zatem gdyby okazało się, że to jednak NIE działa (poddanie się po paru miesiącach z powodu tego, że ,,pfuj, ludzie nie chcą po prostu słuchać nikogo innego niż Linus'') nie jest własciwie katastrofą. Tak długo, jak opiekun jest kompetentny w łączeniu, by uporządkować całą gałąź; a jeśli by wymienieni opiekunowie jednak tacy nie byli, to chyba nie mogliby efektywnie zarządzać własnymi drzewami.

Jawne wyodrębnienie gałęzi przeznaczonej tylko do uzyskania stabilności mogłoby się nawet stać narzędziem pomagającym w stabilizowaniu gałęzi Linusa (jeśli to jest, albo zostanie, celem), dzięki śledzeniu błędów i poprawianiu wydajności w środowisku z mniejszą liczbą zawirowań, w trakcie ciężkich prób wprowadzenia tak niewielu nowych problemów, jak to tylko możliwe, przy czym byłoby to głównym celem takiej gałęzi. Wiele błędów zostało wyśledzonych w -dj lub -ac, a poprawki później przeniesiono do głównej wersji jądra.

Gdy gałąź stabilna osiągnie 2.6, to 2.6 może się ROZPOCZĄĆ od razu z nowym opiekunem, takim jak Marcelo dla 2.4 i Alan dla 2.2. Od opiekunów stabilnych gałęzi i tak normalnie nie oczekuje się podejmowania wielkich decyzji architekturalnych, od tego są jądra rozwojowe. :)

Jeśli nic nie pomaga, to takie rozwiązanie redukuje skłonność do rozwijania jądra przy mglistych zapewnieniach, że ,,już żadnych nowości, no dobrze, jeszcze jedna, ale to już koniec'' przez większość roku.

Tak, w teorii 2.5, którym opiekuje się Linus, powinno STAĆ się gałęzią stabilizującą w trakcie zamrożenia. To się może nawet zdarzyć tym razem. Ale czy zaszkodzi zabezpieczenie takiego zakładu?

Pomyśl o tym, kto zajmie się tą stabilizacją. Czy naprawdę myślisz, że Alan lub Marcelo zajmą się 2.6 jak tylko się ukaże? Albo Ty sam, lub ktoś inny zajmie się 2.6?

Jedno z podstawowych pytań, które trzeba zadać rozważając problem ,,czy oddzielić 2.7 razem z 2.6'', to pytanie _kto_ dokładnie będzie się zajmował 2.6. Dave Jones? Jeśli Dave, to kto zastąpi Dave'a w zapewnianiu, by poprawki były rozpowszechniane w stabilnych i niestabilnych drzewach?

Dave Jones zauważył, że Marcelo Tossatti nie sprzeciwiał się przejęciu 2.6, w chwili, gdy wypuszczone zostanie 2.7. Dave napisał: "ponieważ do tej pory wykonał kawał dobrej roboty nad 2.4, to wydaje się, że jest idealnym człowiekiem na tę pozycję (o ile czas pozwoli). W chwili, gdy opublikowane zostanie 2.6.0, 2.4 powinno zwolnić tempo rozwoju na tyle, że zacznie on szukać czegoś innego do roboty." W kwestii swojej przyszłej pozycji, Dave dodał: "Gdy dotrzemy do 2.6, będę robił 2.6-dj tak długo, aż wszystkie ważne kawałki nie zostaną przekazane $opiekunowi, i będę je kontynuował aż do 2.7-dj."

W innym miejscu Adrian Bunk bardzo zaprotestował przeciwko wydzieleniu 2.6 i 2.7 w tym samym czasie. Napisał:

Stabilne podstawy do rozpoczęcia nowej wersji rozwojowej są bardzo korzystne (a ja nie wierzę w stabilność 2.6.0).
Pojawi się coś, co nazwałbym ,,syndromem Debiana'': Jest bardzo niewielu deweloperów używających stabilnego Debiana, bo nawet w trakcie cyklu wydawania, istnieje niestabilne drzewo. Jednym z wyników takiej sytuacji jest to, że wielu deweloperów Debiana nie skupia się zbytnio na pracy nad kolejną stabilną wersją (aktualna stabilna wersja Debiana ma prawie dwa lata i nie wspiera jąder 2.4...).

Jeśli 2.7 nie zacznie się zanim 2.6 nie zostanie _naprawdę_ stabilne, wszyscy, którzy będą chcieli mieć nowe drzewo rozwojowe będą bardziej zainteresowani zrobieniem naprawdę dobrego 2.6, zamiast od razu skupiać się na 2.7.

Wydaje się, że powodem, dla którego to zaproponowano był fakt, że sporo nowych rzeczy zostało wepchniętych do 2.2 i 2.4 w początkowym okresie i że NIE były stabilne. Ponieważ proponują to ludzie bardziej wpływowi niż ja, to jasne, że przynajmniej niektórzy goście czują, że warto spróbować czegoś innego.

Opiekun może zawsze umieszczać naprawdę nowe rzeczy w 2.7, a Linus zawsze może odmówić włączenia danej cechy do 2.7 zanim coś innego nie zostanie naprawione w 2.6. Patrząc na to, jak ciężko ludzie pracują nad przenoszeniem różnych rzeczy z 2.5 na 2.4, wierzę, że zostanie podjęty dodatkowy wysiłek.

Opiekuję się równolegle drzewami 2.5 i 2.4 ARM i to jest *naprawdę* ciężka rzecz. Jest kilka problemów:

znalezienie czasu, by sensownie budować i testować każdą wersję jądra na odpowiednim sprzęcie.
śledzenie, co zostało włączone, do którego jądra.
pozyskanie deweloperów do tworzenia łatek zarówno na stabilne, jak i na rozwojowe jądra w zasadzie się nie zdarza.

Końcowy efekt jest taki, że obecnie w 2.4 obsługiwane jest więcej różnych maszyn ARM niż w 2.5, ale tylko 2.5 zawiera moje nowe rozwiązania.

Jeśli 2.6 i 2.7 pojawią się w jednym momencie, to _wpadniesz_ w te same problemy ze społecznością. Jeśli ludziom nie będzie się chciało wkładać mnóstwa w pracy w łatki, które nakładać się będą na dwa istotnie różne drzewa źródeł jądra, to skończysz tak samo. A nie jest to wcale zabawne.

Miałem szansę na przejrzenie dokumentacji modelu sterowników. Usunąłem większość poważnych niedokładności, chociaż mogły pozostać jeszcze jakieś niedopatrzenia. Dokumentacja jest dostępna pod adresem:

http://kernel.org/pub/linux/kernel/people/mochel/doc/

Zachęcam każdego do spojrzenia. Nie krępujcie się z wysyłaniem komentarzy, poprawek lub łatek.

Dodatkowo, wystawiłem moje drzewo BK tutaj:

bk://ldm.bkbits.net/linux-2.5/

W tej chwili, jedyne rzeczy, jakie się tam znajdują, to wspomniana wyżej dokumentacja i poprawki do bieżącej dokumentacji.

Arnd Bergmann przejrzał dokumentację i razem z Patrickiem przedyskutował szczegóły.

Tim Schmielau zauważył: "Wygląda na to, że często zakłada się, że można używać wszystkich nagłówków wciąganych przez sched.h bez deklarowania tego. Ponieważ dążą do uczynienia tego założenia fałszywym, gdyż pracuję nad usuwaniem wszystkich niepotrzebnych włączeń plików nagłówkowych - zacząłem od rozdzielenia nagłówków wciąganych przez sched.h. To jednak dopiero mały krok na początek, łatka obejmująca całe poddrzewo include/ byłaby około 25 razy większa. Jednakże, zanim bardziej się w to zagłębię, chcę mieć pewność, że nie naruszę pewnych reguł pozwalających uznać niektóre pliki nagłówkowe za włączone lub dołączone przez importowanie plików .c, lub czegoś takiego. Dlatego wszelkie komentarze są mile widziane." Stephen Rothwell uznał to za super plan, dodając: "Moim zdaniem każdy plik (włącznie z nagłówkowymi) powinien zawierać wszystkie pliki nagłówkowe od których zależy. To da nam pewną sznasę na utrzymanie porządku w użyciu plików nagłówkowych." Sandy Harris odpowiedział:

Wydawało mi się, że powszechna mądrość mówi, że plik nagłówkowy nie powinien #includować innych nagłówków, a pliki .c powinny wyraźnie dołączać wszystkie pliki nagłówkowe, których potrzebują.

Pogooglowanie za ,,zagnieżdżonymi nagłówkami'' zwraca kilkanaście dokumentów o stylu kodowaniu, które też tak mówią:

http://www.cs.mcgill.ca/resourcepages/indian-hill.html

http://www.doc.ic.ac.uk/lab/secondyear/cstyle/node5.html

i ten, który mówi, że jest to kontrowersyjne i może być zrobione inaczej: http://www.eskimo.com/~scs/C-faq/q10.7.html

Czy mijam się z wykładnią stylu kodowania jądra? Czy też pozbycie się zagnieżdżania nagłowków jest przydatnym celem?

Stephen odpowiedział, że ,,powszechna mądrość'' zmienia się w zależności od tego, kogo pytamy, ale dodał: "Właśnie przekonałem się, jak bolesne jest dochodzenie, których plików nagłówkowych potrzebuję, gdy potrzebna mi jest jedna lub dwie definicje. To samo ma miejsce, gdy usuwam lub przenoszę rzeczy z jednego miejsca do innego (zwłaszcza probując przeczyścić trochę obecny bałagan)." Ale Tim Schmielau też się wtrącił: "Unikanie zagnieżdżonych nagłówków owocuje w mniejszej liczbie nagłówków, które są dołączane. Jednakże, nie uważam, że jest to dobre dla jądra: wiele plików będzie się zaczynało od setek dołączeń, i nie potrafię wyobrazić sobie rozsądnego sposobu na udokumentowanie zależności pomiędzy nimi." EOT.

To jest czwarte wydanie UML dla 2.4.18.

Główne zmiany w tej wersji obejmują:

Możliwe jest teraz dołączenie UML gdb do śpiącego wątku. Jest to realizowane poprzez odłączenie gdb z wątku w kontekście i przyłączenie go do identyfikatora śpiącego procesu gospodarza UML. UML może być kontynuowany poprzez dołączenie do wątku w kontekście. Własność taka pochodzi z Cluster File Systems, Inc.

Powstał /proc/exitcode, który umożliwia procesowi UML ustawienie końcowego kodu wyjścia UML.

Poprawiono kilka segfaultów występujących podczas wołania openpty, który posiadał niezwykłe duży stos ramki, przepełniający stos jądra UML.

Włączona została łatka dla logowania tty. Umożliwia ona klatkom UML-owym logowanie całego ruchu tty do pliku na gospodarzu. Takie logowanie nie może być wykryte ani zakłócone przez administratora wewnątrz UML.

UML posiada teraz ,,sprzętowego'' watchdoga.

Bianria UML żyją teraz w swojej własnej pamięci fizycznej. To uprości przeniesienie łatki swsusp do UML.

Poprawiono błąd powstawania dużej liczby zombich powodujących panikę UML.

Istnieje możliwość robienia kopii zapasowych plików oraz plików COW (copy-on-write, czyli kopiuj przy zapisie) przy użyciu ubdx=plik-cow,nowa-kopia-pliku. Pamiętaj, aby zachować czas modyfikacji pliku, gdy przesuwasz kopię przy pomocy 'cp -p', czy 'tar p'.

Dodano obsługę punktów kontrolnych w jądrze. Można je mieszać z punktami kontrolnymi gdb w UML.

Poprawiono błąd powodujący zamknięcie deskryptorów plików, które powinny pozostać jeszcze otwarte. Można to zaobserwować najczęściej jako panikę podczas wyłączania UML, chociaż może występować w innych miejscach.

Sterownik mconsole wysyła teraz powiadomienie o panice do wszystkich klientów mconsole.

Dodano kilka własności i poprawiono pomniejsze błędy.

Strona domowa projektu to http://user-mode-linux.sourceforge.net

Pobierać można z http://user-mode-linux.sourceforge.net/dl-sf.html

Pavel Machek zapytał: "Co zapobiega temu, aby administrator z UML wstawił oszukany moduł (przypuszczalnie używający /dev/kmem) pozwalający opuszczenie pułapki?" Jeff wyjaśnił: "To jest ograniczone przez administratora zachowującego podstawowe środki ostrożności i włączającego tę pułapkę, które uniemożliwią uruchomienie, gdy włączona jest obsługa dla modułów, a oprócz tego, przy okazji uniemożliwią także zapis do /dev/kmem." Pavel złośliwie zauważył, że Jeff wyłączył zapis do /dev/kmem przez wyłączenie CAP_SYS_RAWIO, to może to kolidować z operacjami, które potrzebują CAP_SYS_RAWI. Sądził, że UML powinien poinformować, żę CAP_SYS_RAWIO jest niezatkaną dziurą, zamiast wyłączać tę funkcjonalność. Jeff zgodził się, że użytkownik może być zaskoczony znajdując wyłączone CAP_SYS_RAWIO, gdy oczekuje, że jest to wciąż dostępne, ale dodał: "Nie widziałem niczego, co przejmuje się wyłączeniem CAP_SYS_RAWIO, to jest najprostsza droga, jaką znalazłem, aby wyłączyć zapis do /dev/kmem." Pavel cały czas był zdania, że wyłączanie zapisu do /dev/kmem jest dziwnym sposobem projektowania kodu, ale Jeff zauważył, że ta cała sztuczka z wyłączaniem CAP_SYS_RAWIO jest używana jedynie, gdy jest włączona 'pułapka'.

Kolejne łatki włączone - ppc, scsi, USB, kbuild, sterowniki wejścia, etc.

I Al, i Andrew znów mają co robić.

Została dodana obsługa dla nie-100Hz wewnętrznych zegarów jądra na x86 przy zachowanym starym interfejsie do przestrzeni użytkownika (np. każdy, kto wyekportował surowe jiffies powinien eksportować ,,clock_t'', które na x86 nadal ma zachowany 100 Hz zegar niezależnie od wewnętrznych czasów jądra).

Obecnie częstotliwość x86 jest ustawiona na 1kHz, ale to jest tylko przypadkowa wartość. Jeśli ludziom będzie na tym zależeć, można z tego zrobić konfigurowalną opcję, ale wolałbym żeby trochę podyskutowali o wyższości jednych częstotliwości nad drugimi, żeby w końcu znaleźć wartość z której najwięcej osób będzie zadowolonych. Łatwo to zmienić tak, by w przestrzeni użytkownika zmiana była niezauważalna.

Inną rzeczą, jaką powinniśmy uporządkować jest zunifikowane nazewnictwo urządzeń dyskowych, skoro i IDE, i SCSI zaczynają mieć wsparcie dla driverfs. Upewnijmy się, że _możemy_ mieć jakiś rozsądny sposób na dostęp do dysków bez względu na to, czy to IDE, czy SCSI, czy cokolwiek innego.

Matthias Andree spytał się: "Czy ludzie od LVM (słuchacie tego?) mówili coś o naprawieniu obecnego w 2.5 LVM? A może zamiast tego EVMS działa na 2.5?" Joe Thornber odpowiedział:

Jeszcze raz powtórzę:

Heinz Mauelshagen opiekuje się LVM1.0.x w jądrach 2.4. To jest linia tylko do poprawek błędów, żadne nowe funkcje nie będą dodawane.

Alasdair Kergon, Patrick Caulfield i ja pracujemy nad bardziej ogólnym sterownikiem mapującym urządzenia dla obydwu serii jąder 2.4/2.5. Na początku skoncentrowaliśmy się na 2.4, ten sterownik jest w tej chwili MSZ bardzo stabilny (z pewnością powierzyłbym mu swoje dane z większą ufnością niż LVM1).

Podeślę URL do łaty do 2.5 jakoś w tym tygodniu.

Nikt nie ma zamiaru utrzymywać zupełnie nieudanej koncepcji, jaką jest LVM1 w serii jądra 2.5 -- nie mamy zasobów, aby je tak marnować.

Alexander Viro odparł: "W porządku. Więc może usuńmy to z drzewa? Jest zepsute; nie będzie naprawione; zostało porzucone przez opiekunów (i $BÓG mi świadkiem, istnieje wiele bardzo dobrych powodów do tego); nie ma nikogo, kto były w stanie i chciałby się za to zabrać. Więc jaki jest cel utrzymywania tej cholernej rzeczy w jądrze? Czy mógłbyś (albo Heinz) podesłać łatkę usuwającej LVM1 z 2.5?" Nie było odpowiedzi.

Ta łata jest oparta na minimalnej wersji rmapa Craiga Kulesy dla 2.5.24 z kilkoma zmianami:

usunięcie kilku niezwiązanych zmian
aktualizacja armv/rmap.h do nowego układu tablicy stron w linux/arm
usunięcie wolnych list pte_chain dla każdej strefy, chcemy mieć listy dla każdego procesora w celu usiągnięcia lepszej skalowalności SMP
przeniesienie do 2.5.25 (PF_NOWARN zamiast PF_RADIX_TREE)
usunięcie literówek i poprawek białych znaków (zostanie włączone oddzielnie)
usunięcie wyścigu w truncate_complete_page (akpm)

Łatka jest już prawie gotowa do włączenia do drzewa 2.5, z tym że obsługa pte-highmem cały czas czeka na implementację (kilka osób z IBM już się zgłosiło do tego, ta funkcjonalność może jednak bez przeszkód być dodana później).

W tej chwili łatka potrzebuje testowania oraz uważnej lustracji.

Andrew Morton i Linus Torvalds przedyskutowali błąd związany z (ale nie znajdujący się bezpośrednio w niej) łatką Rika. Jakiś czas później Sebastian Droege zgłosił: "przez chwilę używałem tej łatki i muszę powiedzieć, że stara implementacja VM i pełny rmap (z łatki Craiga Kulesy) były lepsze. Po pewnym okresie działania (4 godziny - 2 dni) oraz intensywnych operacjach na pamięci, system zdecydowanie zwalnia i zaczyna zbyt dużo swapować. Może tak jest tylko u mnie, ale umiem to powtórzyć." Rik wyjaśnił:

To jest znany problem z jednokrotnym użyciem. Użytkownicy waniliowego 2.4.18 również na to narzekają.

To jest kwestia, którą się zajmiemy, gdy mechanizm odwrotnego mapowania zostanie już włączony. Linus powiedział, że chce włączać to w małych kawałkach, więc właśnie to robimy ;)

Chris Friesen chciał dostarczyć sterowniki do ATM i SONET, ale nie był w stanie znaleźć opiekuna. Zapytał więc komu ma przysyłać łatki, a Jeff Garzik odpowiedział, że te sterowniki nie mają obecnie opiekuna. Zaoferował Chrisowi tę robotę, ale ten odpowiedział: "<brrrrr> Raczej nie... Widziałem ile to może być roboty. Chociaż podejrzewam, że przy ATM to było by zdecydowanie mniej zachodu niż powiedzmy przy ethernecie." Gdzie indziej, Joe Perches także odpowiedział na pierwsze pytanie:

Chyba Linux-ATM na sourceforge'u http://linux-atm.sourceforge.net/

Zauważyłem, że wysłałeś tam takie samo pytanie miesiąc temu...

Deweloperzy Linux-ATM na SourceForge'u

Werner Almesberger almesber almesber at users.sourceforge.net
Mitchell Blank Jr mblank mblank at users.sourceforge.net
Paul B. Schroeder paulsch paulsch at users.sourceforge.net

Mógłbyś się zapisać jako deweloper tego projektu na sourceforge'u i swoje zmiany od razu wkładać do tamtego CVS-u.

Oczywiście mógłbyś po prostu wysyłać łatki na listę i/lub zostać opiekunem.

Oleg Nesterov zauważył, że zgodnie z Documentation/preempt-locking.txt, wyłączenie przerwań zapobiegnie wyłączaniu, o ile aktualnie działający proces nie ustawił flagi TIF_NEED_RESCHED. Robert Love odrzekł:

Tak, masz rację, jeśli użyjesz need_resched, zostaniesz wywłaszczony po zdjęciu ostatniej blokady, nawet jeśli przerwania są wyłączone.

Jednakże, jedyne miejsca w kodzie jądra, które potrzebują użyć need_resched w ten sposób znajdują się w schedulerze i w dodatku robią to przy założonej blokadzie, więc jesteśmy bezpieczni.

W Twoim przykładzie, będąc w procedurze obsługi przerwania podbijamy preempt_count, więc nawet scenariusz, który podałeś nie spowoduje wywłaszczenia. Jeśli byśmy tego nie zrobili, to w dostalibyśmy wiele BUG()-ów ,,szeregowanie w przerwaniu'', więc niewątpliwie byśmy to zauważyli ;-)

Jednakże błąd istnieje: send_reschedule może ustawić need_resched na innym procesorze. Jeśli inny procesor ma przypadkiem wyłączone przerwania, możemy wywłaszczać. Właśnie napisałem łatkę na to i ją wkrótce wyślę.

Oleg nie zgodził się z tym, że kod jest bezpieczny. Powiedział: "jeśli proces nie trzyma żandej blokady, a przerwania są wyłączone, to każde odległe pośrednie wywołanie resched_task() po cichu włączy przerwania. To przynajmniej powinno zostać udokumentowane." Robert odrzekł:


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

1.	24 lip 2002 - 5 li[ 2002	(18 posts)	Zmniejszanie obrotów dysku gdy wyładowują się baterie
2.	26 lip 2002 - 5 lip 2002	(7 posts)	Rozmiary stron na x86
3.	27 lip 2002 - 4 lip 2002	(9 posts)	Drobna dyskusja o autodetekcji sprzętu
4.	30 lip 2002 - 7 lip 2002	(9 posts)	Implementacja SCHED_IDLE
5.	1 lip 2002 - 7 lip 2002	(28 posts)	Stan schedulera O(1) w 2.4
6.	1 lip 2002 - 7 lip 2002	(19 posts)	Dyskusja nad terminarzem publikowania głównych wersji jądra
7.	2 lip 2002 - 5 lip 2002	(6 posts)	Dokumentacja modelu sterowników
8.	3 lip 2002 - 5 lip 2002	(5 posts)	Lokalizowanie dyrektyw #include
9.	5 lip 2002 - 9 lip 2002	(8 posts)	Bezpieczeństwo User-Mode Linuka
10.	5 Jul 2002 - 8 Jul 2002	(11 posts)	Linux 2.5.25 nadchodzi
11.	5 lip 2002 - 11 lip 2002	(11 posts)	Nowa łatka dla podsystemu pamięci wirtualnej z odwrotnym mapowaniem
12.	9 lip 2002	(4 posts)	Status opieki nad ATM/SONET
13.	11 lip 2002	(5 posts)	Wywłaszczanie przy wyłączonych przerwaniach

Kernel Traffic #175 For 2002/07/15

By Zack Brown

Translated By: Krzysztof Wilczyński , Maja Królikowska , Mariusz Mazur , Paweł Kot , Robert Święcki and Tomasz Torcz