Dla przykładu w 2.5.29 w drivers/ide/Config.in:17 mamy

dep_tristate ' SCSI emulation support' CONFIG_BLK_DEV_IDESCSI $CONFIG_ATAPI $CONFIG_BLK_DEV_IDE $CONFIG_SCSI

Ale w tej chwili, w drzewie menu dla 14 z 17 architektur, CONFIG_SCSI nie został jeszcze zdefiniowany. W wyniku tego CONFIG_BLK_DEV_IDESCSI działa tylko w ,,make config'' i w ,,make allyesconfig'' dokładnie przez tę semantykę, którą chcesz zmienić.

Ja używam tylko takich.

To najwygodniejsze parsowanie - wykonać tylko ,,make oldconfig'' (być może najpierw robiąc jakieś ręczne zmiany w pliku .config).

Jeśli chodzi o mnie, to parsery korzystające z powłoki są jedynymi, które naprawdę się liczą. Zatem jeśli chcecie wymienić je na coś innego, to lepiej, żeby to coś innego było równie doskonałe i budowanie tego nie zabierało tyle czasu.

Wykonałem analizę zbierania i wyliczania entropii w bieżących jądrach Linuksa i znalazłem pewne istotne słabości i błędy. Ponieważ wyliczanie entropii stanowi tylko część bezpieczeństwa urządzenia generującego liczby losowe, to te usterki są do przyjęcia, co nie zmienia faktu, że poprawienie ich nie jest zupełnie pozbawione sensu.

• Wadliwa analiza rozkładu entropii
• Model delta umożliwiający oszukiwanie
• Niezależność chwil przerwań
• Ignorowanie skali czasowej źródeł entropii
• Pomieszanie nieprzewidywalnych i złożonych źródeł oraz ufanie tym ostatnim
• Wadliwe transfery pul
• Pula entropii może zostać nadpisana przez niezaufane dane

Całkowity efekt: typowa maszyna będzie zgłaszała, że generuje 2-5 _rzędów wielkości_ większą entropię niż to naprawdę robi.

Zauważcie, że wyliczanie entropii jest zwykle użyteczne dla rzeczy takich jak generacja dużych par kluczy publicznych i prywatnych, gdzie liczba bitów entropii w kluczu jest prównywalna z rozmiarem wewnętrznego stanu PRNG. Dla większości zastosowań, /dev/urandom jest ciągle bardziej niż wystarczająco silne, żeby atakowanie szyfru było bardziej produktywne od atakowania PRNG.

Następujące łatki na 2.5.31 były testowane na x86, ale powinny się bez kłopotu kompilować także gdzie indziej.

Poniżej spróbowałem opisać szczegółowo niektóre problemy:

Wadliwa analiza rozkładu entropii

