Kernel Traffic #165 For 2002/05/06

There were 396 different contributors. 196 posted more than once. 128 posted last week too.

W trakcie debaty na temat obecności BitKeepera w dokumentacji jądra powiedziano parę interesujących rzeczy na całkiem inny temat. Alexander Viro napisał: "Wątpię, aby całkowite porzucenie -pre na rzecz dziennych migawek było dobrym pomysłem - wolę ,,2.5.N-preM daje oopsa, gdy ...'' niż ,,migawka RR/MM/DD daje oopsa, gdy ...'', po prostu dlatego, że łatwiej w ten sposób dopasowywać raporty błędów. Możliwość ściągnięcia wszelkich delt w formie diff+komentarz jest cudowna, ale nie zastępuje dobrze zdefiniowanych (i rzadziej się pojawiających) momentów synchronizacji." Rob Landley powiedział, "Te dobrze zdefiniowane momenty synchronizacji to wersje 2.5.N. Jeśli pozbędziemy się -pre, to wersje ,,kropkowane'' być może będą musiały się pojawiać w mniejszych odstępach, to wszystko." Linus Torvalds zaś odpowiedział:

Zgadzam się.

Powiedziałem kiedyś sobie, że nie powinienem był w ogóle wypuszczać wersji ,,-preX'' w serii 2.5.x - ,,prawdziwe'' numery wersji rozmywają się wtedy, ale podejrzewam, że wersje -pre pojawiły się po prostu dlatego, że przyzwyczaiłem się do nich w trakcie zbyt długiego czasu opieki nad 2.4.x.

Z punktu widzenia dewelopera, myślę, że osobiście wolałbym mieć codzienne wersje przy większej częstotliwości ,,prawdziwych'' wersji. Ale obecnie (gdy nie jest to zautomatyzowane), codzienne wersje kosztowałyby wiele pracy..

Wierzę, że wersje -pre są ciągle ważne. Codzienne migawki są częściej zepsute, a ,,prawdziwe'' wersje różnią się od wersji -pre (a różnica jest *użyteczna*): możesz zignorować wersję -pre, ale nie możesz ignorować prawdziwych wersji (bo prawdziwe wersje dają się porównywać).

Miło by było, gdyby finalne wersje ukazywały się troszkę częściej, ale nie sądzę, aby wykonalne było tak częste ich wypuszczanie, jak to zwykle jest z łatkami -pre.

Linus napisał, że spróbowałby poprawić częstość ukazywania się prawdziwych wersji. Dodał:

Biorąc pod uwagę to, jak często nawet końcowe wersje w drzewie rozwojowym nie działają (nie mam tu na myśli takich _trywialnych_ awarii, jak zatosowanie tej samej łaty do init/main.c dwa razy, mówię o bardziej fundamentalnych błędach, takich jak zepsute sterowniki lub systemy plików), nie jestem pewien, czy to taki wielki problem.

I robię pełne tary końcowych wersji, tak żeby ludzie mogli opuścić trochę (chociaż jeśli nie masz szybkiego łącza, to zwykle warto to zrobić tylko po opuszczeniu mniej więcej 10 pełnych wersji).

W innym miejscu pojawił się inny temat. W trakcie dyskusji na temat Linux Kernel FAQ, Richard Gooch (opiekun FAQ), obiecał dodać odnośnik do strony Free Software Foundation opisującej wolne oprogramowanie. Ale Linus powiedział:

Nie róbcie tego, proszę.

Nie chcę żeby kernel howto cytowało FSF.

Richard odparł: "Już to robi, od lat. Czy to się podoba, czy nie, pewne pytania/problemy *są* podnoszone. Jeśli FAQ może objąć przynajmniej niektóre, to oszczędza pasma na tej liście." Ktoś inny spekulował, że Linus ,,nie chciał wprowadzać stanowiska FSF, w świetle którego oprogramowanie musi być etycznie poprawne''. Na to Linus odpowiedział: "Racja. Poza tym, ponieważ całe pojęcie ,,wolnego oprogramowania'' ma niewielki związek z jądrem, proszę odnoście się do jakichś stron open source. Jedna z bardziej neutralnych to na przykład ,,http://www.debian.org/social_contract.html''. "

