Kernel Traffic #139 For 29 Oct 2001

Na l-k pojawiło się wiele mylących i świadczących o niedoinformowaniu komentarzy dotyczących MODULE_LICENSE i EXPORT_SYMBOL_GPL. Spróbuję przedstawić to tak prosto jak to tylko możliwe, by poprawić stosunek sygnału do szumu na tej liście.

Proszę się nie trudzić wpisując mnie w cc: w odpowiedziach. Nie interesują mnie także wasze poglądy na temat tego czym jest GPL lub czym powinna być.

MODULE_LICENSE

MODULE_LICENSE() pozwala developerom identyfikować jądra, które zostały napiętnowane modułami, których kod źródłowy nie jest powszechnie dostępny. Brak udostępnionego kodu źródłowego oznacza, że tylko dostawca oprogramowania może pomóc odnaleźć źródło problemu, zatem należy wysyłać raporty producentom, nie na l-k. Precyzyjne określenie, które z oznaczeñ licencji uznamy za wolnodostępne jest cały czas ustalane.

Moduł, który nie ma licencji musi być uważany za moduł należący do producenta. Nie wszystkie istniejące moduły mają już MODULE_LICENSE(), ale wiele z nich ma, a reszta nie zostaje daleko w tyle. Dla kodu, który nie znajduje się w standardowych źródłach jądra, podanie napisu określającego licencję zależy od dostawcy oprogramowania. Dla modułów dystrybuowanych bez kodu źródłowego polecam umieszczenie mniej więcej takiego napisu :-

MODULE_LICENSE("Proprietary. Send bug reports to joe.bloggs@somewhere")

Modutils zaznaczają jądro jako napiętnowane gdy ładowany jest moduł bez zgodnego z GPL MODULE_LICENSE(), zgłaszając napis oznaczający licencję, tak by użytkownicy wiedzieli gdzie mają wysyłać raporty o błędach. Oops zgłasza stan jądra jako napiętnowane. Developerzy jądra mogą decydować czy chcą zajmować się raportami o takich błędach, czy nie. Koniec opowieści.

Ktoś podniósł kwestię konsolidacji z jądrem kodu, będącego czyjąś właśnością. Jeśli kompilujesz i konsolidujesz kod z jądrem i nie dostarczasz kodu źródłowego, to nie możesz rozprowadzać wynikowego jądra. Takie postępowanie jest naruszeniem warunków GPL, przeczytajcie GPL jeśli mi nie wierzycie. Nie ma możliwości, aby powstrzymać Cię od kompilacji twojego własnego jądra w połączeniu z elementami dostarczanymi jedynie w formie binariów i używania go dla własnych celów, ale wszystkie błędy stają się Twoim problemem i nie wolno Ci rozprowadzać wynikowego jądra.

EXPORT_SYMBOL_GPL

Niektórzy developerzy jądra nie są specjalnie szczęśliwi gdy widzą, że dostarczane przez nich zewnętrzne interfejsy ich kodu są używane przez moduły rozprowadzane bez kodu źródłowego. Według nich jest to przywłaszczanie sobie cudzej pracy. Nieważne czy zgadzasz się z takim widzeniem sprawy, osoba, która posiada prawa autorskie decyduje jak może być użyty wynik jej pracy.

EXPORT_SYMBOL_GPL() pozwala zaznaczać nowe interfejsy jako takie, które są dostępne tylko dla modułów na licencji zgodnej z GPL. Jest to niezależne od piętnowania jądra, ale oczywiście opiera się na napisach MODULE_LICENSE().

EXPORT_SYMBOL_GPL() może być użyte tylko dla nowych eksportowanych symboli, o których mówił Linus. Mam nadzieję że ci, którzy zmieniają istniejące eksportowane interfejsy, zostaną nawiedzeni przez zabójcze pingwiny z piłami łañcuchowymi.

To wszystko nie dotyczy i nie może dotyczyć wywołañ systemowych, to kolejny element zakłócający dyskusję. Wszyscy, którzy myślą inaczej -- nie rozumieją GPL. Wywołania systemowe definiują, w jaki sposób kod w trybie użytkownika dociera do jądra, nikt nie uważa, że program w przestrzeni użytkownika, który jest rozprowadzany tylko w formie binariów, nie może używać wywołañ systemowych.

... i jeśli ktoś myśli, ze zamiana

int foo(void *bar);
oraz
EXPORT_SYMBOL(foo);

na

int __foo(void *bar, int baz);
static int foo(void *bar)
{


return __foo(bar, 0);


}
oraz
EXPORT_SYMBOL_GPL(__foo);

uchroni go przed wyżej wspomnianymi zabójczymi pingwinami, niech pamięta, że są gorsze i wolniejsze metody i raczej nie chcielibyście ich poznać z pierwszej ręki.

Licencja BSD bez ogłaszania nie jest uznana za zgodną z GPL w jądrze. Jedynie podwójna BSD/GPL nie powoduje napiętnowania jądra, ponieważ kod jest również dostepny na GPL. Wszyscy wykorzystujący licencję BSD bez ogłaszania do tworzenia modułów dostarczanych bez kodu źródłowego będą napiętnowani.

