Kernel Traffic #180 For 2002/08/19

To jest duże, skomplikowane i nikt nie bierze tego wystarczająco poważnie (jedyni ludzie, którzy pytali _mnie_ o sterownik, to Intel, a wygląda na to, że sami zrezygnowali z powiązanych projektów).

Jeśli okaże się, że IB to wielki hit, możemy przenieść sterownik do niższej serii jąder. Na razie wygląda na to, że nie ma większego znaczenia dla zamrożenia 2.6.

Prawda, a żeby poprzeć to faktami, to firmy, które stawiały głownie na IB, mają teraz poważne kłopoty, pomijając ich stan ekonomiczny, bo Intel najwyraźniej zrezygnował ze swoich projektów.

Kilka firm w Austin w Teksasie próbowało przez moment zatrudniać ludzi do pracy nad technologią InfiniBand, ale od dłuższego czasu w związku z tym nie dzieje się nic nowego... I chyba nie będzie się działo, dopóki Intel, HP, IBM lub ktokolwiek inny z dużą kasą i poważną machiną reklamową nie udowodni, że ta technologia nadaje się dla klientów.

Ach, te plotki z Austin.

Według mojego kolegi pracującego w AMD:

1. Intel licencjonował to hiper-transportowe coś, gdy licencjonował x86-64 (Yamhill?).
2. Dell zwracał koszty zakupu za te kilka maszyn z itanium, które udało im się sprzedać. (Wydaje mi się, że liczba, którą usłyszałem, to 250 sprzedanych systemów ,,rozwojowych'' itanium...)

Wydaje się, że trend jest widoczny, ale znacie te plotki... :)

Tutaj znajdują się aktualne parametry dla SIOCETHTOOL ioctl(). Sterowniki urządzeń sieciowych powinny implementować je w jak największym zakresie.

ETHTOOL_GSET
ETHTOOL_SSET

Pobierają/ustawiają parametry kart sieciowych (NIC). Wywołania te oczekują na 'struct ethtool_cmd *' jako ich argument. Struktura ta zawiera pola dla wspieranych właściwości (szybkość, duplex, transceiver), raportowanych możliwości karty, szybkości, dupleksu, portu, transceivera oraz autonegocjacji. Jeżeli podjęta zostanie próba ustawienia niewłaściwej wartości w którymkolwiek z pól, należy zwrócić -EINVAL.

ETHTOOL_GDRVINFO

Pobiera informację o sterowniku. To polecenie oczekuje na argument typu 'struct ethtool_drvinfo *'. Struktura ta zawiera ciąg znaków identyfikujący sterownik, jego wersję (także jako ciąg znaków), informacje o magistrali dla interfejsu oraz rozmiar danych dla innych poleceń ETHTOOL_*.

ETHTOOL_GREGS

Zwraca zrzut zawartości rejestrów karty. Oczekuje na argument typu 'struct ethtool_regs regs *'. Struktura ta ma specyficzne dla sterownika pole wersji oraz pole długości danych. Pole długości danych wskazuje na długość pola danych, które zostanie zapełnione przez informacje pobrane z rejestrów karty.

ETHTOOL_GWOL
ETHTOOL_SWOL

Pobierają/ustawiają parametry wake-on-lan dla NIC. Komendy te oczekują na parametr typu struct 'ethtool_wolinfo *'. Struktura ta zawiera pola dla obsługiwanych i aktywnych opcji WoL oraz hasło SecureOn, o ile zostało uaktywnione. W przypadku próby ustawienia niewłaściwych wartości parametrów należy zwrócić -EINVAL.

ETHTOOL_GMSGLVL
ETHTOOL_SMSGLVL

Pobierają/ustawiają wartość 'message-level' dla sterownika karty. Polecenia te oczekują na argument typu 'struct ethtool_value *'.

ETHTOOL_NWAY_RST

Wymuszenie ponownej autonegocjacji parametrów połączenia, o ile taka usługa jest aktywna. Jeżeli nie, należy zwrócić -EINVAL.

ETHTOOL_GLINK

Pobierz informację opisującą aktualny stan połączenia. Polecenie to oczekuje parametru typu 'struct ethtool_value *'.

ETHTOOL_GEEPROM
ETHTOOL_SEEPROM

Pobierają/ustawiają parametry i informacje związane z EEPROM. Polecenia te oczekują na argument typu struct ethtool_eeprom *'. Struktura ta zawiera ,,magiczny'' parametr - parę danych: przesunięcie i rozmiar oraz pole danych. Jeżeli przesunięcie+rozmiar jest większe od maksymalnego, dozwolonego rozmiaru, wtedy dodatkowe pole jest ignorowane.

ETHTOOL_GCOALESCE
ETHTOOL_SCOALESCE

Ustawia/pobiera wartości stanu połączenia. Polecenie to oczekuje na parametr typu 'struct ethtool_coalesce *'. Struktura ta zawiera kilka pól dla różnych wartości stanu połączenia -- więcej informacji w ethtool.h. Jeżeli wykryta zostanie próba ustawienia nieprawidłowej wartości należy zwrócić -EINVAL.

ETHTOOL_GRINGPARAM
ETHTOOL_SRINGPARAM

Pobierają/Ustawiają parametry ,,ring'' trasmisji danych. Oczekują na parametr typu 'struct ethtool_ringparam *'. Struktura ta ma pola dla aktualnych parametrów transmisji. Jeżeli nastąpi próba ustawienia niewłaściwych wartości, należy zwrócić wartość -EINVAL.

ETHTOOL_GPAUSEPARAM
ETHTOOL_SPAUSEPARAM

Pobierają/ustawiają parametry przerwy RX/TX. Polecenia te oczekują na parametr typu 'struct ethtool_pauseparam *'. Struktura ta posiada pola pola aktywujące autonegocjację tego parametru oraz wymuszające wartość parametru przerwy RX/TX.

ETHTOOL_GRXCSUM
ETHTOOL_SRXCSUM

Pobierają/ustawiają wartość flag odpowiedzialnych za sprzętowe obliczanie sumy kontrolnej odbieranych danych. Oczekują na parametr typu 'struct ethtool_value *'. Jeżeli nastąpi próba ustawienia tej flagi na sprzęcie, który nie wspiera takiej właściwości, należy zwrócić -EINVAL.

ETHTOOL_GTXCSUM
ETHTOOL_STXCSUM

Pobierają/ustawiają wartość flag odpowiedzialnych za sprzętowe obliczanie sumy kontrolnej transmitowanych danych. Oczekują na parametr typu 'struct ethtool_value *'. Jeżeli nastąpi próba ustawienia tej flagi na sprzęcie, który nie wspiera takiej właściwości, należy zwrócić -EINVAL.

ETHTOOL_GSG
ETHTOOL_SSG

Pobierają/ustawiają stan flagi odpowiedzialnej za właściwości scatter/gather Oczekują na parametr typu 'struct ethtool_value *'. Jeżeli nastąpi próba ustawienia tej flagi na sprzęcie, który nie wspiera takiej właściwości, należy zwrócić -EINVAL.

ETHTOOL_TEST
/* wywołuje autotest karty, polecenie prywatne /*

ETHTOOL_GSTRINGS
/* pobiera zadany łańcuch znaków /*

ETHTOOL_PHYS_ID
/* identyfikuje kartę */

ETHTOOL_GSTATS
/* pobiera statystyki specyficzne dla karty */

Seria zmian w driverfs została zaaplikowana w drzewie Linusa w ostatni piątek. Oto krótka lista tych zmian oraz kilka informacji na temat ich użycia.

Po pierwsze, zmieniłem nazwę deklarowanej struktury ze struct driver_file_entry na struct device_attribute. Ta nazwa, w bardziej precyzyjny sposób, opisuje jej przeznaczenie.

Stworzyłem także makro do definiowania atrybutów urządzeń, którego wywołanie jest następujące:

DEVICE_ATTR(name,"strname",mode,show,store);

Stworzy zostanie struktura o nazwie 'dev_attr_##name', gdzie ##name jest pierwszym parametrem przekazywanym do device_create_file(). [2]

Zmieniła się definicja device_remove_file:

void device_remove_file(struct device * dev, struct device_attribute * attr);

(Drugi parametr, w celu zapewnienia spójności (zamiast char*), jest tego samego typu, co w deklaracji device_create_file).

Dodałem obsługę dla atrybutów magistrali oraz sterownika. Te mechanizmy są analogiczne do obsługi atrybutów urządzeń. Aby je zadeklarować, należy wykonać:

BUS_ATTR(name,"strname",mode,show,store); DRIVER_ATTR(name,"strname",mode,show,store);

co stworzy obiekt

struct bus_attribute bus_attr_##name;

jak również

struct driver_attribute driver_attr_##name;

Możecie wtedy użyć

int bus_create_file(struct bus_type *, struct bus_attribute *); void bus_remove_file(struct bus_type *, struct bus_attribute *);

int driver_create_file(struct device_driver *, struct driver_attribute *); void driver_remove_file(struct device_driver *, struct driver_attribute *);

Aby je dodawać i usuwać.

Atrybuty magistrali pojawią się w odpowiednim katalogu (bus/<bus>/ w punkcie montowania systemu driverfs).

Atrybuty sterownika pojawią się w odpowiednim katalogu (bus/<bus>/<driver>/ w punkcie montowania systemu driverfs).

Funkcje wyświetlające i przechowujące dane o magistrali są identyczne z tymi, które obsługują pliki urządzeń, tylko że pobierają wskaźnik do struktury bus_type jako swój pierwszy parametr.

Podobnie urządzenia; pobierają jako pierwszy parametr wskaźnik do struktury device_driver.