Wiem, że to już było dyskutowane do znudzenia, ale składam teraz formalną prośbę o włączenie XFS do głównego jądra. My (The Sloan Digital Sky Survey) i wiele, wiele innych grup tu w Fermilab, będziemy bardzo szczęśliwi, gdy zobaczymy to w głównym drzewie.

Obecnie SDSS ma ~20TB dysków obsługiwanych przez XFS, z czego większość znajduje się na naszych 14 systemach plików i bazach danych. W eksperymencie D-Zero bierze udział ~140 stacji roboczych z XFS i kilkoma serwerami plików XFS. Używamy tego od momentu ukazania się i wydaje się nam, że jest bardzo sprawne.

Daniel Phillips zauważył: "Problem tkwi w tym, jak prywatne części XFS, które powinny należeć do ogólnego kodu vfs, będą pasować do reszty jądra." A Wichert Akkerman spytał: "Czy zostało już stwierdzone, że XFS jest stabilny jak skała i zgodny z POSIX w swoim zachowaniu? Pytam dlatego, że XFS wydaje się być dość często powtarzającym się czynnikiem przy zgłoszeniach błędów stronicowania w dpkg. Problemy są niezwykle rzadkie (i niepowtarzalne), więc nie mogę tego udowodnić, ale wątpliwości mam cały czas." Kilka osób przedyskutowało możliwości XFS, dochodząc do ogólnego wniosku, że XFS jest tak dobry, jak każdy inny dostępny system plików. W pewnym momencie Luigi Genoni powiedział:

włączenie XFS do drzewa 2.5 przypuszczalnie sprawi, że więcej osób zacznie go używać, a co za tym idzie pozwoli znaleźć więcej błędów, zgłosić je, czasem naprawić. W ten sposób XFS będzie poprawiał się szybciej i oczywiście to będzie dobra rzecz.

Innymi słowy, warto poznać techniczne powody za i przeciw włączaniu XFS do 2.5; czy włączenie może spowodować jakieś problemy, czy XFS spełnia wymagania stawiane łatom przez Linusa i jaki wpływ będzie miało włączenie na jądro (włączenie JFS jest dobrym przykładem łatwego włączenia z niewielkimi następstwami).

Kilka osób przedyskutowało perspektywę włączenia XFS do 2.5, gdzie większość z nich zgodziła się co do tego, że to jest w porządku, ale nie powinno się go włączać do 2.4, ponieważ to by była zbyt duża zmiana, jak na serię stabilną. W pewnym momencie Daniel powiedział: "To jest zwyczajnie kwestia tego, że nikt nie wykonał potrzebnej analizy, aby znaleźć dobry sposób na pogodzenie sposobu działania XFS z vfs z jądra. Taka praca zajmuje dużo czasu i wymaga dużych umiejętności, a w tej chwili jest też sporo innych projektów z tej samej kategorii."

NTFS 2.0.2 dla jądra 2.5.9 jest już dostępne. To jest mała aktualizacja, głównie dostosowująca łatkę do jądra 2.5.9. Zmieniłem też domyślną maskę dla plików na 0177, co oznacza, że pliki nie będą domyślnie wykonywalne. Większość użytkowników tak woli. Również poprawki mniejszych błędów. Zalecam aktualizację, która jest niezbędna w przypadku, gdy używacie jądra 2.5.9. Łata będzie działać również z 2.5.7, ale może się nie aplikować czysto i być może będziecie musieli sami wykonać kilka małych i oczywistych poprawek.

Łaty dla jądra 2.5.9 możecie pobrać z Sourceforge:

http://linux-ntfs.sf.net/downloads.html

I oczywiście możecie użyć BitKeepera, aby skorzystać z naszego repozytorium BitKeeperowego pod: http://linux-ntfs.bkbits.net/ntfs-tng-2.5

Repozytorium można przeglądać on-line pod adresem: http://linux-ntfs.bkbits.net:8080/ntfs-tng-2.5

Erik Andersen spytał, czy Anton zamierza przenieść łaty do 2.4, a Anton odparł:

Nie w tej chwili. W ogóle to tak, ale teraz jest wiele innych rzeczy do wykonania.

Ale właśnie dziś ktoś się ze mną skontaktował i może być on zainteresowany wykonaniem przeniesienia do 2.4...

Anton Blanchard podesłał łatkę zmieniającą zmienną ze static inline na extern inline, pisząc: "Zauważyłem, że w jądrze na ppc64, skompilowanym gcc 3.1, context_switch został wyjęty z kolejki. Zakończył się poza miejscami scheduling_functions_start_here/end_here, a to psuło wchan. Jest jedno miejsce, w którym wymagamy, by kod był ,,inline''. więc powinniśmy użyć ,,extern''. " Linus Torvalds twardo odpowiedział:

ABSOLUTNIE NIE!

,,extern inline'' nie gwarantuje rozwijania w miejscu wywołania. To tylko gwarantuje, że _jeśli_ kod nie jest inline, to nie będzie też skompilowany jako statyczna funkcja.

Złóż zażalenie do ludzi od gcc, to oni zrobili coś niezgodnego z poprzednimi wersjami, co nazwali ,,always_inline'' czy jakoś tak i najwyraźniej nie ma sposobu, by dowiedzieć się czy jest to obsługiwane, czy nie.

To dlatego wszystko oprócz INLINE lub _INLINE (zależnie czy w Makefile czy w nagłówku) nie działa. Każdy kompilator chce teraz czego innego. Zatem, tak jak to jest wymagane, mamy jedno z:

#define INLINE inline /* rozsądnie! */
#define INLINE extern inline /* oksymoron */
#define INLINE static inline /* kolejny oksymoron */
#define INLINE __forceinline
#define INLINE __attribute__((always_inline))
#define INLINE inline_me_harder
#define INLINE inline_this_or_I_shove_it_up_your_gnu

BTW, powiedziałem to w trakcie konwersji ,,extern inline'' na ,,static inline''.

IMHO ,,extern inline'' oraz ,,static inline'' są oksymoronami i, choć tak nie było w głupim standardzie C99, powinny produkować informację o błędzie. Mają taki sens jak ,,extern static''. Jeśli kompilator nie może rozwinąć czegoś w miejscu wywołania, co jest zaznaczone jako inline, to też powinien być błąd. O tak.

Właśnie ukończyłem wersję 0.0.6 Linux-LDM, które obsługuje dynamiczne dyski Windows. Windows 2000 i XP mają nowy system partycjonowania do obsługi dynamicznych woluminów.

Źródła mogą być pobrane ze stron projektu:

http://linux-ntfs.sourceforge.net/downloads.html

Ta wersja powinna być dość stabilna, ale jeśli będziecie mieć jakieś problemy, dajcie mi znać. Jeśli nie będzie żadnych zgłoszeń, rozważę wymianę starego sterownika (2.4.10+) na ten.

Ktoś prywatnie spytał, czy byłoby możliwe wykorzystanie tej łaty do przekształcenia dynamicznych dysków na zwykłe dyski, a Richard odpowiedział na liście: "Łata LDM pozwala jedynie na rozumienie nowego schematu partycjonowania Windows przez jądro. Bez tego zobaczysz jedynie jedną DUŻĄ partycję typu 0x42. Jeśli masz jedynie zwykłe dyski na dynamicznym dysku, nie powinno być zbyt trudnym przekształcenie dynamicznego dysku w zwykły. Jednak nie mamy jeszcze narzędzia do tego."

John Tyner podesłał łatkę obsługującą układ AMD AM29F040B flash w jądrach 2.4, ale David Woodhouse odparł: "Ten chip jest już obsługiwany w kodzie z CVS. Plan na dziś jest taki, żeby poczekać na publikację 2.4.19, wysłać obecny kod Marcelo do dołączenia do 2.4.20-pre1, a potem zobaczyć co popsuło się w 2.5, naprawić i wysłać wyniki Linusowi. "

Uaktualniłem moją łatę, która pozwala na podmontowanie dowolnej liczby woluminów. Stara wersja była do 2.4.9 i nie aplikowała się do nowych jąder. Podzieliłem to na łatę z nienazwanymi numerami głównymi urządzeń i na łatę dla NFS. Usunąłem też opcję CONFIG_, bo przez nią kod był brzydszy.