(Wiem, że temat entropii jest raczej słabo rozumiany, prezentuję zatem kilka użytecznych, podstawowych pozycji dla ludzi od jądra:

Cryptanalytic Attacks on Pseudorandom Number Generators Kelsey, Schneier, Wagner, Hall www.counterpane.com/pseudorandom_number.pdf

Cryptographic Randomness from Air Turbulence in Disk Drives D. Davis, R. Ihaka, P.R. Fenstermacher http://world.std.com/~dtd/random/forward.ps)

Matematyczna definicja entropii

Dla rozkładu prawdopodobieństwa P i K próbek, entropia to:

E = sum (-P(K) * log2 P(K))

Dla rozkładu jednostajnego, gdzie dane są n bitowe, entropia wynosi n. Wszystkie rozkłady inne niż rozkład jednostajny mają entropię mniejszą niż n bitów.

Niejednostajny rozkład czasu

Niestety, źródło naszych próbek nie jest jednostajne. Na początek, każde przerwanie ma związany ze sobą skończony czas - opóźnienie przerwania. Koniec końców przerwania dadzą w efekcie próbki, które powtarzają się okresowo, z ustalonym interwałem.

A priori możemy oczekiwać, że typowe przerwanie będzie procesem Poissona, czyli będzie miało rozkład gamma. Miałoby też zerowe prawdopodobieństwo aż do pewnego minimalnego opóźnienia, największą wartość przy mimimalnym opóźnieniu reprezentującą wiarygodność kolejnych przerwań, łagodne łuki wokół średniej i nieskończony ogon.

Nie jest zaskoczeniem fakt, że ten rozkład ma mniejszą entropię niż rozkład jednostajny. Linux przyjmuje podejście, w którym zakłada się, że rozkład jest skalowalny (co jest prawdą dla rozkładów ekspotencjalnych i w przybliżeniu prawdą dla ,,ogonów'' rozkładów rodziny gamma) i że entropia próbki zależy jakoś od liczby bitów w podanej delcie przerwania.

Zakładając, że przerwanie naprawdę ma przyjemny rozkład, zbliżony do rozkładu gamma (w praktyce to raczej tak nie jest), to jest to naprawdę prawdą. Problem polega na tym, że w Linuksie założono, że jeśli delta ma 13 bitów, to zawiera 12 bitów entropii. Wystarczy chwilę pomyśleć, żeby odkryć, że liczby binarne postaci 1xxxx mogą zawierać najwyżej 4 bity entropii - tautologią jest to, że wszystkie liczby binarne zaczynają się od 1, jeśli nie bierze się pod uwagę zer na początku. To jest tak naprawdę zdegenerowany przypadek prawa Benforda (http://mathworld.wolfram.com/BenfordsLaw.html), które to prawo dotyczy rozkładu najbardziej znaczących cyfr w rozkładach skalowalnych.

To co nas obchodzi to entropia zawarta w cyfrach stojących za pierwszą 1, co możemy wyprowadzić z prostego rozszerzenia prawa Benforda (i odrobiny Pythona):

    def entropy(l):
        s=0
        for pk in l:
            if pk: s=s+(-pk*log2(pk))
        return s

    def benford(digit, place=0, base=10):
        if not place:
            s=log(1+1.0/digit)
        else:
            s=0
            for k in range(base**(place-1), (base**place)):
                s=s+log(1+1.0/(k*base+digit))
                print k,s

        return s/log(base)

    for b in range(3,16):
        l=[]
        for k in range(1,(2**(b-1))-1):
            l.append(benford(k,0,2**(b-1)))
        print "%2d %6f" % (b, entropy(l))

Co daje nam:

3 1.018740
4 2.314716
5 3.354736
6 4.238990
7 5.032280
8 5.769212
9 6.468756
10 7.141877
11 7.795288
12 8.433345
13 9.059028
14 9.674477
15 10.281286

Jak się okazuje, nasza 13-bitowa liczba ma conajwyżej 9 bitów entropii, a jak to widać, prawdopodobnie znacząco mniej.

Mając to wszystko, łatwo to zrobić przy użyciu tablicy wyszukiwania.

Niezależność chwil przerwań

Estymacja entropii w Linuksie niewłaściwie zakłada też niezależność różnych źródeł przerwań. SMP wszystko komplikuje, to jednak nie jest głównie to. Przerwania o niskich priorytetach muszą czekać na te o wysokich, a kolejne przerwania, które coś dzielą między sobą, ustawią się w końcu w formie ABABABAB. Co więcej, powszechne w systemie CLI, czyszczenie cache i podobne, pozmieniają -wszystkie- czasy i spowodują, że ułożą się one w przewidywalny sposób.

Co więcej, to wszystko jest obserwowalne z przestrzeni użytkownika, w taki sam sposób w jaki mierzone są opóźnienia w przypadku pesymistycznym.

Żeby zabezpieczyć się przed kolejnymi pomiarami i obserwacją z przestrzeni użytkownika, wymuszamy przynajmniej jedno przełączenie kontekstu między poszczególnymi zaufanymi próbkami.

Wątpliwe źródła i skale czasowe

Ze względu na kapryśne architektury komputerów, rzeczy takie jak przerwania klawiatury i myszki następują w zależności od ich skanowania lub granic zegara szeregowego i ich czas jest relatywnie wolno mierzony. Co gorsza, urządzenia takie jak klawiatury, myszy i dyski na USB posługują się tymi samymi przerwaniami i prawdopodobnie ustawiają się równo w okolicach ograniczenia zegara USB. Nawet przerwania PCI mają ziarnistość rzędu 33MHz (albo gorszą, zależną od konkretnego adaptera), która, mierzona przez szybki, 2GHz zegar procesora sprawia, że dolne sześć bitów pomiaru czasu jest przewidywalne.

Z tego, co udało mi się znaleźć wynika, że nikt nie próbował stworzyć dobrego modelu albo estymatora prawidziwej entropii klawiatury czy myszki. Losowość wywoływana przez turbulencje talerza dysku została zmierzona i jest rzędu 100 bitów na minutę i jest dobrze skorelowana z czasem mierzonym w sekundach - wydaje się więc, że ją przeceniamy.

Możemy sobie z tym poradzić deklarując dla każdego zaufanego źródła własną rozdzielczość zegara i usuwając nadmiarowe bity w trakcie przygotowywania próbek.

Ufanie przewidywalnym i mierzalnym źródłom

Entropia pobierana z czasu dysku może ,,przeciekać'' przez natychmiastowe przekazywanie danych do sieci, powłoki albo klienta X. Co więcej, wzory przesuwania się głowicy dysku mogą być zdalnie sterowane przez klientów rozmawiających z serwerami plików czy www. Zatem, choć czasy dyskowe mogą być atrakcyjnym źródłem entropii, to nie mogą być nieostrożnie używane w typowym środowisku serwera.

Złożoność analizy źródeł ,,czasowych'' nie powinna być mylona z nieprzewidywalnością. Zapisywanie do cache dysku nie ma żadnej etropii, ruchy głowicy dyskowej mają pewną entropię tylko dlatego, że wytwarzane są turbulencje. Ruch w sieci jest potencjalnie w pełni obserwowalny.

(Nawiasem mówiąc, sztuczki takie jak techniki dryfu Matta Blaze prawdopodobnie nie zadziałają na większości współczesnych PC, bo źródło zegara ,,czasu rzeczywistego'' jest często wyprowadzane bezpośrednio z zegara magistrali/PCI/pamięci/procesora.)

Jeśli będziemy ostrożni, to wciąż możemy używać tych czasów do przesiewania naszego RNG, tak długo jak nie uważamy tego za źródło entropii.

Batching

Próbki do mieszania są trzymane w cyklicznym buforze o 256 elementach. Ponieważ tego bufora nie można ,,nawinąć'' na siebie, to niebezpieczne jest trzymanie niezaufanych próbek, bo mogą one wyprzeć te zaufane.

Możemy dopuścić, żeby niezaufane dane były bezpiecznie dodawane do pul przez wykonywanie XOR na nowych próbkach zamiast kopiowania i umożliwienia ,,zawijania się'' pul. Ponieważ nielosowe dane nie będą skorelowane z losowymi, takie pomieszanie nie zepsuje entropii.

Wadliwy transfer pul

Najgorsze jest to, że wyliczanie transferów entropii pomiędzy pierwotnymi a drugorzędnymi pulami od jakiegoś czasu jest zupełnie zepsute i wypuszcza w powietrze tysiące bitów entropii.

Z drugiej strony, jeśli jesteś _zbyt_ analizujący, to nie znajdziesz _nic_ ,,naprawdę losowego'', a /dev/random staje się praktycznie bezużyteczny w miejscach, w których niedostępny jest specjalny sprzęt gwarantujący losowość.

Z twojego opisu to dla mnie wygląda, że masz szansę być na krawędzi bycia ,,zbyt analizującym''. _Należy_ wziąć pod uwagę prawdziwe życie, a nieakceptowanie entropii ze względu na teoretyczne przeszkody _nie_ jest dobrym pomysłem.

Całkiem szczerze, wolałbym mieć użyteczne /dev/random niż takie, które działa tak szybko, że nie ma sensu używanie go do rzeczy takich jak generowanie 4096 bitowych kluczy dla sshd itp.

W szczególności, jeśli maszyna musi generować silne liczby losowe, a /dev/random może dać taką liczbę tylko raz dziennie, bo odmawia używania rzeczy takich jak bity z TSC czy pakietów sieciowych, to /dev/random nie jest w takiej sytuacji użyteczne w praktyce.

Teoria jest teorią, a praktyka praktyką. Teoria powinna być używana do analizowania praktyki, ale nigdy, PRZENIGDY nie powinna stanowić najważniejszej troski.

Zatem proszę, napisz jeszcze wywód, który przekona nas, że Twoje łaty są _praktyczne_. W innym przypadku ich nie nałożę.

Pozwól mi wyjaśnić te 2-5 rzędów wielkości. Jądro ufa około 10 razy więcej próbkom niż powinno i przecenia entropię każdej próbki mniej więcej 10 razy (na x86 z TSC) lub 1.3 (gdy używa się 1kHz jiffie).

5 rzędów pojawia się, gdy pula się wyczerpie i funkcja xfer magicznie produkuje 1024 bity albo i więcej następnym razem, gdy pojawi się bit entropii (lub .1 lub 0 bity entropii, patrz wyżej).

Hmm.. Po dokładniejszym przeczytaniu, wydaje mi się (jeśli dobrze zrozumiałem), że ponieważ ruchu w sieci nie uważamy -w-ogóle- za zaufane źródło, to przeciętna maszynka na ruter / ścianę ogniową / xxx _nigdy_ nie uzyska żadnego wyniku z /dev/random. Zupełnie niezależnie od problemu z przełączaniem kontekstu, ponieważ to jest tylko przełącznikiem zaufanych źródeł. Zatem to jest nawet bardziej drakońskie niż tego oczekiwałem.

Na serio mówisz, że TSC uruchamiane z częstotliwością gigahertza nie może być uważane za coś zawierającego losową informację tylko dlatego, że uważasz, że można łatwo z zewnątrz określić czasy ruchu sieciowego?

Oliver, naprawdę myślę, że ta łatka (która z drugiej strony wygląda świetnie) jest po prostu nierealna. Są _realne_ powody dla których komputer będący zaporą ogniową (to znaczy taki, który prawdopodobnie ma flash dysk i uruchamiany jest na nim mały serwer www do konfiguracji), chciałby mieć silne liczby losowe (w celu rzeczy takich jak generowanie kluczy komputera na żądanie administratora), a w tej sytuacji wynika, że taki użytkownik musiałby używać /dev/urandom.

Jeśli dobrze przeczytałem łatkę, uważasz taką maszynkę za zupełnie ,,niezaufane'' źródło losowości i w tej sposób zero bitów informacji w /dev/random. Taki komputer oczywiście nie będzie miał klawiatury ani podobnych rzeczy.

To jest absurdalne.

Obecna polityka mówi, żeby nie ufać zdarzeniom nad którymi dokładnie nie panujemy. Oliver w ogóle nie zmienił tej polityki sieciowej.

Prawdopodobnie jest prawdą, że mniej bitów losowości jest dostępnych z takich źródeł, przy założeniu, że wiemy, że maszyna ma tsc, no chyba że czas APIC WE/WY jest mierzony z dokładnością będącą dzielnikiem zegara procesora, w którym to przypadku zachowanie danego źródła jest prawdopodobnie rozsądniejsze.

Bądź realistą. O to Cię proszę. Chcemy mieć bezpieczeństwo w _realnym_świecie_, nie coś, co można określić jako ,,przykład wymyślony dla NSA, który jest bezużyteczny dla kogokolwiek innego''.

Wszystkie twoje argumenty sprowadzają się do stwierdzenia, że ,,ludzie nie powinni w ogóle używać /dev/random, a powinni używać /dev/urandom''.

Co jest po prostu niedorzeczne.

Od czasu gdy posiadam P4 i używam jego obsługi, uzyskuję hyperthreading dla 2.4.19 (CONFIG_MPENTIUM4=y). W wersji 2.4.18 musisz także bezpośrednio podać parametr dla lilo - acpismp=force.

Możesz chcieć także rozdystrybuować dostępne przerwania pomiędzy procesory. Ingo Molnar napisał w tym celu łatkę, którą umieściłem na http://www.hardrock.org/kernel/.

hyperthreading zwiększy nieco wydajność systemu, lecz *jedynie* wtedy, gdy przez większość czasu posiadasz działające procesy lub wtedy, gdy są uruchomione ,,mocno wątkujące'' aplikacje. (przykładem może być odpalenie czterech procesów setiathome na dwuprocesorowym systemie).

To jest obecnie prawdą, lecz, jak sądzę, Intel planuje wypuszczenie obsługujących HyperThreading biurkowych wersji P4.

Jeżeli chcecie poznać możliwości obsługi HT przez konkretny procesor, to powinniście odczytać cpuid 1 i sprawdzić bity 16-23 rejestru ebx.

Istnieją interesujące spekulacje nt. tego, czy da się włączyć HT poprzez nieudokumentowane mtrr na procesorach, które mają HT, lecz raportują, że nie jest on używany. Wiadomo, że ta zwrócona wartość musi gdzieś być ustawiana, lecz nie mam, jak dotąd, żadnych dowodów na to, iż można uaktywnić w ten sposób HyperThreading na procesorach innych niż PIV Xeon.

Linus, czy mógłbym Cię prosić o włączenie łatek uaktualniających ALSĘ do najnowszej wersji do 2.5:

Łatka bez dodatków:
------------

ftp://ftp.alsa-project.org/pub/kernel-patches/alsa-1.489.1.1.patch.gz
ftp://ftp.alsa-project.org/pub/kernel-patches/alsa-1.501.patch.gz

Format send/receive interfejsu BK (zawiera ładne ,,komentarze/listy zmian'' dla każdego pliku):
---------------------------------------------------------------------

ftp://ftp.alsa-project.org/pub/kernel-patches/alsa-1.489.1.1.bk.gz
ftp://ftp.alsa-project.org/pub/kernel-patches/alsa-1.501.bk.gz

repozytorium BK dla linux-sound
-------------------------

bk pull http://linux-sound.bkbits.net/main

Zestawy zmian: 1.489.1.1 oraz 1.501

Strona WWW: http://linux-sound.bkbits.net

Opis ------------

Wersja ALSY 0.9.0rc3

* poprawki dla x86-64
* poprawiony wrapper ioctl32
* usunięto definicje __NO_VERSION__, używane dla zachowania zgodności
* Cały kod zawiera inicjalizatory struktur w formacie C99
* Interfejs kontrolny
  - poprawiono zachowanie read()
* Interfejs PCM
  - obsługa większej liczby formatów PCM (do 512)
    - dodano 24-bitowy format dla USB_audio
	- usunięto oczyszczającą funkcję z funkcji snd_pcm_close(),
	  dane są zawsze ignorowane
    - dodano wsparcie dla SBUS DMA - stworzone przez Davida S. Millera <davem@redhat.com>
* Interfejs zegarów
  - poprawione zachowanie kmod dla systemowych zegarów
  - poprawiona implementacja read()
* Interfejs RawMidi
  - poprawiona obsługa read()
* Interfejs sekwencera
  - wyzerowanie zegara przy instrukcji ,,continue'', jeżeli nie został wcześniej zainicjalizowany
  - sprawdzenie ewentualnych, ,,nieskończonych'' pętli w kolejkach priorytetów
  - usunięcie ,,zakleszczeń'' w snd_seq_timer_start/stop
* sterownik intel8x0
  - poprawione pci id dla AMD8111
* sterownik via686
  - obsługa DMA Scatter-Gather
  - poprawiona inicjalizacja kodeka AC97
* sterownik opti92x/93x
  - różne poprawki
* sterownik via8233
  - poprawione odgrywanie próbek mono
  - obsługa DMA Scatter-Gather
* sterownik EMU10K1/Audigy
  - obsługa DMA Scatter-Gather dla odgrywania
  - ,,obejście'' dla nagrywania (wskaźnik bufora ring)
* sterownik NM256
  - usunięte ,,zawieszanie się'' w NM256 ZX (Dell Latitude Cpt)
* sterownik CS46xx
  - obsługa nowych obrazów DSP
  - eksperymentalna obsługa tylnego i cyfrowego wyjścia dźwięku
* dodane sterowniki snd-usbaudio i snd-usbmidi
* sterownik ymfpci
  - poprawione odczyt/zapis GPIO
  - dodano opcję snd_rear_switch
* sterownik ice1712
* usunięte ,,zakleszczanie się'' na maszynach SMP (kod CS8427 I2C)
* sterownik HDSP
  - różne poprawki w kodzie
* sterownik CS4236
  - nowe ISA PnP ID
* sterownik CS4281
  - dodano obsługę mocy karty
* PPC Keywest
  - poprawiono inicjalizację sterownika
* serial-u16550
  - dodano obsługę przyszłych urządzeń
* zmiana nazwy sterownika dt0197h na dt019x
* kod ac97
  - dodano kodeki Conexant i VIA
  - dodano kodek AD1981A z Analog Devices
  - dodano parametry id dla układów ITE
  - oddzielony, specyficzny dla kodeka, kod inicjalizacji

Wewnętrzny debuging ext3 zawsze zakładał, że nie można zrównoleglać zadań WE/WY na początku bufora, który starał się modyfikować. To wydaje się rozsądne -- jeżeli zaistnieje konflikt WE/WY, wszystko kończy się dostępem do popsutego dysku z dziennikiem zdarzeń, tracimy więc gwarancję odtworzenia poprzedniego stanu.

Jednakże istnieją dwa przypadki, gdy taki stan zaczyna graniczyć z nadgorliwością. Jeżeli w przestrzeni użytkownika wykonujemy dziedziczone ,,zapisy'', nie powiązane w transakcje zapisy (np. tune2fs dodający etykietę do aktywnego systemu plików i zapisujący na buforowane urządzenie pozycję superbloku) możemy pozbyć się asercji ext3.

Tak bardziej serio, to powodem jest to, że od 2.4.11 buforowanie stron potrafi zablokować buffer_head dla zapisu, nawet wtedy, gdy bh jest już pod kontrolą journalingu. Błąd w tune2s ujawnia się bardzo rzadko: nie ma na jego temat raportów ani na Bugzilli, ani na liście użytkowników ext3. Jedyny taki przypadek odnotowaliśmy na liście dotyczącej jądra 2.5. Lecz obecnie, dump(8) na aktywnym systemie plików może prowadzić do tych samych przypadków. Podczas testowania, uruchamianie dump + fs powoduje BARDZO częste błędy asercji.

Łatka ta podmienia kod get-write-access dla jbd, która zakłada blokadę na buffer_read przed sprawdzaniem uaktualnionego i ,,pobrudzonego'' bh oraz odblokowuje obsługę niespodziewanie ,,pobrudzonych'' buforów tak, aby było to raportowane poprzez printk i nie kończyło się fatalnym błędem. Blokada ta naprawia interackcję z dump(8), a ostrzeżenie mówi, że zdarzą się jeszcze ,,niedziałające'' operacje zapisu bez unieruchamiania całego jądra systemu, jeżeli koliduje to z tune2fs(8).

Łatka ta także usuwa potencjalne zagrożenie w obsłudze naprawy systemu plików. Nie jest bezpiecznym ,,podkradanie'' buforów z trybu checkpoint, aż do czasu, gdy transakcja zostanie wykonana. Inaczej reset w nieodpowiednim momencie może doprowadzić do tego, że stara kopia bufora związana z trybem journalingu zostanie usunięta usunięta z zestawu, na którym dokonywana jest naprawa, przed zapisem nowej kopii.

Rozdzieliłem sterownik, tworząc działające jego wersje dla 2.4.19 i 2.5.31 (a nawet je przetestowałem) oraz przerzuciłem kod emulacji do osobnej łatki.

Zauważyłem także, że przerwania licznika w 2.5.31 występują co 1ms, zamiast co 10ms, więc powinno to dostarczyć akceptowalną szybkość, bez liczników pracujących w trybie wysokiej rozdzielczości. 2.4 bez liczników pracujących w tym trybie i bez przerwań nadal będzie bardzo wolne.

Jeszcze nie testowałem wersji z przerwaniami, ponieważ nie posiadam karty, która je obsługuje (jest już w drodze). Jakkolwiek jest to całkiem oczywiste.

Strona WWW: http://home.attbi.com/~minyard

Proszę, wypróbujcie to i powiedzcie, co o tym sądzicie. I znów, nalegam, aby włączono to do głównej linii rozwojowej jądra.

to jest moja pierwsza próba stworzenia łatki dla jądra i mam nadzieję, że zrobiłem to bez błędów; jeżeli nie, po prostu mi powiedzcie. (wysyłam łatkę zarówno na listę progamistów drm jak i na listę pocztową ,,linux-kernel''. czy powinienem wysyłać łatki dla 2.4 bezpośrednio do marcelo? mm..)

w każdym razie, jest to wersja sterownika DRM z jąder 2.5 układu Intel 830M dla jąder serii 2.4. Jest ona przeznaczona dla 2.4.19, lecz, składając się jedynie z dodanych plików, powinna działać i na tych późniejszych (testowane na 2.4.20pre). Łatka jest całkiem spora (67252 bajtów) i może być ściągnięta z:

http://people.initd.org/fog/linux-2.4.19-i830.diff

Proszę, nie rób tego. Kod 2.5drm jest stekiem bzdur, bardziej zepsutym, niż to w 2.4.

Alan, czy istnieje szansa, że podeślesz marcelo kod drm z linii -ac?

Podesłałem łatkę, która uaktualnia główny kod drm do wersji z -ac, poprawia wszystkie ostrzeżenia kompilatora i usuwa pozostałe jeszcze testy na obecność LINUX_VERSION_CODE, po tym, jak większość z nich została usunięta z -ac.

Jest na: http://verein.lst.de/~hch/misc/linux-2.4.20-pre4-drm.patch

Nie, nie przechodzimy na GPL, ale robimy parę zmian i chcieliśmy się upewnić, że w oczach użytkowników korzystających darmowo z BK, jest to poprawa, a nie krok w tył. Wybaczcie to wtargnięcie, wyjaśnię wszystko tak krótko, jak to tylko możliwe.

Nową licencję można znaleźć pod adresem: http://www.bitkeeper.com/bkl.txt, ale zmiany streszczę poniżej.

3(a) Propagacja na openlogging.org. Stara licencja nalegała, żeby każdy logował swoje zmiany w ciągu 7 dni; parę osób zwróciło uwagę, że wydaje swoje dolary zarobione na dotcomach siedząc gdzieś na wyspie hakując jądro i nie mają połączenia ze światem co 7 dni. Czy coś w tym stylu. Podnieśliśmy tę granicę do 21 dni, co powinno wystarczyć, muszę wierzyć w to, że sprawdzacie pocztę co trzy tygodnie, jeśli naprawdę pracujecie.

3(c) Opieka nad Open Source. Możliwość darmowego użycia BitKeepera przewidzieliśmy w celu pomocy społeczności open source; nie po to, żeby dostarczyć użytkownikom komercyjnym darmowego produktu. Mieliśmy pewną liczbę przypadków, w których menedżerowie, nawet bardzo wysokiego szczebla, radzili swoim inżynierom, żeby ,,po prostu nie umieszczali niczego użytecznego w komentarzach, a wtedy będzie można używać tego za darmo''. Nie to mieliśmy na myśli. Dodajemy więc klauzulę, w której zastrzegamy sobie prawo do naciskania, żeby upublicznić repozytoria w ciągu 15 dni od takiego żądania.

Rozumiemy, że wielu prawowitych użytkowników open source ma bardzo dobre powody, żeby nie chcieć ujawniać swoich zmian, na przykład gdy pracują nad poprawkami bezpieczeństwa. Nie mamy zamiaru zmuszać tego typu repozytoriów do otwarcia, a jeśli się tego obawiacie, to możemy wypracować pewne porozumienie rozwiązujące ten problem. Bardzo nam zależy na wspieraniu rozwoju produktów open source, w szczególności jądra Linuksa, a dokładniej Linusa, bo to on jest zasobem krytycznym.

Jedyni ludzie, których chemy ścigać to ci, którzy w oczywisty sposób nie są częścią społeczności open source. Myśleliśmy o zapisie, który wymuszałby to w przypadku pracy nad źródłami, które nie mają licencji open source, ale odrzuciliśmy takie myślenie z następującego powodu: istnieją komercyjne firmy, które pracują nad open source używając do tego BitKeepera, które jednak nie dzielą się swoją pracą tak długo jak tylko mogą, żeby osiągnąć maksymalną konkurencyjność na rynku. Z punktu widzenia warunków GPL nie ma w tym nic złego, ale my nie chcemy za darmo wspierać czegoś, co z naszego punktu widzenia jest działalnością komercyjną. Naszym zdaniem otwarte oznacza otwarte w sensie dzielenia się, nie pobierania pieniędzy.

To twardy orzech do zgryzienia, nie można powiedzieć po prostu ,,to jest za darmo jeśli wszystko otwierasz'', bo istnieją uzasadnione przyczyny ukrywania niektórych rzeczy. Istnieją także komercyjne powody ukrywania, a naszym zdaniem, jeśli to jest właśnie to co robisz, to powinieneś płacić za narzędzia. BK jest darmowy jako sposób pomocy ludziom, którzy pomagają innym.

4.4. Usunęliśmy klauzulę o $20,000 za obsługę. Klauzula ta mówiła, że możemy zamknąć repozytorium jeśli jego obsługa kosztuje nas więcej niż $20K. Spotkała się ona z powszechną nienawiścią i mamy tego świadomość. Zostawiliśmy ją, żeby mieć sposób na tych, którzy prowadzą prawdziwie komercyjną działalność. Ponieważ poprzednia poprawka zmienia sytuację, to nie potrzebujemy klauzuli. Dzięki temu pozbyliśmy się strachu przed zamknięciem bkbits, czy użycia BK w rozwoju jądra.

Tyle na temat licencji. Skoro już tu jestem, oto trochę rzeczy na temat stanu BK.

Jesteśmy w trakcie rozmów z pewnym bardzo przyjaznym Linuksowi serwisem (który utrzymuje 4000 serwerów Linuksowych), żeby przesunąć bkbits.net i openlogging.org do nich w zamian za licencje BK. To powinno dołożyć pasma bkbits.net i dać korzyści w postaci świetnego łącza i świetnie zarządzanego środowiska. Nie potrzebujemy pasma, BK jest dość skąpy jeśli chodzi o używanie pasma, ale fajnie by było mieć bkbits.net w klimatyzowanym, UPS-owanym, środowisku z wieloma źródłami zasilania, zamiast w moim biurze. Mamy na tym punkcie lekkiego świra, to dobra rzecz.

Pracujemy nad zamknięciem pierwszej komercyjnej umowy, którą możemy związać z używaniem BK przez drużynę jądra. Jeśli to się naprawdę uda, to wezmę $25K z tej umowy i ,,dam'' je Linusowi w charakterze ,,BK dolców'', które będzie mógł wydać. Co oznacza, że będzie miał $25K na to, co będzie chciał mieć w BK. To jest ponad i poza rzeczami, które już robimy, to pewien sposób, w który damy mu moc oddziaływania na nas, żebyśmy wykonali jakąś pracę, której w innym wypadku byśmy nie zrobili. Ogólnie, chciałbym żeby takie rzeczy odbywały się według jakiegoś schematu. Do tej pory nie możemy mówić, że BK jest używany w jakimś komercyjnym przedsięwzięciu dzięki open source. Jeśli to się zmieni, to dobrze dla nas, ale też dobrze dla jądra.

Mam pewną prośbę. Możliwość oglądania zbiorów zmian na bkbits jest użyteczna, ale sortowanie nie daje pełnego obrazu.

Oto przykład:
bk pull http://linux.bkbits.net/linux-2.5

• Edytowanie czegoś
• Wprowadzenie zmian
• Kilkudniowe testowanie zmian
• Przesłanie csetów Linusowi

Linus robi bk pull z mojego repozytorium

Przy dostępie do bkbits przez interfejs webowy, zmiany są podawane w porządku określonym przez czas dokonania modyfikacji, a nie czas wykonania bk pull przez Linusa, zatem moje zmiany mogą być poprzedzone przez być może 100 csetów.

Czy jest jakoś możliwe sortowanie csetów zgodnie z czasem, w którym były nałożone na lokalne drzewo, a nie czasem, gdy były wprowadzone do repozytorium?

Jeśli to jest właśnie to czego chcesz, to robimy to:

Zamiast oglądać zdarzenia w porządku ich stworzenia, chcesz je widzieć w porządku określonym przez ich przybycie do konkretnego repozytorium.

Zgadzam się, że obecny sposób prezentacji jest bezużyteczny, jeśli chcesz się dowiedzieć, kiedy poprawka w końcu trafiła do drzewa.

Pracujemy nad ,,stosem'' przybywających zdarzeń. BK/Web będzie tego używać, żeby dać Ci takie wyniki jakich oczekujesz, a bk undo będzie mogło tego używać, żeby odtwarzać stare repozytoria przez wykonywanie ,,pop'' na stosie. Będziesz mógł zrobić:

        while true
        do      bk undo -sf
        done

a gdy to się skończy, nie będzie żadnego repozytorium, bedzięsz miał wszystkie elementy zdjęte ze stosu. bk unpull stanie się specjalnym przypadkiem wykonywania operacji zdejmowania elementu ze stosu.

Właśnie odpaliłem kilka testów ,,dbench'' na:

• 2.4.18
• 2.4.18 + skompresowana pamięć podręczna -0.24pre3
• 2.4.19
• 2.5.31

Ok, wiem, że dbench nie jest ,,dobrym'' testem, lecz jest przynajmniej dobrym testem obciążenia. Nie uzyskałem żadnych oopsów, ni BUG()ów.

Każdy test był przeprowadzany dwa razy Tutaj są wyniki:

2.4.18
Istances Throughput
8        25.1022
16       20.3833
24       18.0078
32       13.6657

2.4.18 -0.24pre3 (64MiB skompresowana pamięć podręczna)
Istances Throughput
8        28.5116
16       27.5003
24       24.6963
32       16.423

2.4.19
Istances Throughput
8        25.5343
16       20.7133
24       16.2473
32       14.2351

2.5.31
Istances Throughput
8        30.6827
16       18.2236
24       14.6759
32       12.7659

Alan Cox zaakceptował moją ostatnią łatkę poprawiającą ostrzeżenie analizatora, ale nie moją wcześniejszą łatkę naprawiającą oopsa w khttpd.

Ta poprzednia musiała trafić na jakiś fitr przekłamań... hmm. Tak. Zawierała niezwiązane z resztą poprawki wcięć i stylu, była złożona i słabo opisana. Przedstawiam więc wyczyszczoną jej wersję, z lepszym opisem.

Łatka rozwiązuje cztery problemy w khttpd:

1. Oops w DecodeHeader gdy Buffer[CPUNR] było NULL, zdarzał się za każdym razem, gdy wątek roboczy był restartowany po zatrzymaniu. (Wątek roboczy zwalnia swój bufor przy wyjściu, ale wątek zarządzający pomijał alokowanie bufora dla wątku roboczego przy ponownym uruchamianiu.)
2. Błąd, który powodował, że wątek roboczy był bez sensu restartowany od razu na początku (co powodowało, że poprzedni błąd był znacznie poważniejszy).
3. Użytkownik końcowy musiał wykonywać ,,sleep 1'' po zatrzymaniu demona, zanim go uruchomił ponownie. Ta cecha nie była udokumentowana i raczej myląca.
4. W /usr/src/linux/Documentation nie istniała pozycja dla khttpd i początkujący użytkownicy czasem nie mogli znaleźć dokumentacji.

(Wcześniejsza wersja, która naprawia tylko pierwsze dwie rzeczy jest dostępna pod adresem http://marc.theaimsgroup.com/?l=linux-kernel&m=102068445316516&w=2 ) Mogę podzielić tę łatkę na trzy lub cztery kawałki, jeśli jest taka potrzeba.

Dajcie mi proszę znać, jeśli łatka się przyblokuje na jakimś filtrze przekłamań...

Większość tej pracy wykonał Jens Axboe; ja jedynie trochę to potestowałem i naprawiłem kilka błędów. Ponieważ Jens jest teraz na wakacjach, chciałem Wam to przedstawić i poprosić o komentarze.

Kompiluje się i przechodzi przez mój skrypt testowy, więc mam nadzieję, że nie spieprzyłem tego całkowicie ;-) Na pewno nie jest gorsze niż obecny kod.

Stworzyłem także małą łatkę na mdadm, która pozwala na dostęp do nowej funkcjonalności.

Usprawnienia obejmują:

• Rozkładanie pisania & czytania z łączeniem żądań od przodu i od tyłu, w przeciwnym przypadku brana jest ostatnio używana ścieżka. (Zrobione przez Jensa)
• Ścieżki mogą być aktywne lub wolne; wolna ścieżka zostanie użyta w miejsce zepsutej aktywnej ścieżki, w przeciwnym wypadku będzie jednak wyłączona.

• Ścieżka może zostać ręcznie ,,wyczyszczona'' (zaznaczona jako niezepsuta). To jest zaimplementowane jawnie tylko dla multipathing, bo nie ma sensu dla innych poziomów RAID, w których jest to bez wątpienia zadanie procesu odtworzenia.

  Automatyczne ponowne sondowanie nieudanych ścieżek zostało rozmyślnie niezaimplementowane; to można zrobić w przestrzeni użytkownika, a jądro nie powinno używać takich żądań w takim celu.

• Niektóre specjalne przypadki w md.c dla multipath zostały usunięte / naprawione.
• md będzie teraz włączało wszystkie ścieżki, które znajdzie podczas automatycznego działania. Prowadzi to do tego, że pojawiają się ,,zabawne'' komunikaty (,,Device changed to [07:04] from [00:00]'' itp), ale można je spokojnie ingorować.

• Zagnieżdżone urządzenia md są teraz także wykrywane automatycznie; ważne na przykład dla RAID1 umieszczonego ponad multipath, wymagane dla prawdziwie strasznie elastycznych konfiguracji Jednakże to jeszcze nie działa doskonale i jest przedmiotem wciąż trwających prac ;-)

  (Jeśli ktoś ma tu jakieś uwagi, byłbym wdzięczny)

• Ubiłem część kodu, która nie miała zastosowania w module multipath; to znaczy, kodu związanego z odtwarzaniem md.
• Złe strony: Żeby to zrobić potrzebowaliśmy 3 dodatkowych ioctl()i.

Załączam łatkę.

Oczywiście wciąż całość jest przedmiotem ogólnych komentarzy na temat obsługi błędów urządzeń blokowych w 2.4.

Załączona mała łatka zezwala urządzeniu loop ,,padać'' na żądanie. Każde kolejne żądanie wysłane do urządzenia loop po prostu się nie powiedzie.

Chociaż to oczywiście nie symuluje padów, które mogą się zdarzyć w trakcie normalnego działania, może to być użyteczne przy automatycznych testach, na przykład testach multipath WE/WY.

Zrobione przez Jensa Axboe. Przyczyna, dla której ja to wysyłam: głównie mi jest to potrzebne, a on jest na wakacjach.

Pan Daniel Phillips jakiś czas temu rozpoczął projekt systemu plików TUX2. Odnośniki do 'tux2' są albo niedziałające albo dość stare.

Czy któryś z deweloperów jądra wie coś o stanie tego projektu?

Projekt jest na końcu mojej listy priorytetów ze względu na niepewności wynikające z systemu patentowego Stanów Zjednoczonych.

Czy ktoś chce wiedzieć, czy zagrożenie patentami istnieje i krzywdzi open source? Odpowiedź brzmi tak.

Podejrzewam, że Daniel odnosi się do sprawy NetApp/WAFL. System plików WAFL NetApp (ZTCP) implementuje coś co ma taką trochę jakby, po przymrużeniu oka, filozofię podobną do drzew fazowych tux2. Tylko, że:

1. *Naprawdę* nie jest to takie podobne
2. Daniel był pierwszy, już w latach 80-tych
3. NetApp zatrudnia większą liczbę prawników niż Daniel

Daniel, czy mam mniej więcej rację?

Właśnie zrobiłem z najnowszych Linuksowych skryptów hotplug jedną paczkę, którą umieściłem pod adresem:

http://sourceforge.net/project/showfiles.php?group_id=17679

Można też ją ściągnąć z ulubionego serwera lustrzanego kernel.org:

kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2002_08-26.tar.gz

Zrobiłem też rpma dla Red Hata 7.3:

kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2002_08-26-1.noarch.rpm

rpm ze źródłami jest też dostępny, jeśli chcesz go zbudować dla innych dystrybucji. Można go pobrać z adresu:

kernel.org/pub/linux/utils/kernel/hotplug/hotplug-2002_08_26-1.src.rpm

Główna strona projektu linux-hotplug znajduje się pod adresem:

http://linux-hotplug.sf.net/

i zawiera sporo dokumentacji na temat całego procesu linux-hotplug. Są tam także odnośniki do łat na jądro nie znajdujących się w głównym drzewie, które dodają funkcjonalność hotplug do nowych podsystemów (takich jak CPU, SCSI, pamięć, itp.)

Główne zmiany w tej wersji są następujące:

• poprawka w USB hotplugging włączająca przeszukiwanie /etc/hotplug/usb/*.usermap

Oto zmiany (i ich autorzy) z ostatniej wersji:

Zmiany Davida Brownella

• load_drivers(): zmienne są lokalne i nie ma próbowania usbmodules, chyba, że istnieje plik $DEVICE (nie udawałoby się)
• uaktualnienie podręcznika hotplug.8 tak, żeby wspominała łatkę Maxa
• łatka Maxa Krasnyanskijego, teraz usb hotplugging przeszukuje także /etc/hotplug/usb/*.usermap

Zmiany Fumitoshi UKAI

• etc/hotplug/hotplug.functions: grep -q przekierowane do /dev/null zamyka to: debian Bug#145484

symetryczna wielowątkowość (hyperwątkowość) jest bardzo interesującym nowym pomysłem, który moim zdaniem zasługuje na pełną obsługę w schedulerze. Fizyczne procesory mogą mieć wiele (typowo: 2) zanurzonych logicznych procesorów i mogą uruchamiać wiele zadań 'równolegle' używając szybkiego sprzętowego przełączania kontekstu pomiędzy dwoma zbiorami rejestrów, nie bacząc na takie rzeczy jak brakujące cache czy specjalne instrukcje. W systemie operacyjnym logiczne procesory są prawie nieodróżnialne od fizycznych. Tak naprawdę, obecny scheduler traktuje każdy logiczny procesor jak pojedynczy fizyczny, co działa, ale nie maksymalizuje wydajności wieloprocesowości na maszynkach SMT/HT.

Scheduler, który chce być ,,w pełni świadomy HT'' (ang. HT - skrót od HyperThreading), musi mieć następujące własności:

• Pasywne rozkładanie obciążeń w uwzględnieniem HT: rozkład obciążeń sterowany przerwaniami powinien odbywać się przez fizyczny procesor, a nie per logiczny.

  W przeciwnym wypadku może się zdarzyć, że na jednym fizycznym procesorze działają dwa zadania, podczas gdy inny fizyczny procesor nie obsługuje żadnego wątku. Normalny scheduler nie rozpoznaje takiej sytuacji jako 'niezrównoważenia' - schedulerowi wydaje się, że na dwóch pierwszych procesorach jest po jednym zadaniu, a na dwóch kolejnych nie ma żadnych. Zwykły scheduler nie ma świadomości tego, że dwa logiczne procesory należą do tego samego fizycznego.

• 'aktywne' rozkładanie obciążenia, gdy logiczny procesor przechodzi w tryb jałowy, które powoduje niezrównoważenie fizycznych procesorów.

  To jest mechanizm, który po prostu nie istnieje w normalnym schedulerze, który jest 1:1 - niezrównoważenie spodowane jałowym procesorem może być rozwiązywane przez normalną obsługę rozkładania obciążeń. W przypadku HT sytuacja jest specjalna, bo na źródłowym fizycznym procesorze mogą na raz być uruchamiane dwa zdania, oba działające - to jest sytuacja, której normalne rozkładanie obciążeń nie będzie umiało obsłużyć - działające zadania niezwykle trudno przenieść gdzie indziej. Ale to jest konieczne - w innym wypadaku fizyczny procesor może zostać z dwoma zadaniami działającymi na nim, podczas gdy drugi fizyczny procesor pozostaje jałowy.

• Pobieranie zadań do wykonania z uwzględnieniem HT.

  Gdy scheduler zaczyna się zajmować nowym zadaniem, to powinien woleć mieć wszystkie zadania na tym samym fizycznym procesorze, zanim zacznie próbować wyciągać zadania z innych procesorów. Zwykły algorytm szeregujący bierze tylko zadania przypisane do konkretnego logicznego procesora.

• Afiniczność z uwzględnieniem HT.

  Zadania powinny próbować ,,przyklejać się'' do fizycznych, nie logicznych, procesorów.

• Budzenie wątków z uwzględnieniem HT.

  to jest kolejna zupełnie nowa rzecz - zwykły scheduler zna tylko 'aktualny' procesor, nie wie nic o rodzeństwie [== logicznych procesorach na tym samym fizycznym] logicznych procesorów. W HT, jeśli wątek jest budzony na logicznym procesorze, który już wykonuje zadanie, a procesor-brat jest jałowy, to procesor-brat musi być obudzony i natychmiast nowo obudzone zadanie.

załączona łata (na 2.5.31-BK-curr) implementuje wszystkie powyższe wymagania schedulingu z HT: wiele procesorów może mieć tę samą kolejkę wykonywanych zdań. Taka dzielona kolejka, oddzielna dla każdego fizycznego procesora, magicznie spełnia wszystkie powyższe wymagania odnośnie szeregowania z HT. Oczywiście to w pewien sposób komplikuje szeregowanie i wyrównywanie obciążeń (aby poznać szczegóły obejrzyj łatkę), zatem trzeba to robić bardzo ostrożnie, tak żeby nie wpłynąć źle na schedulery nie używające HT (SMP, UP). Tak naprawdę scheduler SMP jest specjalnym przypadkiem schedulera HT wybieranym w trakcie kompilacji (a scheduler UP jest specjalnym przypadkiem SMP wybieranym w trakcie kompilacji)

łatka oparta jest o prototyp Juna Nakajima - niskopoziomowe rzeczy dotyczące x86/Intel to ciągle te pochodzące z czerwca, w sched.c pojawiła się nowa, bardziej ogólna implementacja.

Oto pojedynczy elastyczny interfejs dla niskopoziomowego kodu startowania, który ustanawia fizyczne procesory: sched_map_runqueue(cpu1, cpu2) mapuje kolejkę cpu2 na kolejkę cpu1. Łatka implementuje także niskopoziomowe rzeczy dla maszynek P4 z HT w niektórych przypadkach.

(systemy NUMA, które mają połączone procesory z mniejszym cache i chronione przez dużą cache L3 mogą też mieć korzyści z posiadania jednej kolejki - ale celem tego pomysłu jest SMT.)

trochę liczb:

kompilacja samego floppy.c w nieskończonej pętli zabiera 2.55 sekundy na iterację. Równoległe uruchomienie dwóch takich pętli na dwóch fizycznych, dwóch logicznych procesorach (w sumie na 4 logicznych), na maszynie P4 z HT daje następujące wyniki:

2.5.31-BK-curr: - waha się między 2.60 sekundy a 4.6 sekundy.

BK-curr + sched-F3: - stabilny wynik w okolicach 2.60 sekundy.

wyniki przy normalnym schedulerze zależą po prostu od szczęścia, to znaczy od tego któremu procesorowi zostanie przydzielone zadanie. W przypadku, w którym scheduler zdaje sobie sprawę z istnienia HT, każdemu zadaniu jest cały czas przydzielany inny fizyczny procesor.

kompilacja źródeł jądra przy użyciu ,,make -j2'' [under-utilizes CPUs]:

2.5.31-BK-curr: 45.3 sekundy

BK-curr + sched-F3: 41.3 sekundy

to znaczy poprawa wynosi ~10%. Te testy to najlepsze wyniki wybrane z wielu (>10) prób. Liczby ,,bez HT'' są dużo bardziej zmienne (to znowu efekt losowy), zatem średni czas kompilacji w takim przypadku jest wyższy.

wyniki wysyconej kompilacji ,,make -j5'' są mniej więcej równoważne, tak jak tego oczekiwano - pomysł posiadania jednej kolejki dla każdego procesora działa dobrze, gdy liczba zadań jest większa niż liczba logicznych procesorów. Normalny scheduler działa dobrze na maszynkach z HT w granicznych przypadkach: gdy uruchomione jest jedno zadanie i kiedy jest więcej zadań niż wynosi nr_cpus.

łatka ujednolica także trochę innego kodu i usuwa kolejnych kilka gałęzi #ifdef CONFIG_SMP ze schedulera.

(łatka kompiluje się/uruchamia/działa dobrze zarówno na UP jak i na SMP na maszynie z P4, a także na innej maszynie SMP z PIII.)

Linus się z tym kiedyś nie zgodził, gdy to z nim dyskutowałem, a przy obecnym (głupim, nieprzenośnym, wadliwym) wołaniu systemowym set_affinity ma rację.

Nie wiesz, czy ktoś powiedział ,,zaszereguj mnie na procesorze 0'' dlatego, że naprawdę chce na tym procesorze być zaszeregowany, czy raczej dlatego, że *nie* chce być zaszeregowany na procesorze 1 (czy jakimś innym działającym). Możesz tylko zakładać, że są one równoważne, jeśli tak naprawdę są tym samym fizycznym procesorem.

Moje zmodyfikowane wołanie systemowe set_affinity (wołane z flagą ,,include/exclude'') pozwala architekturze podjąć tę decyzję (na końcu) jeśli nie wiadomo czego chce użytkownik (to znaczy także, że wiesz co robić, jeśli dostaniesz krótką bitmapę, albo przybędzie/ubędzie nowy procesor).

Nowa łatka MMU-less na 2.5.31, linux-2.5.31uc1. Mniej istotne aktualizacje, kilka małych poprawek.

Można ją pobrać stąd co zwykle:

http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/

Nie rób tego. Alan ma już poprawną wersję w swoim drzewie, którą ja przygotowałem i wysłałem Marcelo. Czytanie lkml nie boli..

Łatka, którą podesłałeś to śmieć prosto z repozytorium XFree, śmieć, który wycofuje zmiany poczynione w jądrze. Być może jest ona wystarczająca do dodania do losowego zestawu śmieciowych łatek, ale w oczywisty sposób nie spełnia kryteriów jakości nakładanych na oficjalne jądra.

dlaczego zawsze czujesz potrzebę zniechęcania ludzi, którzy oferują swoją pomoc? Pierwsze dwa zdania wystarczyłyby żeby Marc-Christian zrozumiał, że jego łatka nie jest tak dobra jak TWOJA. Reszta listu to czyste, bezinteresowne obelgi, tak jak w każdym innym Twoim liście ostatnimi czasy (z wyjątkiem tych, w których chwalisz sam siebie). Od paru tygodni, za każdym razem, gdy widzę wiadomość od Ciebie, to zanim ją otworzę pytam siebie ,,hm, kogo dziś zabija?''.

Być może masz dość śmieci w jądrze, ale MSZ to nie jest sposób na pozbycie się ich. Ta lista jest listą deweloperów, więc stara się być z natury miejscem na konstruktywne uwagi. Proszę więc, bądź trochę bardziej tolerancyjny dla innych ludzi, szczególnie tych, którzy wkładają swoją pracę w jądro.

mówiąc głośno, wcześniej w tym tygodniu zdarzył się list od jednego z opiekunów sieci, w którym ostro karcił kogoś, kto przysłał łatę jedynie na kernel list, a nie na listę network, bo nie wszyscy deweloperzy czytają kernel list.

jeśli główni deweloperzy jądra mówią ludziom, że nie czytają L-K, to nowa osoba, która przesyła łatkę i nie czyta cały czas L-K jest rozsądna, albo tak, albo tak.

to czy -ac jest najważniejsze, to kwestia opinii, w wielu przypadkach jest, ale też w wielu dużo rzeczy, które się w nim pojawia nigdy nie dostanie się do głównego drzewa.

Ta łatka dodaje jedynie podstawową funkcjonalność systemu plików XFS firmy SGI do Linuksa 2.5.32. NIE zawiera takich zmian, jak ACL-e Posix, dmapi, kdb i innych, które można znaleźć w CVS-ie XFS-u.

Łatka dodaje zawierający się w sobie kod XFS i nie czynie prawie żadnych zmian do istniejącego już kodu jądra. Oto wynik działania programu diffstat z opuszczonymi nowymi plikami:

 Documentation/Changes              |   16
 Documentation/filesystems/00-INDEX |    2
 MAINTAINERS                        |    8
 fs/Config.help                     |   66
 fs/Config.in                       |    9
 fs/Makefile                        |    1
 include/linux/sched.h              |    1
 include/linux/sysctl.h             |    2
 kernel/ksyms.c                     |    1

Wszelkie uwagi na temat łatki albo kodu xfs wysyłajcie, proszę, na adres linux-xfs@oss.sgi.com. Wiemy, że pozostały jeszcze problemy do rozwiązania, ale nie czujcie się skrępowani, aby dodawać własne pozycje.

Łatki są dostępne pod adresem:

ftp://ftp.kernel.org/pub/linux/kernel/people/hch/patches/v2.5/2.5.32/linux-2.5.32-xfs.patch.gz
ftp://ftp.kernel.org/pub/linux/kernel/people/hch/patches/v2.5/2.5.32/linux-2.5.32-xfs.patch.bz2

URL: http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.32/2.5.32-mm1/

Od 2.5.31-mm1:

• Trochę rzeczy z 2.5.31-mm1 zostało włączonych.
• Łatka konsolidująca BKL została odrzucona, bo zrobił to także Linus.
• Łatka debugująca `might_sleep()' straciła obsługującą ją infrastrukturę i narazie ją odrzuciłem.
• Łatka dająca konfigurowalne PAGE_OFFSET nie zgadza się z pewnymi zmianami w kbuild i wymaga trochę więcej pracy.

• Zostały dodane następujące łatki

  discontig-cleanup-1.patch
  discontig-cleanup-2.patch
  writeback-thresholds.patch
  buffer-strip.patch
  daniel-rmap-speedup.patch
  rmap-speedup.patch
  wli-highpte.patch

func-fix.patch
  gcc-2.91.66 nie obsługuje __func__

ext3-htree.patch
  Indeksowane katalogi dla ext3

misc.patch
  popraweczki page_alloc.c 

tlb-speedup.patch
  Redukcja o 35% typowego globalnego unieważnienia TLB

buffer-slab-align.patch
  Nie wyrównuje buffer_head do sprzętowego ograniczenia cache 

zone-rename.patch
  Zmiana nazw zone_struct->zone, zonelist_struct->zonelist.  Usunięcie zone_t,
  zonelist_t.

per-zone-lru.patch
  Algorytm LRU per strefa 

per-zone-lock.patch
  Blokowanie list LRU oddzielnie dla każdej strefy

l1-max-size.patch
  Infrastruktura pozwalająca określić maksymalny cache L1, który może obsługiwać jądro.
  
zone-lock-alignment.patch
  Poprawka struktury zone w celu zapewnienia rozdzielenia lru i blokad

put_page_cleanup.patch
  Wyczyszczenie put_page() i page_cache_release().

anon-batch-free.patch
  Połączenie zwalniania i zdeLRUowania anonimowych stron 

writeback-sync.patch
  Poprawki i ulepszenia writeback
  
ext3-inode-allocation.patch
  Poprawka zakleszczenia ext3
  
ext3-o_direct.patch
  Obsługa O_DIRECT dla ext3.

discontig-paddr_to_pfn.patch
  Zmiana wskaźników stron na pfns dla i386 NUMA

discontig-setup_arch.patch
  Przeróbka setup_arch() dla i386 NUMA

discontig-mem_init.patch
  Zmiana struktury mem_init dla i386 NUMA

discontig-i386-numa.patch
  Obsługa discontigmem dla i386 NUMA

cleanup-mem_map-1.patch
  Wyczyszczenie wielu użyć mem_map[]. Dla ia32 NUMA

zone-pages-reporting.patch
  Poprawka raportu o dostępnych stronach w każdej strefie w czasie startowania

enospc-recovery-fix.patch
  Poprawka błędu w  __block_write_full_page().

fix-faults.patch
  Usunięcie początkowej pracy nad atomowym copy_*_user()

spin-lock-check.patch
  infrastruktura sprawdzania spinlock/rwlock 

copy_user_atomic.patch

kmap_atomic_reads.patch
  Użycie kmap_atomic() w generic_file_read()

kmap_atomic_writes.patch
  Użycie kmap_atomic() w generic_file_write()

throttling-fix.patch
  Poprawka wąskich gardeł dla dużej liczby write()ów.

dirty-state-accounting.patch
  Bardziej odpowiednie zliczanie globalnej brudnej pamięci

rd-cleanup.patch
  Poprawki i wyczyaszczenie sterownika ramdisk (jeszcze nie działa dobrze)

discontig-cleanup-1.patch
  poprawki kodu w i386 discontigmem

discontig-cleanup-2.patch
  poprawki i386 discontigmem
  
writeback-thresholds.patch
  Poprawki do domyślnych progów zabrudzonej pamięci

buffer-strip.patch
  Ograniczenie używania ZONE_NORMAL przez buffer_heads

daniel-rmap-speedup.patch
  Blokowanie dla rmap pte_chains

rmap-speedup.patch
  Redukcje zużycia przestrzeni i procesora w rmap pte_chain

wli-highpte.patch
  CONFIG_HIGHPTE - ia32 pagetables w highmem

Napisałem API zaawansowanego śledzenia, jako potencjalną możliwość zastąpienia ptrace. Nie jest jeszcze kompletne, ale ma wystarczającą funkcjonalność, aby możliwe było zaimplementowanie strace.

Wszystko działa dzięku dodaniu nowej funkcji systemowej, która obsługuje deskryptory plików, dotyczące plików ,,specjalnych'' (mniej więcej jak to robi shm z sysvipc). Jednakowoż deskryptory te są udostępniane i można z nich korzystać. Każdy deskryptor kieruje grupą wątków.

Jest już obsługa wątków stworzonych przez CLONE_THREAD.

Dostępna dokumentacja znajduje się w łatce trace-2532.

Komentarze są mile widziane.

Dostępna jest para łatek dla 2.5.32 oraz program przykładowy/demonstracyjny:

ftp://infradead.org/pub/people/dwh/orn-2532.diff.bz2
ftp://infradead.org/pub/people/dwh/trace-2532.diff.bz2
ftp://infradead.org/pub/people/dwh/trctl2.c

Najpierw zaaplikujcie łatkę orn-2532, a potem -- trace 2532, obie na jądro 2.5.32, skompilujcie i zainstalujcie. W tej chwili program trctl12 wymaga dostępu do plików nagłówkowych załatanego jądra.

Uruchomcie trctl12 przy załatanym jądrze. Wygeneruje się proces ,,zależny'', który będzie łapany i opisywany przez pryzmat zdarzeń, które się w nim wydarzą. Proces zależny następnie uruchomi zbiór wątków, które też będą zarządzane przez ten ,,debugger''. Aby otrzymać te zdarzenia, można wysyłać do wątków różne sygnały.

Głównie łączenie kawałków z Alanem i innymi.

Podsumowanie zmian od v2.4.20-pre4 oo v2.4.20-pre5
============================================

<andersen@codepoet.org>:
  o 2.4.20-pre[234] poprawka /proc/partitions

<bhavesh@avaya.com>:
  o Poprawka zachowania schedulera w czasie rzeczywistym

<danc@mvista.com>:
  o PPC32: Dodanie obsługi płyty SBS Palomar 4 

<davem@pizda.ninka.net>:
  o SPARC64: Początek obsługi Cheetah-plus, nie w pełni zdebugowany

<dwmw2@redhat.com>:
  o Kolejna poprawka oopsa w JFFS2

<dz@cs.unitn.it>:
  o ostatnia wersja modułu i8k 

<engebret@us.ibm.com>:
  o Re: [PATCH] poprawka PPC64 dla 2.4.19-rc1

<hch@lst.de>:
  o Włączenie obsługi ETHTOOL_GDRVINFO dla kilku sterowników sieciowych pcmcia
  o aktualizacja drm do XFree 4.2 
  o użycie -iwithprefix w celu znajdowania nagłówków gcc
  o naprawienie teoretycznego wyścigu w śceiżce: init błąd strony init

<james@cobaltmountain.com>:
  o drivers_usb_usb-uhci.c, literówki: the the, brakujące 'of'
  o drivers_usb_auerswald.c, literówka: the the
  o net/ipv4/netfilter/ip_conntrack_core.c: Poprawka literówki w komentarzu
  o net/ipv4/netfilter/ip_nat_core.c: Poprawka literówki w komentarzu

<jani@iv.ro>:
  o głęba kolorów dla tridentfb w Config.in

<jgarzik@tout.normnet.org>:
  o Poprawka prototypu xdr_shift_buf w inc/linux/sunrpc/xdr.h, żeby
  pasował do implementacji (s/unsigned int/size_t/).

<jsiemes@web.de>:
  o net/ipv4/ipconfig.c: dodano obsługę wielu serwerów nazw. 

<jwoithe@physics.adelaide.edu.au>:
  o Obsługa twardego dysku Buffalo 40GB USB 

<kisza@sch.bme.hu>:
  o net/ipv6/netfilter/ip6_tables.c: poprawka błędów parsowania
  rozszerzenia nagłówka 

<mark@alpha.dyndns.org>:
  o USB: ov511 1.61 dla 2.4

<paulus@au1.ibm.com>:
  o PPC32: dodanie obsługi platformy IBM ,,Spruce'' 
  o PPC32: czyszczenie obsługi przerwania na platformie APUS

<sct@redhat.com>:
  o 2.4.20-pre4/ext3: Obsługa niespodziewanych brudnych buforów 
  o 2.4.20-pre4/ext3: Poprawka nieudanej asercji ,,buffer_jdirty''
  o 2.4.20-pre4/ext3: Poprawka ,,dump corrupts filesystems''
  o 2.4.20-pre4/ext3: Poprawka problemu z aliasem bufora 
  o 2.4.20-pre4/ext3: Poprawka wycieku truncate
  o 2.4.20-pre4/ext3: Poprawka obsługi sytuacji braku i-węzłów
  o 2.4.20-pre4/ext3: Poprawka błędu truncate restart 
  o 2.4.20-pre4/ext3: Poprawka wydajności zachowania O_SYNC

<solar@openwall.com>:
  o net/unix/af_unix.c: Ustawienie ATIME na i-węźle gniazda

Alan Cox <alan@lxorguk.ukuu.org.uk>:
  o SBUS: extern->static inline
  o to było źle - dobrze było od wieków w -ac 
  o dodanie config.in dla nowego synclink mp
  o parisc config.in
  o zauważenie znikającego błędu initrd i problem z rozmiarem bloku 
  o dokumenty dla uaktualnienia isapnp w pre4
  o zmienne synclink zamienione na static
  o poprawienie obsługi zawijania w ieee1394
  o poprawienie ostrzeżenia w i2o
  o założenie maski DMA w i2o
  o poprawki literówek w aic7xxx
  o zła definicja ixj 
  o zorro proc powinien również używać loff_t 
  o hppa także wymaga dziwnego kstat
  o tylko egcs miało ten problem, więc nie włazić na 2.95+
  o wyrównanie cache w irq stat
  o poprawki sparc64 pcibios ze względu na zmiany w pre4
  o nowe pozycje w dmi
  o poprawka stareńkiego błędu w khttpd
  o ogólna część rw trylocks
  o aktualizacja parport ifdefs dla HPPA
  o ponowne przysłanie - magistrala wejścia HIL
  o down_write_trylock
  o poprawka EFS przy wykrzaczeniu się cd 
  o dodanie hppa do danych fbcon 
  o wyciszenie informacji o opóźnieniu
  o w ppc64 brakuje ioctl32 
  o hppa w ia64 nie używa starych struktur ipc 
  o nowe sem_getcount oznacza, że cna znika
  o kolejne poprawki literówek
  o poprawki literówek ctd
  o poprawka via rhine
  o poprawka typów w bttv_read 
  o poprawka typów w detected_devices 
  o naprawienie ostrzeżeń gcc w isdn 
  o wyczyszczenie ifdefów w vt.c
  o uaktualnienie opisu /proc 
  o dokumentacja księgowania 
  o poprawki PCI 
  o dokumentacja uaktualnienia ldm 
  o ps2esdi - niewłaściwy bit
  o sterownik watchdoga AMD 
  o dodanie synclink_mp
  o sensowniejsze zwracanie błędu w hotplug
  o poprawka literówki w i2o 
  o e1000 - powrót z funckji bez wartości
  o odśmiecenie smodemu
  o fix pci_release/request_regions bugs
  o poprawka __FUNCTION__ w  irda-usb

Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>:
  o arch/i386/lib/checksum.S: Obsługa zerowej długości

Brian Beattie <beattie@beattie-home.net>:
  o łatka dla scanner.h w 2.4 dodająca urządzenie ids

David S. Miller <davem@nuts.ninka.net>:
  o arch/sparc64/defconfig: aktualizacja
  o include/linux/sunrpc/svcsock.h: zmiana sk_flags na long
  o include/linux/sunrpc/svcsock.h: sk_flags muszą być typu must be a long for bitops
  o SPARC: Uakatualnienie zmienionych argumentów pcibios_enable_device 
  o include/linux/sunrpc/xdr.h: usunięcie deklaracji xdr_zero_buf, poprawienie argumentów 
xdr_shift_buf 
  o arch/sparc64/mm/ultra.S: Poprawienie warunku rozgałęzienia w  __cheetah_flush_tlb_range
  o include/asm-sparc/types.h: Nie ma powodu, żeby na sparc 32 dma64_addr_t było 64-bitowe
  o SPARC64: Poprawka ukrytego zawieszania cheetah+ 
  o TIGON3: Dodanie brakującego udelay podczas czyszczenia statystyk/bloku statusu SRAM 
  o SPARC64: Naprawienie DRM by używało nowych, nie starych sterowników 
  o net/unix/af_unix.c: Dobre ustawienie msg_namelen w unix_copy_addr, zdefiniowanie
MODULE_LICENSE
  o net/ipv4/tcp_diag.c: Zapobieżenie niewyrównanym dostępom do tcpdiag_cookie
  o SPARC64:setup_arch poprawka linii I-cache podczas łatania irqsz_patchme
  o SPARC64: poprawka w Ultra-III+ i lepsze logowanie złych pułapek

Greg Kroah-Hartman <greg@kroah.com>:
  o USB: uaktualnienia dokumentacji
  o USB: uaktualnienie sterownika ov511 do najnowszej wersji 
  o USB: uaktualnienie sterownika pegasus do najnowszej wersji 
  o aktualizacja sterownika microtek do najnowszej wersji 
  o aktualizacja sterownika wacom w celu poprawienia problemu z niepoprawnymi danymi
  o USB: mniejsze czyszczenia kodu i poprawki __FUNCTION__ 
  o USB: poprawki błędów w USB 2.0 hub
  o aktualizacja do ostatniej wersji sterownika rtl8150 
  o mniej ważne poprawki sterownika drukarki 
  o aktualizacja sterownika stv680 do ostatniej wersji 
  o USB: poprawienie błędu usb-ohci dal wolnych maszyn i poprawienie błędu cardbus
  o USB: poprawki nieprawidłowych operacji bitowych i przeterminowań FSBR w uhci 
  o dodanie pozycji w Configure.help dla sterownika ACPI PCI Hotplug 
  o PCI Hotplug: poprawienie oopsa przy dostawaniu się do pcihpfs

Hanna Linder <hannal@us.ibm.com>:
  o path_lookup dla 2.4.20-pre4

Hugh Dickins <hugh@veritas.com>:
  o M386 flush_one_tlb invlpg

James Morris <jmorris@intercode.com.au>:
  o [NETFILTER]: ip{,6}_queue.c poprawki i czyszczenie

Jeff Garzik <jgarzik@mandrakesoft.com>:
  o Poprawka obsługi 8139cp 64-bit DMA 
  o Uaktualnienie sterownika e1000; dwie małe poprawki ethtool

Marcelo Tosatti <marcelo@plucky.distro.conectiva>:
  o Odwrócenie zepsutej poprawki statystyk cpqarray w poprzednim -pre
  o Ponowne dodanie context_swtch do struktury kernel_stat 
  o Zmiana EXTRAVERSION na -pre5

Neil Brown <neilb@cse.unsw.edu.au>:
  o SUNRPC 1 z 3 - Nowe słowo ,,sk_flags'' w strukturze svc_sock
  o SUNRPC 2 z 3 - Poprawka dwóch problemów z równoległością
  o SUNRPC 3 z 3 - Wołanie svc_sock_setbufsize gdy gniazdo 

Rob Radez <rob@osinvestor.com>:
  o SPARC32: poprawki kompilacji Sparc32 z włączonym CONFIG_PCI 

Rusty Russell <rusty@rustcorp.com.au>:
  o [PATCH] podwójne deklaracje #2
  o 2.5: kconfigowi znowu brakuje OBSOLETE (2_3) 
  o Documentation_filesystems_devfs_README, literówka: the the
  o trywialna łatka na dokumentację SonyCD535 
  o drivers_net_rcpci45.c, literówka: the the
  o drivers_net_pcmcia_xircom_cb.c, literówka: the the,
  o Re: pci_alloc_consistant poprawka flagi gfp 
  o drivers_net_winbond-840.c, literówka: the the
  o list_for_each_entry

Scott Feldman <scott.feldman@intel.com>:
  o uaktualnienie sterownika sieciowego e100 1/3
  o uaktualnienie sterownika sieciowego e100  2/3
  o uaktualnienie sterownika sieciowego e100  3/3
  o uaktualnienie sterownika sieciowego e1000  1/5
  o uaktualnienie sterownika sieciowego e1000  2/5
  o uaktualnienie sterownika sieciowego e1000  3/5
  o uaktualnienie sterownika sieciowego e1000  4/5
  o uaktualnienie sterownika sieciowego e1000  5/5

Tim Waugh <twaugh@redhat.com>:
  o 2.4.20-pre4: ,,myślówka'' w parportbook

Tom Rini <trini@kernel.crashing.org>:
  o PPC32: odzielenie wyszukiwania i parsowania informacji z boot wrapppera
  o PPC32: implementacja funkcji obsługi dla dodatkowych poprawek PCI wymaganych na niektórych 
platformach
  o PPC32: dodanie funkcji obsługi dla debugera Abatron BDI2000, dodatkowe flagi kompilacji. 

Jest nowa łatka bez-MMU, linux-2.5.32uc1. Możecie ją pobrać z:

http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/

Małe poprawki:

• Poprawiłem niepoprawne ustawienia totalram_pages w arch mm init
• Dodałem kilka funkcji vmalloc_, aby naprawić moduły
• Dodałem opcję konfiguracyjną m68knommu dla podsystemów bezpieczeństwa oraz bibliotek
• Dodałem Config.help do arch/m68knommu

Załączam łatki ic2, które synchronizują jądro z ostatnią przetestowaną wersją. Aktualizacje obejmują:

• Obsługę błędów dla SMBus 2.0 PEC
• Nowy algorithm-i2c-algo-8xxx dla MPC8XXX
• Nowy algorithm-i2c-algo-ibm_ocp dla IBM PPC 405
• Nowy adapter-i2c-adap-ibm_ocp dla IBM PPC 405
• Nowy adapter-i2c-frodo dla płyty SA 1110
• Nowy adapter-i2c-pcf-epp dla PCF8584
• Nowy adapter-i2c-pport dla portu równoległego
• Nowy adapter-i2c-rpx dla osadzonego MPC8XX
• Aktualizację dokumentacji