W pliku include/linux/device.h znajdują się definicje struktur a w drivers/base/fs/*.c szczegóły implementacji.

Driverfs wspiera atrybuty obiektów wszelkich typów. Zaktualizowałem dokumentację (Documentation/filesystems/driverfs.txt), miejmy nadzieję, że znajduje się tam wystarczająco dużo informacji, by móc ze zrozumieniem grzebać w kodzie. Jestem otwarty na wszelkie zapytania i propozycje, więc możecie śmiało pytać.

NTFS: 2.0.24 - czyszczenie kodu.

• Traktowanie BUG_ON() jako ASSERT(), a nie jako VERIFY(), np.: nie używać efektów ubocznych wewnątrz BUG_ON(). (Adam J. Richter)
• Rozdzielenie wyrażeń logicznych OR wewnątrz BUG_ON() na osobne wywołania w celu poprawienia odpluskwiania. (Adam J. Richter)
• Dodanie flagi błedów do stanu partycji ntfs, dostępnej przez NVol{,Set,Clear}Errors(vol).
• Nie zezwalać na montowanie partycji tylko do odczytu z błędami jako partycji z prawem do odczytu i zapisu.
• Ujednoznaczenienie komentarza dotyczącego operacji na pliku dla ntfs sendfile, dodanego niedawno przez Christopha Hellwiga (po prostu używamy generic_file_sendfile()), aby powiedzieć, że ntfs ->sendfile używa się tylko w przypadku, gdy dane źródłowe są na partycji ntfs, a miejsce docelowe na jakiejś innej, nic, czym musimy się przejmować.

Z ciekawości sprawdziłem

static void tg3_write_mailbox_reg32(struct tg3 *tp, u32 off, u32 val)
{ 
        unsigned long flags;

        spin_lock_irqsave(&tp->indirect_lock, flags);
        writel(val, tp->regs + off);
        spin_unlock_irqrestore(&tp->indirect_lock, flags);
}

i to działa. To oznacza, że zapis skrzynki pocztowej powoduje dodatkową blokadę w okolicach niezmienionego wywołania writel(). Czy spin_lock_irqsave/spin_unlock_irqrestore w odpowiedni sposób operują na magistrali PCI?

Podczas poprawnego ,,ładowania'', komputer w dalszym ciągu zawieszał się. Po krótkim namyśle postanowiłem dodać ,,nicnierobiące'' pci_read_config_dword(), zaraz przed writel() i to zadziałało! Używam tej funkcji zarówno dla tw32 jak i dla tw32_mailbox. Torturowałem to skryptem ponad godzinę skryptem, który zawsze doprowadzał do zawieszenia komputera w ciągu pięciu sekund.

Pozostało tylko jedno pytanie: czy da się to osiągnąć w bardziej elegancki sposób?

Ta łatka pozwala zadaniom współdzielić uwierzytelnienia (credentials) przez flagę podawaną funkcji clone().

Ta wersja naprawia problem z funkcją exec() znaleziony przez Linusa. Zadania, które wołają exec() dostają w tym momencie własną kopię uwierzytelnień.

Podaję tu URL, bo łatka jest zbyt duża, by ją umieścić w liście elektronicznym:

http://www.ibm.com/linux/ltc/patches/misc/cred-2.5.30-3.diff.gz

Jest to łatka do nałożenia na drzewo Linusa z BK z tego poranka.

Makra (i funkcje 'inline') mają taką zaletę, że wymuszają dobre zachowanie. Wykonanie 'task->cred->uid = a' dla zadania innego niż 'current', nie jest ogólnie bardzo bezpieczne. Taki rodzaj rzeczy, w odniesieniu do polityki bezpieczeństwa, powiniem w szczególności Cię niepokoić, gdy zaczniesz dodawać CRED_CLONE...

Jest parę dobrych precedensów, by stosować ten argument: patrz 'set_current_state()' & przyjaciele.

Dodatkowo, te makra pozwoliłby by Ci utrzymać zgodność z 2.4.x i ułatwić przenoszenie łatki na niższe wersje jądra.

Jeśli chodzi o zmianę struktury: tak jak wcześniej powiedziałem chciałbym wszystkie wszystkie te {fsuid, fsgid, group} zunifikować w poprawnym ucred, żebyśmy mogli dzielić te obiekty z kodem VFS i trzymać w cache... Twoja 'struct cred' taka jaka jest, nie jest wystarczająca, żeby to wszystko zrobić, jako że nie dostarcza koniecznej ochrony Copy On Write. (Na przykład, jeśli pewien wątek czasowo zwiększa przywileje procesu, to *nie* chcę, żeby wszystkie już otwarte 'struct file' nagle dostały prawa superużytkownika).

Uwierzytelnianie pod systemami UNIX zwykle wymaga od Ciebie sprawdzenia uid/gid/dodatkowych grup procesu. Ponieważ tak jest, to użyteczną byłaby możliwość przekazywania tych informacji w jądrze. Większość systemów operacyjnych używa pewnej wariacji struktury 'ucred' z BSD, w której jest licznik odniesień i przestrzegane jest COW (copy on write).

struct ucred{
  atomic_t count;
  uid_t    uid;      /* == fsuid jeśli wolisz */
  gid_t    gid;      /* == fsgid   "     "    */
  int      ngroups;
  gid_t    *groups;
};

To oznacza, że 'struct file', odpowiednie systemy plików, inne takie... mogą trzymać referencję do tej struktury i być pewnymi, że ona się nigdy nie zmieni. Zmiany fsuid itp. są wybitnie rzadko odbywającymi się operacjami w porównaniu z otwieraniem/zamykaniem plików, więc cały ten pomysł polega dokładnie na *uniknięciu* posiadania kopii powyższych informacji przez cały czas (co, biorąc pod uwagę wszystkie wyścigi, które wprowadza CLONE_CRED, jest dobrą rzeczą).

Co do zachowania zgodnego z POSIX: jest całkiem zgodne z powyższym. Jedyną zmianą byłoby to, że twoja współdzielona 'struct cred' wymagałaby referencji do struct ucred zamiast umieszczania w cred pól fsuid, fsgid, groups.

Uwaga: Ponieważ Linux przyjął model 'capability' nadbudowany na standardowy model uwierzytelniania UNIX-a, być może konieczne będzie przemieszczenie capabilities do struktury ucred, żeby także one były COW?

Co jeśli jeden wątek wykonuje wołanie RPC, podczas gdy drugi zmienia pole 'groups'?

Założmy, że pierwszy wątek chce zarówno skopiować jak i porównać pole z grupą, to co zabopiegnie scenariuszom postaci:

  Wątek 1                       Wątek 2

                               zmień cred->ngroups
kopiuj cred->ngroups
kopiuj cred->groups
                               zmień cred->groups

Proszę, nie rób tego przy pomocy blokowania, sądzę, że właściwy sposób rozwiązania tego problemu to funkcja 'duplicate()', która pozwoliłaby duplikować uwierzytelnienia, gdy są gdzieś przekazywane.

Jeśli rozpoczynasz proces jako nie-root, a potem wykonujesz execve suid na roota, to oczekujące żądanie NFS _nie_ powinno nagle mieć zmienianych uwierzytelnień. Oczywiście takie coś nie może też być blokowane.