Część z numerami głównymi: http://people.redhat.com/zaitcev/linux/linux-2.4.19-pre7-unmaj.diff

Część dla NFS: http://people.redhat.com/zaitcev/linux/linux-2.4.19-pre7-nores.diff

Łata dla NFS w przestrzeni użytkownika: http://people.redhat.com/zaitcev/linux/util-linux-2.11q-nores1.diff

Czy ktoś jest właściwie zainteresowany tą łatą? Różne osoby, co jakiś czas proszą mnie o łaty, dostają je i znikają w nicości. Nie słyszę żadnych pochwał ani krytyk (no, nic od czasu, gdy kilka miesięcy temu przejrzał to Trond, a ktoś inny znalazł konflikt z kodem serwera NFS). Myślę o zgłoszeniu jej do włączenia, ale skoro nikt tego nie używa, to po co dodawać dodatkowy kod i jeszcze negocjować z LANANA...

Panu Matilainen zauważył: "Mam kilku użytkowników, którzy ,,potrzebują'' takiej funkcjonalności i jest ona włączona do opracowanych przez nas, opartych na RH, jąder. To, że jest to oddzielna łata dla 2.4 nie stanowi problemu, a mam nadzieję, że w 2.5 będziemy mieli w końcu 32-bitowe numery urządzeń..." Pete odparł: "Pamiętaj, że dajemy tylko tę część z numerami urządzeń, a nie tę dla NFS. Nie słyszałem nic od opiekuna util-linux o koniecznych zmianach w mount(), więc byłbym ostrożny przy robieniu tego." , a Panu odrzekł: "Jasne, wiem o tym. W tych przypadkach jednak zwiększenie limitu z 255 do mniej więcej 800 jest zupełnie wystarczające, więc łata do mount nie jest nawet potrzebna."

Christoph Lameter narzekał, że 2.5.10-dj1 nawet się nie kompiluje. Dave Jones podał odnośnik do swojego wyjaśnienia, dlaczego niektóre rzeczy zostały wyłączone (w tym wypadku -- obsługa błędów SCSI), ale Christoph odparł: "Takie rzeczy mogą być użyteczne w CVS, czy w BK(). Ale jaki jest cel publikowania paczek z jądrem, które się nawet nie kompiluje? Paczki z jądrem są do tego, aby je kompilować i testować..." Jerry McBride zgodził się z tym w całej rozciągłości, ale Anton Altaparmakov wyjaśnił:

Po pierwsze, to jest rozwojowe jądro, co oznacza, że może się nie kompilować, może nie działać, czy nawet gorzej -- może zniszczyć Twoje dane.

Po drugie, jądro będzie się kompilowało poprawnie, dopóki nie zaczniesz używać jakichś w danej chwili zepsutych rzeczy. Puste stwierdzenie ,,jądro się nie kompiluje'' jest często nieprawidłowe i zamiast tego powinno się użyć ,,jądro się nie kompiluje razem z moim .config''.