To powoduje problemy z niektórymi modułami w drzewie jądra, które mają licencję BSD bez ogłaszania. Najlepiej by było, gdyby zmienionoby tę licencję na podwójną BSD/GPL, ale to może okazać się niemożlwe. Ponieważ ich kod źródłowy jest zawsze dostępny, możemy je zamienić na

"BSD bez klauzuli o ogłaszaniu, źródła w drzewie jądra"

i dodać taki napis do listy licencji nie powodujących piętnowania. Kod na BSD bez ogłaszania, który nie jest w drzewie jądra, może zmienić licencjonowanie na licencję podwójną BSD/GPL, albo może być piętnowany, wybór należy do dostawcy kodu.

Poszukuję testerów:

łatki, które umożliwiają zbudowanie w pełni wywłaszczalnego jądra są dostępne pod adresem: http://tech9.net/rml/linux dla jąder 2.4.10, 2.4.12, 2.4.12-ac3 i 2.4.13-pre5.

Cóż to jest:

Wywłaszczalne jądro. Zmniejsza wszelkie opóźnienia w jądrze.

Co nowego:

• synchronizacja z nowymi jądrami
• jeśli HIGHMEM_DEBUG było włączone, licznik wywłaszczeniowy był zwiększany, ale nigdy nie był zmniejszany. To owocowało całkowitym wyłączeniem wywłaszczania.
• jeśli HIGH_DEBUG było wyłaczone, HIGHMEM wykładał system w przypadku, gdy wywłaszczanie było włączane, bez odpowiadającego mu wyłączenia.
• ponowne właczenie kawałka kodu do pgalloc, który wcześniej wyrzuciłem, aby zapobiec powtórnemu wchodzeniu do danych danego procesora

Kilka następnych łat będzie miało na celu zlokalizowanie pozostałych zmiennych per-CPU, które muszą być bezpośrednio blokowane przy wywłaszczaniu.

To już było zgłaszane wcześniej.

n_tty_receive_buf() wkłada znak do kolejki tty i woła con_flush_chars(), które dotyka tty->driver_data.

Problem występuje, gdy jest okno pomiędzy dwiema operacjami, gdzie urządzenie zostanie otwarte (zwłaszcza, gdy znakiem będzie ,,^D''!), a con_close() wyzeruje tty->driver_data. Wówczas wystąpi odwołanie do zerowego wskaźnika.

W zasadzie nie wierzę temu wyjaśnieniu, ponieważ nie zgadzały się czasy operacji -- czytacz nie jest budzony, zanim flush nie jest wywołane. No i z tego powodu niezmiernie trudno jest spowodować wyścig. Przyczyna tkwi raczej gdzie indziej. Ale nieco dogłębniejsze śledztwo powinno wyjaśnić przyczyny.

To raczej kbuild a nie konfigurator potrzebuje takiej możlwości. Mogę to bardzo prosto zrobić w kbuild 2.5, prawie to dodałem za jednym razem. To nie działa, gdy masz zachodzące na siebie łaty: wybierasz jedną konfigurację albo drugą i to działa, wybierasz obie (zakładając, że nie są rozłączne) i nie działa.

Nie mam rozwiązania, a objawy nakładających się łat są gorsze niż problemy, które łaty próbują rozwiązać, więc zostawiłem obsługę łat do 2.5. Możesz używać bliźniaczych drzew, gdy nakładasz nową implementację podsystemu na bazowe jądro, a później przełączać się pomiędzy wersjami, określając, którego drzewa chcesz używać.

http://sourceforge.net/projects/kbuild

Wysłałem identyczne pytanie do opiekuna supermounta ponad sześć miesięcy temu, ale nie dostałem żadnej odpowiedzi. Tak więc uaktualniłem łatę samodzielnie tak, aby działało z wersjami 2.4.2, 2.4.4 i 2.4.5. W pewnym momencie zacząłem używać 2.4.4-ac9, które działa mi bez problemów, ale nie miałem jeszcze czasu przenieść łaty do tego jądra.

Nie mam pojęcia, czy ktoś inny robi cos podobnego. Sam znalazłem tę łatę, jako część standardowego jądra mandrake 7.2 (chyba), ale nie wiem, czy w dalszym ciągu ją mają. Sprawdzę to. W każdym razie, jeśli jeszcze nikt tego nie robi, mogę postarać się zakutualizować łatę do najnowszych dostępnych wersji jądra, także tych z serii -ac i, jeśli mi się uda, kontynuować opiekę nad aktualizacjami. Będę szczęśliwy ponownie mając supermount.

Ponieważ jest to pierwsza część jądra, którą będę aktualizował, chętnie posłuchałbym dobrych rad i odnośników do źródeł, które mogą mi podpowiedzieć, które interfejsy się zmieniły itp. już w trakcie serii 2.4. Pamiętam, że było wiele zmian pomiędzy 2.4.0 i 2.4.4, które wymagały zmiany części kodu, między innymi dlatego, że łata zawierała także trochę zmian w ogólnym kodzie systemów plików (głównie kwestie związane z blokowaniem).