Razem z semantyką copy-on-write, to powinno działać świetnie (to znaczy 'duplicate()' zwiększałoby tylko licznik, a kod setuid() musiał by zawierać coś w stylu

        if (cred->count > 1){
                newcred = alloc_cred();
                copy_cred(newcred, cred);
                for_each_cred_group(p){
                        p->cred = newcred;
                        atomic_inc(&newcred->count);
                        putcred(cred);
                }
}

zamiast tego, co do tej pory.

Właśnie ukazała się kolejna wersja Projektu Testowania Linuksa -- LTP-20020807.tgz. Odwiedźcie naszą stronę (http://ltp.sourceforge.net), aby ściągnąć najnowszą wersję zestawu oraz dowiedzieć się o wynikach testów przeprowadzonych na wersjach -pre, -rc i stabilnych wersjach jądra. Jest również spis testów, które mają prawo się nie udać - http://ltp.sourceforge.net/expected-errors.php.

Najważniejsze właściwości:

• Działa strona o pokryciu kodu jądra 2.5.X przez LTP - http://ltp.sf.net/coverage/coverage-2.5.26/index.html
• Narzędzia do określania pokrycia kodu jądra są dostępne w CVS w module utils.
• Zautomatyzowanie środowiska testowego do ściągania, budowania i instalowania przeróżnych testów Linuksa dostępnych w CVS w module utils.
• Narzędzie do obciążania baz danych 'dbgrinder' jest dostępne w CVS pod ltp/utils/database.

Zachęcamy społeczność do wysyłania wyników, łatek oraz nowych testów na naszą listę dyskusyjną i używania systemu śledzenia błędów CVS do zgłaszania problemów z zestawem testowym. Więcej informacji dostępnych jest na naszej stronie www.

Lista zmian:

• Dodano:
• Dodano nowe testy dla link07,fcntl22,link06 ( Group Bull )
• Dodano tester opóźnień linuksowego schedulera ( Davide Libenzi )
• Narzędzie do testowania baz danych 'dbgrinder' ( James Kenefick )
• Poprawki
• Wiele poprawek dla 64 bitów ( Gerhard Tonn )
• Poprawki fstat05,llseek dla MIPS ( Carsten Langgaard )
• - poprawiono test getgroups03, który powodował błąd, gdy 'nobody' nie był obecny w żadnej z pobocznych grup ( Paul Larson )
• Poprawiono sendfile02 umożliwiając działanie na 2.5, które już nie pozwala powrócić z operacji zapisu ( Paul Larson )
• Zmieniono zakodowany adres ip na 127.0.0.1 w recvfrom01-sctp-udp-ipv6 ( Robbie Williamson )
• Dodano opcje 'instance' i 'time' dla skryptu runalltests.sh ( Jeff Martin )
• Poprawiono algorytm fork07, fork12 Zmniejszono wyjście fork07 do skończonych ilości ( Nathan Straz )
• Dodano fork12 do runtest/crashme. ( Nathan Straz )
• Dodano opcję wyobru interfejscu w tcpdump01 ( Robbie Williamson )

Zamknięte błędy z CVS:

#591695 getgroups03 szwankuje na niektórych dystrybucjach
#591698 sendfile02 nie działa z jądrami 2.5

Wyróżnienia

• Manoj Iyer, James Kenefick i Peter Oberparleiter za dostarczenie zestawu narzędzi do analizy pokrycia.

Ponieważ Linus nie robi już pre-łatek, zauważył kiedyś, że byłoby miło, gdyby ktoś zautomatyzował robienie migawek BK, aby udostępnić zmiany w BK pomiędzy wydaniami jądra. Zrobiłem to.

ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/snap/2.5/

Wszystkie zmiany z BK, nieznajdujące się w aktualnym jądrze 2.5, będą pojawiały się pod tym adresem, w postaci GNU patch, codziennie. [proces odbywa się minutę po północy, czasu kalifornijskiego]. Pełna lista zmian również się pojawia. Za każdym razem, jak Linus wypuści nowe jądro, zawartość tego katalogu będzie czyszczona.

Dwa szczegóły:

• Tak jak w pre-łatkach, EXTRAVERSION w Makefile wskazuje "-bk1", "-bk2", itd.
• Zrobię coś takiego również dla 2.4, na prośbę Marcelo.

Heh, mam coś mniej-więcej takiego tutaj, na NL.linux.org:

ftp://ftp.nl.linux.org/pub/linux/bk2patch/

Co 3 godziny tworzy zunifikowanego diffa pomiędzy ostatnią oznaczoną wersją i drzewem bk, dla 2.5 i 2.4.

Żeby powstrzymać wszystkie prywatne odpowiedzi [dostałem już dwie], moje rozwiązanie jest troszkę inne niż Twoje czy Davida Woodhouse'a. Moim celem było stworzenie codziennej pre-łatki, kompletnej, ze zmienionym EXTRAVERSION. To coś, co jest znane testerom (forma pre-łatki), a migawki nie są na tyle często, żeby utopić ludzi w zamieci łatek i csetów. wyobraź sobie ,,2.5.30-bk439'' ;-)

Uznaję moje codzienniki, jako uzupełnienie Twojego bk2patch i dwmw2, nie jako coś zbędnego. Programiści zapewnie uznają łatki z każdego csetu dmwm2'a za coś przydatniejszego, podczas gdy testerzy i zaawansowani użytkownicy, a może nawet opiekunowie kodu, będą preferować codzienne pre-łatki do testów i synchronizacji kodu.

OK. Zdobyłem się na odwagę wydania tego w celach testowych...

klibc jest małym podzestawem biblioteki C przeznaczonym do integracji z drzewem kodu źródłowego jądra oraz do testowania z narzędziami initramfs. Tak więc, initramfs+rootfs mogą być użyte do przeniesienia rzeczy, które obecnie działają w przestrzeni jądra systemu, takie jak autokonfiguracja IP lub główny punkt montowania systemu nfs (tak naprawdę, to główny punkt montowania dla systemu - root) do przestrzeni użytkownika.

Chciałbym ujrzeć komentarze na temat przenośności, ponieważ jestem niezorientowany w architekturach innych niż i386 (czy ktoś nie zechciałby przesłać mi odpowiedniego sprzętu?), ale oczekuję również na raporty o błędach.

ftp://ftp.kernel.org/pub/linux/libs/klibc/klibc.tar.gz

Nie martwiłem się dotychczas o numerowanie wersji, ponieważ kod zmienia sie bardzo szybko. Zamieściłem także repozytorium CVS w katalogu podanym powyżej.

Mówisz o tym, jakby to było złe.

(Oraz niepoprawnie w sensie technicznym, ponieważ, jeżeli dostarczasz pliki .o to użytkownik może je skonsolidować w razie potrzeby.)

Teraz coś z ,,zupełnie innej beczki''. Czy istnieją jakiekolwiek plany wyciągnięcia z jądra kodu opartego na GPL, stworzenia osobnej biblioteki i konsolidowania z nią całej reszty?

Jeżeli wejdzie to do drzewa jądra Linuksa, a na to się zanosi, lecz z licencją 'copycenter', to możemy oczekiwać problemów z nVidią lub jeszcze czegoś gorszego.

Wypuszczenie tego na licencji GPL nie powinno być problemem. To ma być w końcu niewielki kawałek kodu. I nie chciałbym się znaleźć w sytuacji w której ludzie podsyłają swój magiczny ,,działajżeszwreszcie'' kod jako zamknięte poprawki dla wczesnej fazy kodu startowego..

Nie przeszkadza mi dana ludziom wolność w kwestii wyboru najbardziej odpowiadającej im licencji, jak również nie przeszkadza mi użycie GPL kiedy pracuję nad projektem, który aktualnie jest oparty o tę licencję, lecz nie jest to licencja, którą na którą bym postawił, gdybym miał wybierać.

Co do ,,działajżeszwreszcie'' kodu, nic nie jest _TERAZ_ w stanie powstrzymać ludzi od tworzenia takiego czegoś. Nie jestem z tego zbytnio zadowolony, lecz dopóki mówimy o kodzie użytkowników, ten kod:

• musi używać normalnych wywołań systemowych
• nie może być konsolidowany z jakąkolwiek biblioteką, bez względu na to, co dostarcza
• będzie zależny od tych, którzy go tworzą oraz tych, którzy decydują się na jego użycie.

Mówimy o libc. _Nic_ w tym kodzie nie powinno być zmieniane przez niekompetentnych programistów. To jest jak powieść. Ci, którzy nie lubią GPL będą mogli w bardzo prosty sposób zaimplementować wszystkie te funkcje w ich własnym kodzie. Koniec powieści. Jakakolwiek licencja zostanie wybrana, nie powstrzyma to ludzi przed wypuszczaniem ich kodu na licencji, którą preferują.

Istnieje zasadnicza różnica pomiędzy obecną sytuacją z nVidią, Veritas oraz całą resztą ,,zapluskwiaczy'' jądra. _Oni_ chcą więcej, niż tylko dostępu do wywołań systemowych z przestrzeni użytkownika, a jest to zupełnie inny rodzaj zagrożenia. I _to_ jest to, z czym mam problemy. Dużo problemów! Szczególnie, gdy oczekują od nas powstrzymania się od zmian w kodzie jądra, które mogłyby spowodować niepoprawne działanie ich śmieci oraz wtedy, gdy jęczą z powodu zaaplikowanych zmian.

Ludzie muszą mieć prawo do publikowania swojego kodu na licencji, która najbardziej im odpowiada. Teraz, _osobiście_, nie użyłbym programu, gdybym nie miał dostępu do jego kodu źródłowego, poza tymi nielicznymi przypadkami w których wierzę, że autor kodu znajduje się w tych kilku procentach, programistów, którzy *wiedzą* w czym rzecz, bez pomocy z zewnątrz. Lecz nie ma to najmniejszego związku z licencjonowaniem i moralnymi rozważaniami oraz z tym, że wiem jak słabej jakości jest większość obecnie publikowanego oprogramowania.

- Poprawka małej literówki wprowadzonej w 113, która powodowała, że CD-ROM-y nie działały.

- Wyeliminowanie block_ioctl(). Ten kod nie może być współdzielony w sposób zaproponowany w tym pliku. Przeniesiemy to niedługo do właściwego blk_insert_request(). To wyeliminuje ,,pogwałcenie warstwowania'' dokonywane przez _elv_add_request().

- Nie bawmy się destrukcyjnym IRQ w ata_dump().

- Poprawka opóźnień przy szukaniu w ide-cd.c

- Połączenie special_intr() i tcq_nop_intr() w jedną funkcję obsługi przerwania. W ten sposób nie musimy robić żadnego kmalloc, żeby wysłać NOP do napędu w TCQ.

- Wyelimnowanie użycia XXX_handler ze struktury ata_taskfile Teraz zawsze wykrywamy z polecenia, które będzie wykonywane, jaka funkcja obsługi będzie potrzebna. To powoduje, że użycie wskaźnika do funkcji obsługi jest znacznie bardziej przejrzyste.

- Nie przekazujemy plików zadań przez rq->special. Przekazuje się je przez rq->cmd[], tak jak to robią, albo przynajmniej powinny robić, wszystkie urządzenia blokowe. W ten sposób nie przekazujemy już wskaźników do struktur ze stosu lokalnego.

- kod pdc4030 nie ma nic do roboty z normalnymi rzeczami dotyczącymi plików zadań.

Listy elektroniczne, które wymieniłem z Jensem (przekazywane też Marcinowi), potwierdzają, że Jens nie miał na myśli tego, by Marcin przestał być opiekunem IDE, ani nic takiego.

Jens odniósł się do ogólnego kodu urządzeń blokowych, którym się opiekuje (włączając w to elv_add_request i drivers/block/block_ioctl.c, na które to pliki Marcin przesłał łaty dla IDE 115, nie konsultując ich z Jensem).

Osobiście mam nadzieję, że Marcin pozostanie opiekunem IDE. Doprowadzenie IDE do stanu, w którym w ogóle się da opiekować tym kodem, było przejściem przez pole minowe. Czy ktoś inny zrobił to, popełniając mniej błędów? Być może, ale było dużo czasu, żeby zacząć to robić i jakoś nikt się nie podjął. Oczywiście jest tu sytuacja coś za coś, niektórzy, bardziej konserwatywni, mogą mówić, że tu chodzi o oprogramowanie, które kontroluje pracę dysku, ale ogólnie myślę, że ważne żeby wspierać tych, którzy są naprawdę produktywni.

Jeśli jesteś nowy wśród hakerów jądra Linuksa i chcesz przesłać raport o błędzie w jądrze, albo łatkę, ale nie wiesz jak to zrobić, ani _gdzie_ to zgłosić, to zapisz sobie gdzieś ten plik, przyda się w przyszłości.

Przygotowanie raportu o błędzie:

Problemy z kompilacją: zgłoś to, co na wyjściu daje GCC oraz wynik polecenia 'grep '_^CONFIG_' .config'. Oops: zdekoduj go przy pomocy ksymoops. Proces nie do zabicia: Alt-SysRq-T i ksymoops stosowną część. Tak to znaczy, że powinieneś mieć zainstalowane i przetestowane ksymoops, co łatwo zrobić źle. Często też to robiłem.

Więcej info w FAQ dostępnym na http://www.tux.org/lkml/

Przesyłanie raportu o błędzie/łatki:

• Sterowniki niektórych urządzeń mają aktywnych deweloperów, spróbuj najpierw skontaktować się z nimi.
• Jeśli się nie uda, to znajdź opiekuna podsystemu, którego dotyczy raport i wyślij go na jego adres.
• Małe poprawki i uaktualnienia sterowników urządzeń najlepiej kierować do opiekunów podsystmeów i do integratorów ,,małych kawałków''
• Wpisanie Linux kernel mailing list w CC: listu nie boli, ale jeśli w To: nie wpiszesz adresu konkretnego opiekuna, to z wysokim prawdopodobieństwem twoja łata nie zostanie zauważona. Zostałeś ostrzeżony.
• Nie wysłaj tego na raz na wszystkie adresy. To wkurzy wiele osób i w ogóle nie jest użyteczne. To spam.
• NIE podsyłaj małych poprawek Linusowi, on po prostu nie ma szans obsłużyć _wszystkiego_. W końcu dostanie to od opiekunów/integratorów, przesyłaj to co masz przez nich.
• Jeśli twoja łatka jest czymś dużym i nowym, to ogłoś ją na lkml i spróbuj przyciągnąć testerów. Po tym jak zostanie przetestowana i przedyskutowana, możesz oczekiwać, że Linus rozważy jej włączenie do głównego jądra.

Obecni ludzie jądra Linuksa

Zauważcie, że ta lista jest posortowana datami, w odwrotnej kolejności, to znaczy najpierw podaję najnowsze pozycje listy. Oznacza to, że pozycje na samym jej dole mogą być już nieważne :-(

Linux kernel mailing list <linux-kernel@vger.kernel.org>
Wysyłaj tu wszystko, co jest związane z jądrem Linuksa, ale nic poza tym :-)

Ingo Molnar <mingo@elte.hu> [30 lip 2002]
Ingo napisał nowy algorytm szeregujący dla 2.5.

Ralf Baechle <ralf@uni-koblenz.de> [30 lip 2002]
Jestem opiekunem kodu AX.25

Victor Yodaiken <yodaiken@fsmlabs.com> [30 lip 2002]
łatki, uaktualnienia, dodatki, sterowniki RTLinux.
Pisz najpierw na listę: rtl@rtlinux.org

Pavel Machek <pavel@ucw.cz> [27 lip 2002]
Jestem opiekunem sieciowych urządzeń blokowych.
Odwiedź: http://nbd.sf.net.
(patrz: Steven Whitehouse <steve@gw.chygwyn.com> na tej liście)
Pracuję nad programowym zawieszaniem.

William Irwin <wli@holomorphy.com> [02 lip 2002]
Wysyłaj do mnie raporty błędów i/lub prośby o nowe cechy związane z wieloma
zadaniami, rmap, zużycie przestrzeni, alokacje. Biorę udział w
* rmap
* alokacja pamięci
* redukcja przestrzeni zużywanej przez struktury danych (np. struct page)
* problemów pojawiających się przy dużych obciążeniach, w związku z różnymi zadaniami
* nadzorowanie kodu jądra 
Patrz także:
Rik van Riel <riel@surriel.com>
Andrea Arcangeli <andrea@suse.de>
Martin Bligh <Martin.Bligh@us.ibm.com>
Andrew Morton <akpm@zip.com.au>

Dave Jones <davej@suse.de> [23 kwi 2002]
Zbieram różne kawałki i fragmenty kodu do włączenia w 2.5,
szczególnie te małe i trywialne oraz uaktualnienia sterowników.
Przekażę je Linusowi gdy (i jeśli) zostanie udowodnione, że są tego
warte.

Andre Hedrick <andre@linux-ide.org> [09 kwi 2002]
Architekt ATA/ATAPI Storage   [2.0,2.2,2.4]
Deweloper interfejsu HBA
Architekt szeregowego ATA [w przyszłych wersjach]
Członek NCITS komitetu AT-Attachment z prawem głosu

Andrea Arcangeli <andrea@suse.de> [28 mar 2002]
Przysyłajcie mi raporty błędów i łaty dotyczące VM.
W szczególności interesują mnie następujące problemy z VM:
* dużo RAMu i procesorów
* NUMA
* scenariusze z dużym udziałem partycji wymiany
* wydajność przy dużych obciążeniach WE/WY (szególnie, gdy odbywa się
dużo asynchronicznego czyszczenia buforów)
Patrz także: Martin J. Bligh <Martin.Bligh@us.ibm.com>
Piszcie także do:
Arjan van de Ven <arjanv@redhat.com>

Martin J. Bligh <Martin.Bligh@us.ibm.com> [28 mar 2002]
Jestem zainteresowany kwestiami związanymi z VM przy dużej
(>4G przy i386) ilości RAM, wieloma procesorami, NUMA

Steven Whitehouse <steve@chygwyn.com> [27 mar 2002]
Jestem opiekunem stosu sieciowego DECnet w Linuksie
Odwiedź http://www.chygwyn.com/decnet/

Arnaldo Carvalho de Melo <acme@conectiva.com.br> [26 mar 2002]
IPX, 802.2 LLC, NetBEUI, http://kerneljanitors.org,
cyclom2x sync sterownik karty

John Cagle <jcagle@kernel.org> [19 mar 2002]
Obecny opiekun devices.txt, listy przypisanych numerów urządzeń dla
LANANA. Przeczytaj stronę w sieci (www.lanana.org) w celu uzyskania
instrukcji jak przesyłać prośby o nowe numery urządzeń. Prześlij wszystkie
prośby związane z urządzeniami na adres:
<device@lanana.org>.

Tigran Aivazian <tigran@veritas.com>
Jestem autorem i opiekunem systemu plików BFS i sterownika aktualizacji
mikrokodu dla IA32.

Rogier Wolff <R.E.Wolff@BitWizard.nl> [12 mar 2002]
Robię ,,porty szeregowe specialix'':
drivers/char/specialix.c (IO8+)
drivers/char/sx.c        (SX, SI, SIO)
drivers/char/rio/*.c     (RIO)

Martin Dalecki <martin@dalecki.de> [11 mar 2002]
opiekun podsystemu IDE w 2.5
(piszcie też do Vojtecha Pavlika <vojtech@suse.cz>)

Ed Vance <serial24@macrolink.com> [05 mar 2002]
Opiekun podstawowego sterownika szeregowego, serial.c, dla
jąder 2.2 i 2.4. Proszę, przesyłajcie łatki na adres
linux-serial@vger.kernel.org z przetestowanymi poprawkami błędów
albo żeby dodać obsługę nowych urządzeń szeregowych.
Ograniczenia dostępnego czasu. Jeśli nie odpowiadam w ciągu
tygodnia, wrzeszczcie na serial24@macrolink.com

deweloperzy netfilter/iptables <netfilter-devel@lists.samba.org> [23 feb 2002]
Na tę listę, na której są deweloperzy netfilter, proszę zgłaszać
wszystkie problemy związane z netfilter/iptables.
Patrz także: http://www.netfilter.org/contact.html

Hans Reiser <reiser@namesys.com> [16 lut 2002]
Przesyłajcie mi wszystkie łatki dotyczące reiserfs z
cc do reiserfs-dev@namesys.com, a raporty błędów
reiserfs-dev@namesys.com, żądania opłaconej obsługi przesyłajcie
na support@namesys.com po zapłaceniu na
www.namesys.com/support.html,
wszelkie dyskusje (nie raporty błędów, no chyba, że zainteresują większość
osób) ślijcie na reiserfs-list@namesys.com.
Jeśli przez tydzień nie odpowiemy na twoją łatę, krzycz na nas, zasłużyliśmy.
Aby dowiedzieć się więcej o przesyłaniu mam łatek, pracy z nami i naszym
systemie przesyłania i śledzenia łatek obejrzyj naszą stronę na www.namesys.com.

Paul Bristow <paul@paulbristow.net> [16 lut 2002]
Jestem opiekunem sterownika stacji dyskietek na ide
(ATAPI ZIP, LS-120/240 Superdisk, napędy Clik!).

Mike Phillips <phillim2@comcast.net> [15 lut 2002]
Podystem Token ring i sterowniki.

Anton Altaparmakov <aia21@cam.ac.uk> [15 lut 2002]
Jestem gościem od NTFS.

https://bugzilla.redhat.com/bugzilla [14 lut 2002]
Zgłaszanie problemów z jądrami dostarczanymi przez Red Hat.

Alan Cox <alan@lxorguk.ukuu.org.uk> [14 lut 2002]
Opiekun Linuksa 2.2 (jedynie poprawki utrzymaniowe).
Utrzymuję zestawy łatek na nieutrzymywane rzeczy w 2.2/2.4.
Opiekun drzewa 2.4-ac (2.4 z testowanymi rzeczami).
I2O, dźwięk, opiekun 3c501 w 2.2/2.4.

Robert Love <rml@tech9.net> [14 lut 2002]
Wywłaszczalne jądro jest moje.

Deweloperzy ALSA <alsa-devel@alsa-project.org> [12 lut 2002]
Jaroslav Kysela <perex@perex.cz> [12 lut 2002]
Advanced Linux Sound Architecture
Łatki ALSA są dostępne pod adresem:
ftp://ftp.alsa-project.org/pub/kernel-patches/*

Neil Brown <neilb@cse.unsw.edu.au> [08 feb 2002]
Jestem zainteresowany wszystkimi kwestiami, które dotyczą następującego kodu:
serwer NFS    (fs/nfsd/*)
programowego RAID (drivers/md/{md,raid,linear*})
lub innych związanych z tym plików

Maksim Krasnyanskiy <maxk@qualcomm.com> [08 lut 2002]
Jestem autorem i opiekunem podystemu Bluetooth i sterownika urządzenia
Universal TUN/TAP.
Obecnie pracuję głównie nad rzeczami związanymi z Bluetooth.

Rik van Riel <riel@conectiva.com.br> [07 lut 2002]
Przysyłajcie mi, proszę, rzeczy związane z VM, z CC do linux-mm@kvack.org.

Geert Uytterhoeven <geert@linux-m68k.org> [07 lut 2002]
Pracuję nad podystemem bufora ramki, przeniesieniem na m68k (część dotycząca
Amigi) i przeniesieniem na PPC (część CHRP LongTrail).
Niestety, nie mam zbyt wiele wolnego czasu by naprawdę popracować nad tymi
rzeczami. Moja praca zawodowa nie jest związana z Linuksem (na razie :-). Nie
mogę nic obiecać w kwestii mojej wydajności jako opiekuna.

H. Peter Anvin <hpa@zytor.com> [07 lut 2002]
kod uruchamiania dla i386,
protokół startowania dla i386, autofs3,
skompresowane iso9660
(ale przyjmę wszystkie zmiany związane z iso9660);
kierownik stron kernel.org; proszę się ze mną kontaktować
w sprawach związanych ze sponsorowaniem.

administratorzy kernel.org <ftpadmin@kernel.org> [07 lut 2002]
Administratorzy kernel.org. Daj nam znać jeśli coś nie działa, a jeśli
chcesz jakiejś zmiany, to upewnij się, że dajesz nam przynajmniej 1-2 tygodnie.
Zwróć uwagę proszę, że dostajemy dużo próśb o nowości, a dużo z nich
nie daje się pogodzić, albo po prostu nie są praktyczne; nie mamy czasu, by
odpowiadać na wszystkie prośby.

Greg KH <greg@kroah.com> [07 lut 2002]
Jestem opiekunem USB i PCI Hotplug.

Trond Myklebust <trond.myklebust@fys.uio.no> [07 lut 2002]
Jestem opiekunem klienta NFS.

James Simmons <jsimmons@transvirtual.com> [07 lut 2002]
Podsystemy konsoli i bufora ramki.
Bawię się także warstwą wejścia.

Richard Gooch <rgooch@atnf.csiro.au> [07 lut 2002]
Opiekuję się devfs. Chciałbym żeby ludzie umieszczali mnie w Cc:, gdy zgłaszają
problemy z devfs, ponieważ nie czytam wszystkich informacji na linux-kernel.
Przesyłajcie łatki na devfs bezpośrednio do mnie, nie pomijajcie mnie
wysyłając je Linusowi/Marcelo/Alanowi/Dave'owi itp.

Russell King <rmk@arm.linux.org.uk> [06 lut 2002]
Opiekun architektury ARM. Proszę, przesyłajcie mi wszystkie łatki na ARM przez
system łatek dostępny pod adresem:
http://www.arm.linux.org.uk/developer/patches/
Opiekun nowych sterowników portu szeregowego w 2.5.  Przesyłaj łatki na
rmk+serial@arm.linux.org.uk

Andrew Morton <akpm@zip.com.au> [05 lut 2002]
Chłonę wszystkie powtarzalne błędy w całym jądrze 2.4.
Specjalizuję się w ext2, ext3 i sterownikach sieciowych.
Nie myślę o 2.5.x w tej chwili.

Petr Vandrovec <vandrove@vc.cvut.cz> [05 lut 2002]
system plików ncpfs, sterownik bufora ramki dla matrox,
problemy związane z VMware - w 2.2.x, 2.4.x, jak i 2.5.x.

Lista deweloperów reiserfs <reiserfs-dev@namesys.com> [05 lut 2002]
Wysyłaj wszystkie rzeczy związane z reiserfs włączając w to raporty, poprawki,
propozycje, ale też wszystkie inne rzeczy.

Oleg Drokin <green@linuxhacker.ru> [05 lut 2002]
SA11x0 USB-ethernet i SA11x0 watchdog są moje.

Vojtech Pavlik <vojtech@ucw.cz> [05 lut 2002]
Nie wahaj się wysłać mi raportu o błędach i łatek na sterowniki urządzeń wejściowych
(drivers/input/*, drivers/char/joystick/*)
Chciałbym także dostawać raporty o błędach i łatki dla następujących sterowników USB:
printer, acm, catc, hid*, usbmouse, usbkbd, wacom.
Wszystkie inne (spoza listy) zmiany sterowników USB powinny iść do
opiekuna USB (mam nadzieję, że jest jakiś na tej liście :-).
Umieść mnie w CC jeśli wysyłasz informacje związane ze sterownikiem VIA IDE
(jakkolwiek nie jestem opiekunem podystemu IDE).

======= Te pozycje zaproponowali ludzie na lkml ========

Ralf Baechle <ralf@gnu.org> [27 mar 2002]
Jestem opiekunem mips/mips64.

David S. Miller <davem@redhat.com> [07 lut 2002]
Jestem opiekunem Sparc64 i podstaw obsługi sieci.

======= Te napisałem sam ========
======= Czekam na potwierdzenie/poprawki od tych ludzi ========

Urban Widmark <urban@teststation.com> [13 lut 2002]
smbfs

Jeff Garzik <jgarzik@mandrakesoft.com> [12 lut 2002]
Jestem gościem od sterowników kart sieciowych (8139 na przykład).
Umieść mnie i Andrew Mortona <akpm@zip.com.au> w listach dotyczących
łat na sterownik sieci.

Lista dyskusyjna video4linux <video4linux-list@redhat.com> [12 lut 2002]
Gerd Knorr <kraxel@bytesex.org> [12 lut 2002]
video4linux

Tim Waugh <twaugh@redhat.com> [08 lut 2002]
> Kto opiekuje się rzeczami związanymi z linux iomega?
W 2.4.x, ja (teoretycznie). W tej chwili nie mam czasu na 2.5.x.

Alexander Viro <viro@math.psu.edu> [5 lut 2002]
NIE jestem opiekunem podsystemu systemów plików. Ale nie zabiję cię, jeśli
przyślesz mi jakieś raporty błędów generalnie dotyczące fs i (mam nadzieję) łatki.

Eric S. Raymond <esr@thyrsus.com> [5 lut 2002]
Przesyłaj mi raporty błędów i propozycje dotyczące konfiguracji jądra.
Będę też bardziej niż zadowolony, gdy dostanę pozycje ,,pomocy'' dla
opcji konfiguracyjnych jądra (Configure.help)

G?rard Roudier <groudier@free.fr> [5 lut 2002]
Jestem gościem od SCSI.

Jens Axboe <axboe@suse.de> [5 lut 2002]
Jestem opiekunem podsystemu urządzeń blokowych.

Keith Owens <kaos@ocs.com.au> [5 lut 2002]
ksymoops, kbuild, .. .. .. .. .  są moje.

Linus Torvalds <torvalds@transmeta.com> [5 lut 2002]
Nie przysyłaj mi niczego, chyba, że jest to dla 2.5 i dobrze przetestowane,
przedyskutowane na lkml i używane przez znaczącą liczbę ludzi.
Przesyłanie mi małych poprawek i uaktualnień sterowników jest
generalnie złym pomysłem; prześlij je opiekunom podystemów i/lub do integratorów
,,małych rzeczy'' (obecnie jest to
Dave Jones <davej@suse.de>,
zobacz pozycję na tej liście dotyczącą jego). Wybaczcie, nie mogę robić wszystkiego.

Marcelo Tosatti <marcelo@conectiva.com.br> [5 lut 2002]
Nie przysyłaj mi niczego, chyba, że jest to dla 2.4 i dobrze przetestowane.
Jeśli przysyłasz małe poprawki albo aktualizacje sterowników, prześlij kopię
do opiekuna podystemu i/lub do integratorów ,,małych rzeczy'':
- Alan Cox <alan@lxorguk.ukuu.org.uk>,
- Rusty Russell <trivial@rustcorp.com.au>.

Rusty Russell <rusty@rustcorp.com.au> [5 lut 2002]
> Oto pewne poprawki czyszczące kod w...
Chcesz, żeby to dodał do zestawu trywialnych łatek, żeby zostało prześledzone?
Jeśli tak, to pisz (lub wstaw adres w cc:) na trivial@rustcorp.com.au.

Algorytmy alokacji bloków są jednymi z kluczowych rzeczy, które naprawilibyśmy przed wypuszczeniem 2.4, gdybyśmy mieli czas. Ten, który był używany dotychczas jest po prostu strasznie brzydki.

Algorytm alokacji bloków w ReiserFS był kiedyś maksymalnie prosty. Próbował zaalokować blok następny po jego lewym ,,sąsiedzie'', zachowując porzadek drzewa, szukając wolnego bloku - startując od numeru bloku tego ,,sąsiada'' i szukając przeszukując bloki poprzez zwiększanie ich numeru. (Odkryliśmy, że zwiększanie, a nie zmniejszanie tego numeru ma bardzo duże znaczenie dla wydajności.)

Problemy z tym algorytmem pojawiały się gdy nie było wolnych bloków w sąsiedztwie. Przeprowadzał on wtedy liniowy skan bitmapy, a to mogło powodować duże obciążenie CPU, ponieważ sprawdzany był każdy bit. Dodatkowo, jeżeli nie możesz uzyskać wolnego bloku blisko ,,sąsiada'' wtedy powiązanie z ,,sąsiadem'' jest, właściwie, niezbyt dobrą rzeczą, ponieważ oznacza to powiązanie z zapełnioną częścią dysku.

Już dawno temu sugerowałem, by do każdej bitmapy przypisać licznik i nie martwić się o skanowanie bitów gdy jest on równy zero. Nowy kod właśnie to robi.

Dodatkowo, Jeff Mahoney napisał kod, który wybiera losową bitmapę, jeżeli obecna jest pełna i próbuje użyć jej, jeżeli jest zapełniona w mniej, niż w 90%. Teraz jest to domyślne zachowanie kodu. (Oleg przepisał kod Jeffa i straciłem orientację, co do autorstwa poszczególnych jego części.)

Wypróbowaliśmy, także, całą masę innych rzeczy, lecz kod Jeffa/Olega zmniejszał ich użyteczną wartość, ponieważ robią one podobne rzeczy co ich kod, lecz albo w znacznie mniejszym stopniu, albo jako niezamierzony efekt uboczny.

W 2.4 istnieje kod, który pobiera wszystkie sformatowane węzły i próbuje umieścić je w pierwszych 10% dysku. To stawia mnie w nienajlepszej pozycji, ponieważ wartość ,,10%'' jest zakodowana na stałe. Może źle czynię odrzucając to. Potrzebujemy większej liczby eksperymentów, lecz mogę z tym poczekać do 4.1. Zawierają się w tym również przypadki przemieszczania różnych rzeczy w zależności od funkcji haszującej, która kiedyś była zepsuta (można powiedzieć, że nie działała w sposób zgodny z założeniami i umieszczała rzeczy blisko początku dysku przez przypadek i w związku z panującą sytuacją w której numery identyfikacyjne katalogów były mniejsze, niż rozmiar urządzenia wyrażany w ilości bloków). Nie pamiętam czy ta funkcja haszująca została naprawiona w 2.4.19, czy też tylko w naszej łatce.

Sprawdzaliśmy wariant z rozmieszczaniem katalogów losowo na dysku.

Eksperymentowaliśmy z losowym przemieszczaniem katalogów, wystarczająco dużych, by pozostawić niesformatowane węzły (opcja w nowym alokatorze pozwala na przemieszczanie plików większych, niż ustalony z góry rozmiar).

W końcu zdecydowałem, że poprawione skanowanie bitmapy plus unikanie zapełnionych w ponad 90% bitmap, gdy nic w pobliżu nie jest wolne plus zaczynanie od lewego sąsiada jest wystarczająco dobre jak każde inne rozwiązanie, więc uczyniłem to domyślnym zachowaniem, ponieważ wierzę stabilność prostych algorytmów, które w pełni rozumiem.

Domyślne ukierunkowanie kodu albo bardzo różni się od obecnego stanu, albo jest nadrzędne, w zależności od tego o której części kodu mówimy. Nie twierdzę, że znalazłem właściwą odpowiedź, lecz prawdopodobnie znalazłem najlepszą, którą zastosuję w V3.

Prawie wszystko co my, tutaj w Namesys, próbujemy zmienić w V3 jest już napisane i czeka na integrację z jądrami 2.4.20-pre*. Jedyną rzeczą o której wiem, że pozostała i jest nieprzepisana jest prawdopodobnie nawiązanie do polityki konwersji ,,ogona'' z Linuksa 2.2.* (obecny kod jest bardzo nieefektywny w operowaniu ,,ogonem'' i jeden z nas sądzi, że powrót do starej postaci kodu mogłoby przyspieszyć operacje, więc jestem zainteresowany wynikami testów). Będziemy, prawdopodobnie, chcieli usunąć 4k przy okazji kodu czytania lecz najbardziej prawdopodobnym jest zrobienie tego w V4 (Linux 2.5/2.6), a nie w V3.

V3 zmieni się prawdopodobnie w bardzo niewielkim stopniu po 2.4.20, a to jest to, czego nasi użytkownicy potrzebują do czasu ustabilizowania się wersji V4 --- potrzebują czegoś, co, po prostu, działa, nawet, jeżeli nie jest to tak szybkie jak V4.

Niniejsza łata dodaje szkielet dla kart multimedialnych. Została przetestowana z iPAQ H3800 z kartami MMC do przechowywania danych.

Dostęp do informacji potrzebnych do napisania sterownika dla SD lub SDPIO z możliwością zapisu danych w chwili obecnej wymaga podpisania i NDA, które uniemożliwiają opublikowanie sterownika o otwartym kodzie źródłowym, zatem tylko MMC są obecnie obsługiwane.

Oto łata pod 2.5.30 jest ona początkiem konwersji całego kodu USB, aby logicznie i funkcjonalnie używał nowego rdzenia ,,struct device_driver'' Teraz tylko sterowniki HUB i HID są skonwertowane i tylko te będą działać prawidłowo (inne się skompilują, ale żadne urządzenie się pod nie nie podłączy).

Kod jest jeszcze w niedopracowanych kawałkach, ale podstawowe funkcje zdają się działać dobrze (odwołania sterownika, etc.). Jest kilka dodatkowych i specyficznych ulepszeń USB, które musimy zrobić, aby to działało prawidłowo.

Podsystem USB dołącza sterownik tylko do ,,interfejsu'' USB. Urządzenie USB może mieć wiele interfejsów, więc pojedyncze urządzenie może mieć wiele sterowników podłączonych do niego, które obsługują różne rzeczy (pomyślcie o głośniku USB, który ma sterownik dla strumienia audio i sterownik HID do regulacji głośności). Właśnie przez to musiałem utworzyć ,,pusty'' sterownik, który podłączyłem do struktury urządzenia USB. To zapewnia prawidłowe zobrazowanie w drzewie driverfs, więc żaden sterownik USB nie może się do niego podłączyć.

Również reprezentacja driverfs w urządzeniu USB została zmieniona, przypuszczalnie na gorsze. Wypróbujcie tylko łatkę, aby zobaczyć, co mam na myśli :)

Istnieje znany błąd, który zdarza się w put_device(), kiedy urządzenie USB jest usuwane z systemu, ale odpowiednie osoby już o tym wiedzą.

Spostrzeżenia?

Jeżeli nie usłyszę żadnych sprzeciwów, będę pracował nad konwersją wszystkich sterowników USB do tej postaci (sonda i parametry funkcji odłączającej zostały zmienione) i wyślę łatę do Linusa.

Wielkie dzięki dla Pata Mochela za oryginalną wersję tej łatki (poprzednio pod 2.5.15) i poradzenie sobie z tym bałaganem w sterownikach / interfejsach USB.

Ta łata jest dla 2.5.31 rozwiązuje kilka problemów w sterowniku konicawc

• dodano nowy tryb video 160x120
• dodano konicawc_camera_on/off()
• wysyłamy URB-y w kolejności status,dane
• poprawka konicawc_isoc_irq, aby zawsze wysyłała ponownie status, a potem dane URB
• uporządkowano wiadomości podczas śledzenia błędów
• konicawc_compress_iso szuka początku ramki w początkowym obrazie

2.4 IDE zostało przepisane na bazie starego kodu przez Andre Hendricka. Wygląda na to, że Andre, który zdaje się naprawdę rozumieć IDE wraz z jego humorami, jest trudny we współpracy... We wczesnych 2.5 Linus zaczął przyjmowaqć łaty od Marcina (albo Martina) Daleckiego. Od tego czasu, na przestrzeni ponad 115 łat, Marcin przepisuje powoli kod IDE. To spowodowało, że w 2.5 IDE jest raczej niestabilne. W okolicach 2.5.26 Jens Axboe zmęczył się problemami z IDE w 2.5 i przeniósł sterownik z 2.4. Tę zmianę wprowadził do swojego drzewa także Dave Jones - pozwala to testować inne fragmenty jądra w czasie prac Marcina nad czystszym IDE.

IDE 2.5 u jednych jest stabilne, u innych (np. u mnie) -- nie, w zależności od humorów - trzeba koniecznie mieć kopie zapasowe. Jeśli nie chcesz testować IDE z 2.5, użyj -dj (Dave nieco się spóźnia w stosunku do Linusa, a to z powodu pracy i bardzo mu potrzebnych wakacji).

• synchronizacja (2.5.18?) z makrami pte/pfn/page/tlb itd.;
• asm-generic/tlb.h: ładowanie stałej unsigned long do unsigned int tlb->nr wywołuje ostrzeżenia kompilatora na platformach 64 bitowych.
• send_ipi_message() poprawka od Jeffa Wiedemeiera: Algortym IPI 2.5.30 (z to_whom == set test) niepoprawnie wysyła komunikaty IPI do CPU 0 w przypadku systemu SMP działającego z jednym procesorem. W takim wypadku to_whom często równe jest 0 (cpu_present_mask & ~1UL << smp_processor_id()) co powoduje wystąpienie przypadku to_whom == set.
• usunięta migracja IPI;
• Sprzętowe mapowanie cpu_id do logicznego CPU znikło. Zamienione na cpu_online() itp.
• Z powodów historycznych, kawałki w assemblerze dołączały libcowy nagłówek <alpha/regdef.h> celem użycia nazw rejestrów OSF/1 . Z nowym systemem budowy jądra to nie działa. Utworzono własną kopię w <include/asm>.
• Od Jay Estabrook: CIA rev 1 nie może używać DAC i okien 1,2 do SG.
• cli, sti i takie tam znikły;
• irq_smp.c poszło do /dev/null; jedyna pozostałość (synchronize_irq) trafiła do irq.c;
• licznik sprzętowych przerwań w liczniku wywłaszczenia rozszerzono do 12 bitów - jeden więcej niż potrzeba dla wildfire.
• Ogólne obszary per-cpu; obejścia dla procesu uruchamiania SMP
• osf_getrusage() zaktualizowany pod kątem nowych pól utime/stime w task_struct;
• obejścia dotyczące zgodności dla funkcji systemowych readv/writev OSF/1 v4: przeniesione z 2.4.19.
• pcibios_init() musi być typu int;
• fls() - ctlz na ev67, ogólnie na innych. Było to potrzebne wiele wydań jądra temu, teraz wydaje się być nieużywane. Jednakże, nie zaszkodzi, więc zostało włączone.
• brakujące #include, brakujące #if RTC_IRQ w drivers/char/rtc.c;
• zdefiniowane USER_HZ;
• Od Jeffa Wiedemeiera: zmiana nazwy specyficznej dla alphy sekcji konfikuracji 'General setup' na 'System setup', w celu uniknięcia pomyłek z ogólnym 'General setup';
• Od Jeffa Wiedemeiera: poprawione budowanie 'bootpfile'.
• zaimplementowane __down_[read,write]_trylock, __downgrade_write;
• __builtin_expect zamieniony na unlikely().

Hmm. Zmieniłem w tym tygodniu komputery w domu, a ludzie mieli sporo zajęć, sporo rzeczy pewnie zostało opuszczonych.

Sporo jednak zostało włączone, rozmaite architektury nabierają tempa we wprowadzaniu dużych zmian (tlb i irq itd., i rmk stara się wyraźnie zmniejszych swoją łatę arm). Sparc64, alpha, ppc32, ARM..

Seria łat od Ala Viro powinna usunąć blokowanie semaforów, gdy odczytywanie partycji było uruchamiane podczas otwierania nowego urządzenia i powinna przygotować podstawy do większych porządków w opisach dysków.

Uaktualnienia NTFS, JFS, driverfs i sieci. Uaktualnienia sterowników USB, ISDN i sterowników sieciowych, częściowe włączenie akpm (widzieliście dyskusję o odrzuceniu niektórych rzeczy) itd. Zobaczmy także, ile odpadów zostanie po trzydzistobitowych pidach itd.

Umieściłem ostatnie łaty uClinux (bez-MMU) tutaj:

http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.31uc0.patch.gz

Niewiele nowego, po prostu dostosowałem do 2.5.31.

Strona projektu: http://www.csn.ul.ie/~mel/projects/vmregress/
Można ściągać z: http://www.csn.ul.ie/~mel/projects/vmregress/vmregress-0.4.tar.gz

Oto pierwsza udostępniana publicznie wersja VM Regress v0.4 (BumbleBee). Jest początkiem narzędzia do testów regresyjnych, porównawczych i innych dla wirtualnej pamięci w Linuksie. Podana strona sieci zawiera wstęp, a sam projekt zrozumiałą dokumentację i komentarze, więc nie zamierzam tu wnikać w szczegóły.

Wydaje się, że sensowne testy VM i porównania wpływu (pozytywnego lub wręcz przeciwnie) różnych cech VM, są regularnie pojawiającym się problemem. W moim najlepszym przekonaniu istnieje silny związek między testowaniem pod dużymi obciążeniami i intuicyjnymi decyzjami podejmowanymi przez poszczególnych deweloperów jądra, by udowodnić, że VM działa i że jest lepsze od innych implementacji. To narzędzie powinno ostatecznie móc dostarczyć danych empirycznych na temat wydajności VM, oraz służyć jako narzędzie do przeprowadzania testów regresyjnych, by mieć pewność, że zmiany niczego nie psują.

Całość działa przy użyciu modułów jądra tak, żeby dostać dokładny obraz tego, co robi jądro i by dostarczyć wiarygodnych, powtarzalnych testów. Moduły są podzielone na 4 kategorie. Główne moduły dostarczają infrastruktury całemu narzędziu. Moduły czujniki mówią, co się dzieje w VM. Testy testują poszczególne cechy, a moduły porównujące (narazie nie ma żadnego) będą porównywać różne fragmenty VM.

Ostatecznym celem projektu jest wyeliminowanie zgadywania w trakcie rozwijania jądra. Narzędzie będzie umiało definitywnie powiedzieć, czy jakaś cecha działa. Jeśli bedzie działała, to będzie umiało pokazać jak kiepska lub jak dobra jest jej wydajność. Mam nadzieję, że to zastąpi różne skrypty testowe tworzone ad-hoc i dostarczy konkretnych danych na temat wydajności, na które to dane będzie mógł wyprodukować sobie deweloper i używać ich jako dowodu twierdzenia, że ,,Cecha X jest lepsza''.

Interfejs do testów jest udotępniany przez proc w /proc/vmregress. Dla większości z nich pomoc jest dostępna przez wypisanie odpowiedniej informacji po załadowaniu modułów. Plik README i podręcznik systemowy są bardzo zrozumiałe, a każdy plik c ma szczegółowy opis na samej górze, zatem nie będę wnikał w tej wiadomości w drobiazgi. W README znajduje się przykładowy zbiór testów, by zilustrować, jak można użyć tego narzędzia w celu uzyskania użytecznej informacji o wydajności.

Całość została napisana dla 2.4.18 i 2.4.19, ale będzie się kompilować z 2.5.30 i bierze pod uwagę istnienie rmap (będzie się kompilować i działać z lub bez rmap). Pamiętajcie, że temu narzędziu daleko jest do bycia skończonym i narazie czekam na odpowiedzi dotyczące jego sensowności i użyteczności (albo ich braku). W związku z tym, to co jest, robi niewiele. Obecnie:

• Dostarcza infrastruktury, takiej jak funkcje pomocnicze proc, funkcje do przechodzenia po tablicy stron i podobne
• Dostarcza testów interfejsu w /proc w celu zapewnienia, że interfejs ten działa
• Wypisuje sizeof() struktur związanych z VM i wypisuje stopień użycia pamięci
• Wypisuje informacje na temat wszystkich stref w systemie
• Testuje funkcje alokacji/zwalniania fizycznych stron pamięci z flagami GFP_ATOMIC lub GFP_KERNEL
• Testuje procedury błędów stron

Zostało to bardzo mocno przetestowane z UML 2.4.18 i na podwójnym PII350 z jądrem 2.4.19. Wiem, że kompiluje się z 2.5.30, ale nie robiłem narazie żadnego testowania na 2.5 bo brakuje mi komputera do testów. Będzie działało z rmap i bez tej łatki; w trakcie pisania myślałem o niej (jak też o wszystkich innych cechach VM).

To wygląda raczej na mikronarzędzie do testów porównawczych, co jest dobrym początkiem, ale prawdziwym problemem w optymalizacjach VM jest to, że muszą brać pod uwagę obciążenia pojawiające się w rzeczywistości oraz, w szczególności, doświadczenia użytkowników.

Prostym przykładem jest fakt, że nieruszany komputer biurkowy będzie wydawał się bardzo ospały, gdy użytkownik wróci po paru godzinach przerwy, bo wszystkie widoczne programy są wyrzucone z pamięci. Żeby to poprawić, ktoś mógłby pomyśleć o dodaniu do aplikacji flag mówiących ,,związane z interfejsem graficznym''. Taka cecha wymagałaby testów, ale nie stosowałyby się do niej zwykłe mikrotesty porównawcze.

Wydaje mi się za tem, że dobrym pomysłem jest unikanie wprowadzania wolnych operacji między coś, co musi się wykonać szybko, ale to nie pomaga zbytnio deweloperom w rozwiązaniu problemu symulowania obciążeń i mierzenia prawdziwego i interaktywnego przepływu.

Może uda Ci się wziąć to pod uwagę?

Bardziej jestem zainteresowany odpowiedziami na pytania takie jak:

• Czy podsystem X ciągle działa po dokonanych w nim zmianach?
• Jak wydajny jest podsystem X?
• Jak dużo czasu zabiera znalezienie stron do wyswapowania?
• Jak duży narzut wprowadza cecha Y?
• Jak będzie wyglądała przestrzeń procesów po tym jak vmscan zrobi swoje?

Na przykład, za jakiś czas, będę mógł dokładnie powiedzieć jak wydajny jest rmap i porównać go do VM bez rmap w terminach tego, ,,jak dużo czasu zabiera znalezienie strony do wymiany'' i ,,jak wygląda przestrzeń adresowa po tym jak zadziała kswapd''. Na przykład powinienem móc pokazać, że rmap trzyma właściwe strony w pamięci; samo narzędzie do porównań nie powie mi nic nowego. Użyte w połączeniu z narzędziem profilującym, takim jak oprofile, powinno pomóc mi dać bardzo dokładne dane wydajnościowe, które podejrzewam, że będą bardzo użyteczne dla deweloperów, a potem -- dla użytkowników.

Zakładam z góry, że jeśli można pokazać, że każdy składnik działa i ma dobrą wydajność, to całkowita wydajność powinna się poprawić.

Możemy także za bardzo się skupić na rzeczywistych obciążeniach, a przy użyciu takich testów deweloperzy VM nie spędzą swego czasu produktywnie. Deweloperzy muszą używać testów, które skupiają się na bardzo specyficznych aspektach wydajności VM. Jasne, takie testowanie musi być poparte rzeczywistymi testami, żeby potwierdzić to, co deweloperzy myślą, czyli że poprawiona wydajność podsystemu przekłada się na lepszą ogólną wydajność i żeby uważać na niespodziewane i niepożądane interakcje. To się nazywa ,,testy rzeczywiste''.

Jeśli chcesz poprawić ,,wydajność interaktywną'', to znaczy doświadczenia użytkowników, to *skwantyfikuj co się na to składa* i napisz narzędzie do mikropomiaru takich rzeczy. Na przykład opóźnień odpowiedzi na zdarzenia przychodzące z klawiatury przy obciążeniu. To nie wyższa matematyka, to zabiera tylko czas i wymaga trochę wysiłku, żeby tak dobrać takie rzeczy, by były odpowiednie i przewidywalne.

Ciągłe uruchamianie ,,testów rzeczywistych'' bez użycia bardziej precyzyjnych metod mierzenia jest niesamowitą stratą czasu dewelopera. Każdy, kto chce uruchamiać testy rzeczywiste i przesyłać ich wyniki, jest więcej niż mile widziany, a same testy mają wartość. Bezwartościowe jest natomiast obrzucanie błotem narzędzia testującego/dokonującego pomiarów, bo myślisz, że nie jest 'realistyczne'.

Chodzi o to, że deweloperzy potrzebują czegoś do testowania, co mogą ubrać w skrypt i puszczać w nocy. Oglądanie vmstat godzinami nie jest zbyt pożytecznym sposobem na spędzanie czasu dewelopera.

Z drugiej strony, jeśli ktoś może zakodować pewne testy porównawcze, które dają się wyrazić skryptem i które przybliżą rzeczywiste obciążenia lepiej niż to robią obecnie testy porównawcze, to oczywiście docenię taki wysiłek.

Na przykład, do testowania serwowania stron, nie przeszkadzałby mi test porównawczy, który:

1. symuluje pewną liczbę użytkowników, którzy:
1. ładują stronę z 10 lub 20 obrazkami
2. zasypiają na losową liczbę sekund między 3 a 60, ,,czytając stronę''
3. idą za odnośnikiem i ściągają inną stronę z N obrazkami
2. zmienia liczbę użytkowników od 1 do N
3. dokonuje pomiaru
1. czasu odpowiedzi serwera zanim zacznie odpowiadać na żądanie.
2. czasu, jaki zajmuje ściągnięcie każdej strony w całości.

Potem można narysować oba rodzaje czasu odpowiedzi w zależności od liczby użytkowników i w ten sposób mamy obraz wydajności serwowania stron konkretnego systemu... bez skupiania się na, a nawet bez mierzenia nierealnego wskaźnika ,,serwowania N stron na minutę''.

W obszarze VM Regress, bardziej chciałbym dostarczyć testów porównawczych, które będą robiły coś takiego, jak opisano poniżej. (Pamiętajcie, że celem VM Regress jest dostarczenie czegoś więcej niż czystego narzędzia do testów porównawczych. Testy porównawcze stanowią tylko jeden aspekt)

1. Pamięć mapuje przy użyciu MAP_SHARED pewną liczbę regionów
1. Każdy region składa się z 512 stron (2MB na x86)
2. Tworzymy taką liczbę regionów, zanim procent zużytej pamięć nie wpływnie na różne znaki wodne stref
2. Przez ponad jedną godzinę odnosimy się do regionów zgodnie z rozkładem gaussowskim, żeby zasymulować pobieranie popularnych stron i obrazków
3. W końcu daje najlepszy, najgorszy i średni czas czytania regionu. Wypisuje, które regiony ciągle pozostają w pamięci i porównuje to z odwołaniami do regionów. Regiony, do których jest wiele odwołań, powinny ciągle być w pamięci, a martwe regiony na partycji wymiany
4. Powtarzamy test zmieniając następujące parametry:
• Procent zużywanej pamięci fizycznej, by zobaczyć co zostanie wysłane na dysk
• Symulujemy użycie buforów dyskowych zamiast 'mmapowania' regionów

Przy niskim procencie zużywanej fizycznej pamięci nie powinno się nic ciekawego dziać, bo większość rzeczy powinna być wykonywana przy użyciu pamięci podręcznej. Przy większej liczbie regionów, powinno dać się zauważyć jak działa VM, jak dobrze wybiera regiony do przeniesienia na partycję wymiany i jak długo zajmuje znalezienie odpowiednich stron i tak dalej.

Testy porównawcze takiego rodzaju są jeszcze daleko przede mną, ale wykonałem już większość pracy nad modułem fault.o. Robię mmap dla regionu, którego rozmiar jest zależy do wielkości fizycznej pamięci (bardziej precyzyjnie, zależy od znaków wodnych strefy, o której wiem, że zostanie używana w teście) i dostaję się do wszystkich stron tego regionu. Po n przejściach, sprawdzam, czy każda strona jest w pamięci, jeśli została przeniesiona na partycję wymiany, to używam jej, by przywrócić ją z powrotem do pamięci. Wtedy wypisuję liczbę stron, które były przerzucone na dysk, liczbę stron fizycznie obecnych w regionie, oraz czas w milisekundach, jaki zabrało jedno przejście.

To jest większość pracy w tym, zatem nie można tego porównać do delikatnej mgiełki, to raczej naprawdę gęsta mgła. Potrzebuję jeszcze trochę różności, takich jak prezentowanie wykresów obecnych stron w stosunku do odwołań i znaczące dane będą łatwo dostępne.

Od paru miesięcy już zbieram trywialne łatki i przyszedł czas na ustanowienie pewnych zasad:

1. Trywialne łatki, aby były zaakceptowane, muszą należeć do jednej z wymienionych niżej grup:

   1. Poprawki literówek (użyteczne dla grep, dają też dobry przykład)
   2. Poprawki ostrzeżeń (bałagan wywołany bezużytecznymi ostrzeżeniami jest zły)
   3. Poprawki kompilacji (tylko jeśli są naprawdę poprawne)
   4. Poprawki czasu wykonania (tylko jeśli naprawdę coś naprawiają)
   5. Usunięcie zaniechanych funkcji/makr(np. check_region).
   6. Szczegóły na temat kontaktów i poprawki dokumentacji
   7. Nieprzenośny kod zastąpiony przenośnym (nawet w kodzie specyficznym dla architektury, bo ludzie kopiują, przynajmniej tak długo jak jest coś trywialne)
   8. Każda poprawka dokonywana przez autora lub opiekuna pliku (tzn. patch monkey w trybie retransmisji)

   Muszą być one także ,,trywialne'' zgodnie z moją definicją ,,trywialności''. Najlepsze łatki zawierają wystarczająco wiele kontekstu, że mogę je ocenić bez otwierania pliku (diff -C<nn> -u twoim przyjacielem).

   UWAGA: To oznacza też, że poprawki wcięć/białych znaków biorę jedynie od autora lub opiekuna.

2. Łatka nie będzie nikomu przekazana, dopóki nie zostanie opublikowane jakieś nowe jądro, *chyba*, że ktoś inny prześle łatkę. Zatem jeśli w cc: umieszczasz trivial patch monkey, to będzie stamtąd przekazane, jeśli nie trafi do następnego jądra.
3. Za pierwszym razem łatka będzie przesłana do autora i/lub opiekuna. Jeśli powiedzą, że umieszczą ją w swoim drzewie, to nie będzie więcej nikomu przekazana (modulo przeterminowanie). Jeśli oni ją odrzucą, to łatka zostanie zamknięta. W innym wypadku łatka będzie bezpośrednio przesłana Linusowi lub Marcelo w kolejnych przesyłkach (opiekun ciągle będzie umieszczany w cc).

Mam nadzieję, że to będzie dobry kompromis między koordynacją z opiekunami, którzy chcą mieć panowanie nad swoimi plikami, a powstrzymaniem trywialnych łatek od prześlizgiwania się przez różne szczeliny.

Co się dzieje w tym przypadku ..

osoba a przesyła ,,małpie od łatek'' łatkę.
osoba b odpowiada na l-k (umieszczając małpę w cc), że ,,nie rób tego tak''?

czy masz jakiś sposób, żeby powiedzieć ,,ta łatka zamienia poprzednią''?

Naprawdę *dobrą* rzeczą w przypadku, gdy ponowne przesłanie łaty jest konieczne, byłoby, gdyby Alan nie wziął tej łatki do 2.4 (albo ja do 2.5), to mógłbyś dodać nas do kolejnych Cc (i usunąć, w chwili w której Alan/ja byśmy ją wzięli).

To może jednak stać się nie takie proste, bo ta sama łatka może potrzebować trochę ręcznego włączania, tak, by pasowała do -ac/-dj.

Może po prostu łatwiej nas usunąć, gdy Alan lub ja wyślemy ACK?

Dziś została wydana wersja 1.0.21 JFS-a.

Migawka nr 59 z 12 sierpnia 2002 r. jfs-2.4-1.0.21.tar.gz oraz jfsutils-1.0.21.tar.gz) zawiera poprawki systemu plików oraz narzędzi.

Nową właściwością, która pojawiła sią w tym wydaniu, jest możliwość zmiany rozmiaru systemu plików.

Zmiany w narzędziach

• dodana obsługa zewnętrznego logowania dla xpeek
• uaktualnienie fsck.jfs dodające logowanie numeru urządzenia w superbloku po logredo z zewnętrznym logowaniem.
• usunięcie literówki z pliku zawierającego przydatne informacje w awaryjnych sytuacjach. (Bas)
• zaniechanie kompilacji obecnie nieużywanych: defrag oraz narzędzi extendfs
• usunięcie powtórnej definicji uuid powodującej ostrzeżenia kompilatora
• dodanie funkcji typu logsuper do libfs
• poprawki znaków formatujących printf. (Christoph Hellwig)
• czyszczenie kodu (wszyscy)
• uaktualnienie JFS FSIM dla EVMS - zobacz http://sourceforge.net/projects/evms/

Zmiany w systemie plików

• definicja sb_bread dla jąder starszych niż 2.4.18
• dostosowanie kodu do stylu C99 (Christoph Hellwig)
• dodanie do JFS funkcji zmieniającej rozmiar systemu plików. Jest ona dostępna poprzez: mount -oremount,resize=<blocks> Więcej w dokumentacji - Documentation/filesystems/jfs.txt.
• usunięcie wywołań d_delete z jfs_rmdir oraz jfs_unlink
• dynamicznie alokowane struktur metastron. Teraz należy używać pamięci podręcznej slab oraz funkcji pool-a na zarezerwowanych strukturach do operowania strukturami metastron. Jest to zrobione na wzór procedur mempool w jadrach serii 2.5. Poprzednio, tylko ustalona z góry liczba tych struktur była prealokowana. To nie było zbytnio skalowalne.
• Przepisane blokowanie węzłów JFS

Aby dowiedzieć się więcej na temat JFS, zajrzyjcie do instrukcji nakładania łatek lub do plików changelog.jfs.

Po raz n-ty, tu jest łata poprawiająca scheduler, aby wprowadzić poprawne zachowanie SCHED_FIFO i SCHED_RR.

Czekałem na włączenie jej do 2.4.20-pre1, nie ma, 2.4.20-pre2, nie ma...

Proszę, włącz ją