Kernel Traffic #155 For 25 Feb 2002

Nie mówisz chyba poważnie? Prawda? Czyżby jakaś paranoja?

Nie umiesz sobie wyobrazić kogoś, kto już nie pracuje zawodowo jako programista, ale cały czas lubi sobie pohakować? Jeśli jesteś pod wrażeniem szybkości mojej pracy i nie umiesz sobie wyobrazić, ze to co robię, to efekt kilkugodzinnej pracy w domu, to niestety nie mogę Ci pomóc...

PS. Jeśli miałbym jakiś ukryty plan, nie wysyłałbym go z domeny evision, bo wiem co nieco o systemach pocztowych ;-). I starałbym się być uprzejmym i byłbym wazeliniarzem, a tego NA PEWNO nie robię, ty s******

Zdziwiłbym się gdyby okazało się, że nie jest to planowane, ponieważ tux ma znacznie większe możliwości niż khttpd znajdujący się obecnie w jądrze.

Tux zdecydowanie udowodnił swoją wydajność i małe zużycie zasobów.

Sądzę także, że włączenie tuxa do głównego jądra mogłoby dopomóc w jego rozwoju, ponieważ ludzie zaczęliby sobie zdawać sprawę, jakie możliwości, tak naprawdę, daje im tux...

Linus umieścił khttpd w jądrze tuż po dodaniu obsługi sendfile, IIRC mówił coś o tym, że dodając khttpd doda się jedynie parę linii kodu, gdy będzie już sendfile.

jeśli to jest naprawdę małe (IIRC <<100 linii kodu), jest tam jeszcze ponieważ wywalenie tego jest nie warte zachodu.

Chciałbym usłyszeć różne opinie na temat ujednolicenia kluczy w hierarchii /proc względem charakteru przestrzeni. W tej chwili Documentation/filesystems.proc.txt nie sugeruje żadnych standardów nazewnictwa. Np. cat /proc/cpuinfo (część wyniku)

cpu family      : 5
model           : 9
model name      : AMD-K6(tm) 3D+ Processor
stepping        : 1
cpu MHz         : 400.907
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no

Zauważcie, że jest spacja pomiędzy ,,cpu'' i ,,MHz'', czy ,,cpu'' i ,,family'', a nie ma jej pomiędzy ,,fdiv'' a ,,bug'' (_).

Przyczyną, dla której sugerowałbym NIE używania spacji w tym miejscu, jest to, że czyni to łatwiejszym życie programistom, którzy parsują pozycje z /proc. Dokładniej mówiąc, programiści Javy z przyjemnością użyliby /proc/cpuinfo, ale spacja w ,,kluczu'', uniemożliwia użycie java.util.Properties.load().