Do tego jest seria rozwojowa jądra... Warstwa urządzeń blokowych była ,,zwalona'', gdy Jens nad nią pracował we wczesnych 2.5.x, teraz IDE jest ,,zwalone'', a scsi dołącza do tego grona. (-;

Jeśli chcesz jądra, które będzie się kompilowało, powinieneś używać 2.4.x albo 2.2.x...

Przeszliśmy ~7 pełnych wydań jądra bez żadnych aktualizacji w kodzie obsługi błędów w niektórych sterownikach. Ponieważ niektórzy opiekunowie czekają aż warstwa urządzeń blokowych i warstwa pośrednia scsi w jakiś sposób się ustabilizują, używanie tych sterowników bez /żadnej/ obsługi błędów jest kuszeniem losu i czekaniem na katastofę.

Eksperymenty z nowymi cechami systemów plików będą ciężkie do śledzenia, jeśli nie będzie można ufać sterownikom scsi.

Jeśli opiekunowie nadal będą czekać aż 2.5 się jakoś uspokoi, to przynajmniej zmusi to zainteresowanych do ubrudzenia rąk i własnoręcznego poprawienia części, których potrzebują.

Gdy Christoph po raz pierwszy przysłał mi łatę, rozważałem oznaczenie tego, jako CONFIG_DEBUG_BROKEN_SCSI_DRIVERS, czy coś w tym stylu. Teraz dostałem tyle zgłoszeń, że ,,xxx jest zepsute'', że na pewno zrobię to w -dj2.

Pavel Machek przesłał na listę łatkę mime-encoded, a Stelian Pop skierował go do 'Documentation/SubmittingPatches' w źródłach, w którym to pliku napisano, że wszystkie łatki powinny być przesyłane czystym tekstem. Ale Alan Cox odpowiedział: "To są tylko preferencje Linusa. Wiele osób spośród nas woli dostawać takie rzeczy w załącznikach, bo w ten sposób istnieją szanse, że klient poczty ich nie zje. " David S. Miller dodał, że on woli łatki przesyłane czystym tekstem.

Murtada Shah zapytał: "Chciałbym przyspieszyć sterowniki i2c w jądrze Linuksa. Teraz działają one przy 10Khz, ale i2c może wyciągnąć 100. Czy ktoś mógłby mnie jakoś nakierować w tej kwestii?" Yves Rutschle odpowiedział:

Zajrzyj do drivers/i2c/*

Szczegóły zależą od tego, jakiego algorytmu używa twój interfejs. Na przykład dla algorytmu ,,bitbanging'', informacja na temat czasów jest zakodowana w ostatnich parametrach struktury i2c_algo_bit_data.

Zatem, i2c normalnie i automatycznie zwalnia tak, by dostosować się do najwolniejszego urządzenia na magistrali, więc być może te 10Khz, które widzisz nie zależy od sterownika z jądra.

Frank Schaefer zapytał, którego kompilatora powinien używać do budowania testowych jąder. Gabor Kerenyi odpowiedział: "Używam 2.95.2 na testowej maszynie i gcc-3.1 z cvs-a na innych. Nie mam problemów. gcc-3.1 daje tylko trochę więcej ostrzeżeń. (W domu też używam 3.1) ale nie próbuj używać gcc 3.2, bo w niektórych przypadkach jądro się nie skompiluje. " Roy Sigurd Karlsbakk spytał: "Czy to jest jakaś wiedza powszechna? Czy 3.1 jest tak stabilne, jak 2.95.[23]? by kompilować nim jądro? Czy jest jakaś różnica w wydajności? " Christian Borntraeger zaś powiedział:

Niezupełnie.

http://www.tux.org/lkml/#s8-2

Gcc 2.95.3 jest rekomendowanym kompilatorem dla jąder 2.4.10 i późniejszych.


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

1.	19 kwi 2002 - 28 kwi 2002	(348 posts)	Filozofia rozwijania niestabilnego jądra; komentarze Linusa na temat FSF
2.	22 kwi 2002 - 24 kwi 2002	(21 posts)	Stan włączania XFS do 2.5
3.	24 kwi 2002	(3 posts)	Stan obsługi NTFS w jądrach 2.4 i 2.5
4.	24 kwi 2002 - 25 kwi 2002	(5 posts)	Zła interakcja jądra z GCC
5.	25 kwi 2002 - 30 kwi 2002	(2 posts)	Stan obsługi dynamicznych dysków Windows
6.	25 kwi 2002	(2 posts)	Stan obsługi układu AMD AM29F040B flash
7.	25 kwi 2002 - 28 kwi 2002	(4 posts)	Stan łaty pozwalającej na montowanie wielu woluminów
8.	27 kwi 2002	(9 posts)	Natura jąder rozwojowych
9.	28 kwi 2002 - 29 kwi 2002	(5 posts)	Dyskusja na temat polityki przesyłania łat
10.	29 kwi 2002	(2 posts)	Przyspieszanie sterowników i2c
11.	30 kwi 2002	(5 posts)	Jakiego kompilatora używać do kompilowania jądra?

Kernel Traffic #165 For 2002/05/06

By Zack Brown

Translated By: Maja Królikowska and Paweł Kot