Osobiście, od DŁUŻSZEGO czasu domagam się, aby w /proc/* wszystkie pozycje były parsowalne, tzn.:

cpu_family=5
model=9
model_name='AMD-K6(tm) 3D+ Processor'

itp. Ilość parsującego kodu z przestrzeni użytkownika, który możnaby wyrzucić jest dość duża, a jednocześnie można by tworzyć dużo prostsze skrypty operujące na tych wartościach.

zamiast tego, to są wszystko ,,śliczne'' pliki, stworzone kodem, który powienien być w przestrzeni użytkownika, a jest w jądrze (tak, to głównie printfy, ale zawsze).

jako opiekun ,,linux_logo'', które ostro (i być może niemądrze) grzebie w /proc/cpuinfo i tego typu rzeczach, powiem, że raczej nie będę skakał z radości z okazji tej szansy.

Pamiętajcie, że jako opiekunowie aplikacji z przestrzeni użytkownika, musimy utrzymywać zgodność ze wszystkimi wersjami, w tym wypadku oznacza to zgodność z /proc/cpuinfo dla wszystkich architektur, i do tego wszystkich jąder wstecz do 1.2.13.

Zatem zmiana /proc/cpuinfo nie uprości kodu w żaden sposób, a tak naprawdę doda jeszcze jeden niekompatybilny z innymi specjalny przypadek.

A ponieważ jądra 2.2 i 2.4 będą obecne jeszcze przez całe wieki, to spowoduje raczej powiększenie, a nie zmniejszenie objętości kodu.

Popieram czyszczenie, o ile jest wykonane prawidłowo. W takim przypadku proszę bardzo, ale nie używajcie argumentu ,,uproszczenia kodu w przestrzeni użytkownika''... bo to kłamstwo ;)

bk send -wgzip_uu -r<rev> - > foo-<rev>.bk

To zrzuci zgzipowany i zuuencodowany zbiór zmian do pliku. Aby to odczytać, odbiorca musi zrobić jedynie ,,| bk receive [repository] -avv''.

Preferowany przeze mnie format do wysyłania CSETów BK jest pokazany poniżej. Dane CSET w tej postaci dodają może 10% objętości dla dużych łat, a w przypadku bardzo małych - podwajają rozmiar. Stworzyłem także wrapper bz64 (bzip2 + base64), który nieco zmiejsza dane CSET, ale jest to użyteczne tylko, jeśli inni deweloperzy używają tego samego wrappera.

#!/bin/sh
# Skrypt formatujący wyjście zbioru zmian BK tak, aby łatwiej było go czytać.
# Andreas Dilger <adilger@turbolabs.com> 13/02/2002

PROG=bksend

usage() {

echo "użycie: $PROG -r<rev>"
echo -e "\tgdzie <rev> jest postaci '1.23', '1.23..', '1.23..1.27',"
echo -e "\tlub '+', aby oznaczyć ostatnią wersję"

exit 1

}

case $1 in
-r) REV=$2; shift ;;
-r*) REV=`echo $1 | sed 's/^-r//'` ;;
*) echo "$PROG: nie podana wersja, raczej tego nie chcesz";;
esac

[ -z "$REV" ] && usage

bk changes -r$REV
bk export -tpatch -du -h -r$REV
echo -e "\n==================================\n\n"
bk send -wgzip_uu -r$REV -

Podczas LinuxWorld w Nowym Jorku rozmawiałem przez kilka minut z Mattem Robinsonem(sp?) o LKCD... odniosłem wrażenie, że ostatnio nastąpiły duże postępy. Do tego pracuje nad tym kilka osób z IBM-a.

Zawsze uważałem, że Linux potrzebuje takich zrzutów o wysokiej jakości w sytuacjach awaryjnych. Jest z tego wiele korzyści, ale te, które mnie osobiście najbardziej interesują to: 1000 razy lepsze raporty błędów, ponieważ dostaniemy o wiele więcej informacji o stanie systemu w momencie awarii.

Zatem mam nadzieję, że Bogowie Pingwina spojrzą przychylnym okiem na LKCD. :)

Rzeczywiście poczyniliśmy duży postęp...

Teraz LKCD obsługuje 2.4.17 i nie powinno być zbyt trudne, aby przenieść go do 2.5.

W przeszłości już pytałem Linusa i innych o włączenie tego do jądra, ale teraz myślę, że w 2.5 taka możliwość naprawdę zasługuje na rozważenie, zwłaszcza, że można to wkompilować w jądro nie włączając go. Czyli, ludzie, którzy chcą tego, mogą sobie to włączyć, ale Ci, którzy nie chcą, nigdy tego nie zobaczą.

Zespół programistów LKCD (w tej chwili ponad 10 inżynierów) jest gotów.

Po pierwsze, od wersji 2.5.5-pre1, jest dostępny aktualny dokument o tym jak przenosić systemy plików z 2.4 na 2.5.<najnowsze>. Lokalizacja:

Documentation/filesystems/porting

BĘDZIE on stale aktualny. Innymi słowy, prześlij zmianę API, która będzie wymagała zmian w systemie plików bez odpowiedniej łaty na ten plik, a ja cię dopadnę i skrzywdzę. Poważnie skrzywdzę.

Ten sam dokument zawiera to ,,co potrzebuję zmienić, by mój system plików nie znajdujący się w drzewie był aktualny''. Śledźcie zatem zmiany.

Zwykle, jeśli zdarzą się zmiany API, osoba, która je robi jest odpowiedzialna za uaktualnianie wszystkich systemów plików w drzewie lub, w ostateczności, ostrzeganie ludzi o popsuciu. Podając listę zepsutych systemów plików.

Aktualnie lista składa się umsdos i intermezzo. Ten pierwszy zostanie naprawiony po kolejnej serii porządków w file_system_type. Drugi jest ofiarą zmian w schemacie blokowania. Pomoc ludziom od intermezzo to niezły pomysł - najlepiej pewnie w formie, która zredukowałaby zależność od bebechów VFSa.

Nowy schemat blokowania jest opisany w Documentation/filesystems/directory-locking. Szczegółowo i z dowodem poprawności.

To nie zmienia tak gwarancji oddzielności systemów plików, zatem, jeśli tylko nie zajmują się one blokowaniem na nietrywialne sposoby (intermezzo był jedynym takim przykładem w drzewie), to nie powinny wymagać zmian. Niektóre rzeczy mogą stać się nawet prostsze (to znaczy w niektórych przypadkach własne blokowanie staje się nadmiarowe i może być zaniechane). Powtórzę, aby poznać szczegóły zmian zobaczcie Documentation/filesystems/porting.

Documentation/filesystems/Locking powoli staje się akutalne. Ciągle brakuje opisu kilku metod na superbloku i naprawdę byłbym wdzięczny, gdyby goście, którzy je wprowadzali udokumentowali je.

Dobry kierunek, Al!

Wszyscy: Czy istnieją jakieś strony w sieci o systemach plików w Linuksie, coś takiego jak Rik ma dla MM/VM?

Tu jest początek, jeśli ktoś chciałby tego używać lub coś dodać:

http://www.osdl.org/archive/rddunlap/linux-fs.html

Shawn Starr używał tej kombinacji.

Jedyny problem jaki znalazł to taki, że XFS i -rmap zmieniają te same pliki z kodem źródłowym, więc musiał łączyć część kodu ręcznie.

Dostosowałem też to do twoich ostatnich zmian z linux.bkbits.net, więc powinieneś móc to po prostu wsadzić do twojego drzewa z:

bk://linuxvm.bkbits.net/linux-2.5-struct_page

Możesz także przejrzeć łatę pod adresem:

http://surriel.com/patches/2.5/2.5.5-p2-struct_page5

Przy okazji, _proszę_ nie róbcie takich rzeczy jak zmienianie bitkeeperowego pliku etc/config. Właśnie teraz twoje pierwsze zbiory zmian są czymś, czego na pewno nie chcę w moim drzewie.

Oczywiście, mogę zrobić ,,bk cset -x'' na tym cholerstwie, ale faktem jest, że nie chcę mieć zupełnie niepotrzebnych ,,powrotów'' w moim drzewie, czy innych podobnych rzeczy. To jest po prostu głupie i powoduje, że historia wersji wygląda nawet mniej czytelnie niż naprawdę jest..

Woooops, probowałem zrobić coś sensownego z tym co widać na linuxvm.bkbits.net, ale nie zdawałem sobie sprawy, że będziesz to wciągał z powrotem do swojego drzewa ;((((

Postaram się nie zrobić więcej tego błędu.

Ponieważ bk nie wydaje mi się pozwalać usuwać rzeczy z historii (prawdopodobnie słusznie), to sądzę, że możesz także zaimportować następującą łatę:

http://surriel.com/patches/2.5/2.5.5-p2-struct_page5

Efektem ubocznym tej łatki jest redukcja całości do jednego zbioru zmian, co nie jest tak do koñca złe, jako że nie potrzebujemy zaśmiecać historii Linuksa wszystkimi mniej ważnymi zmianami tej łatki ;)

Usunąłem z bitkeepera stare (wadliwe) drzewo ze zmianami struktury page i umieściłem nowe w tym samym miejscu... ze wszystkimi zmianami tej struktury umieszczonymi w jedbym zbiorze zmian z komentarzem.

Możesz dokonać synchronizacji z bk://linuxvm.bkbits.net/linux-2.5-struct_page i zobaczysz, że nie ma tam już tej głupiej zmiany w etc/config.

Jeśli wolisz poczekać jeszcze jedną wersję z dodaniem tych zmian, poczekać ze względu na zmiany dokonane przez Ingo i Arjana w pte_highmem, to zrozumiem i po prostu będę cię dręczył przy następnej wersji albo w ogóle kiedyś ;)

Ponieważ obydwaj tañcujecie wokół BK, to mam do was pytanie: mogę sobie wyobrazić, że tego typu cofanie się i posuwanie naprzód będzie się czasem zdarzało, ktoś robi zmianę, a potem Linus (albo ktokolwiek) mówi ,,nie ma mowy'' i deweloper wycofuje się, usuwa zmianę i ją powtarza. To jest w porządku w przypadku Linusa i Rika, bo Linus trzęsie zbiorem zmianem tak samo jak Rik, ale co z innymi, którzy coś wyciągnęli? Te zbiory zmian krążą teraz gdzieś po sieci czekając tylko na wrzucenie z powrotem do drzewa.

To jest sedno moich obiekcji związanych z tematem ,,zmiany porządku wydarzeñ'', który podejmowaliśmy chwilę temu. Możesz zmieniać porządek czego tylko chcesz, ale istnieją kopie niektórych wydarzeñ, które wypływają gdzieś na zewnątrz, ale mogą wrócić.

Dawno temu odbyła się dyskusja na temat czarnej listy zbiorów zmian. Pomysł polegał na tym, że w chwili gdy ktoś chciałby zmienić porządek/coś przepisać/cokolwiek, a twoje zmiany były wyciągnięte/włączone/cokolwiek, to byłoby dobrze móc stwierdzić, być może na jakiejś liście, czy ma się zbiory zmian ze śmietnika.

Moglibyśmy mieć opcję --blacklist, która cofałaby zmiany zaznaczając jednoczęsñie, że ,,nazwy'' wycofywanych zmian powinny być pamiętane w pliku BitKeeper/etc/blacklist. Następny przygotowywany zbiór zmian sprawdzałby ten plik. Warto zauważyć, że każdy zbiór zmian ma unikatową nazwę, która jest używana wewnętrznie, coś na kształt numerów i-węzłów plików. Zatem możemy zapamiętywać te nazwy. Wtedy, jeśli wykonujesz pull albo ktoś robi push, przychodzące zbiory zmian mogą być porównywane z czarną listą i usuwane, gdy zostaną na niej znalezione.

Myślicie, że to byłoby użyteczne? Czy używalibyście tego, gdyby było dostępne?

Po pierwsze, cset -x ma funkcjonalność równoważną do tego co nazwałeś undo -x. Robią to samo. Po drugie, cset -x jest _znacznie_ lepsze. Działa tak samo bez wprowadzania nowych diffów do historii. Weź sobie testowe drzewo, utwórz zbiór zmian, sklonuj to drzewo, zrób cast -x na zbiorze zmian i diffa na plikach historii wersji. Zobaczysz wtedy coś takiego:

^As 00000/00000/00455
^Ad D 1.32 02/02/20 09:50:05 lm 33 32
^Ax 32
^Ac Exclude
^AcC
^AcK50774
^Ae

Linijka ,,^Ax 32'' mówi ,,wyłącz zmianę, której numer seryjny to 32''. Na pliku nie ma żadnych odwrotnych diffów. Znacznie ładniej. Łączenia dzialają tak jak to, zawierają jedynie delty gałęzi.

Wszytko to gubi prawdziwy problem - Linus nie chce mieć historii wersji zaśmieconej czymś takim:

Pomysł 1.

Usuñ pomysł 1.

Pomysł 2.

Usuñ pomysł 2.

Potrzebujemy jakiegoś sposobu, aby pozwolić zmianom dostawać się do sytemu tak, by inni mogli je przeglądać, testować, łączyć z własnymi rzeczami i testować, itp. Ale gdy oni zechcą coś zrobić, musimy mieć sposób na powiedzenie innym ludziom, jakie są ich zbiory zmian.

Jestem otwarty na propozycje, to jest znacznie trudniejszy problem niż się wydaje, ze względu na fakt, że historie wersji są wszędzie replikowane, być może uzupełnione lokalnymi danymi. W odróżnieniu od CVS nie ma jednego miejsca do którego można pójść, wyedytować pliki RCS i wyczyścić niektóre zmiany.