Kernel Traffic #162 For 2002/04/15

Pod DOS-em było tak, że pliki ,,.COM'' były ładowane i ,,wykonywane'', nawet jeśli to były pliki tekstowe. Dalej, jeśli mieliśmy do czynienia z plikiem ,,.EXE'', to był on wykonywany jeśli pierwszymi dwoma bajtami było 'MZ', więc mogłeś stworzyć plik tekstowy z pierwszymi dwoma znakami ,,MZ'' i nazwać go ,,CRASH.EXE'', bo to było to, co robił. Wszystkie pliki ,,.BAT'' były interpretowane jako skrypty przez 'COMMAND.COM' -- powłokę. To oznacza, że można stworzyć plik ,,.BAT'' o nazwie ,,COMMAND.BAT'', co może dać ciekawe wyniki.

Gdy FAT-32, NTFS, VFAT, system(y) plików Windozy były rozwijane nie było takich zakładów. Długie nazwy plików są wynikiem przyjęcia pomysłu ,,pojemnika-pliku'' i wszystko idzie.

Zatem jedynym sposobem na zgadnięcie zdolności tego pliku do wykonywania jest odczytanie nazwy -- i to jest złe zgadywanie.

Jeśli pliki NIE są oznaczone jako 'wykonywalne' przy odczycie przez Linuksa, to samba nie zadziała. Aby pliki były widoczne dla klientów WIN, wszystkie bity muszą być ustawione. Ten 'fjuczer' może być użyty, aby pliki DOS/Win mogły być chwilowo niedostępne klientów WIN (jak przy robieniu kopii zapasowej).

Autorzy tego kodu opublikowali go na GPL. Nie masz prawa tego zmieniać. To, co zrobiłeś to to samo, jakby ktoś zabrał cały Twój kod i udostępnił go tylko w formie binariów.

Tym samym:

• rujnujesz system DRM (digital rights management) [5 lat więzienia w USA]
• łamiesz licencję

ale gorsze od tego jest to, że ignorujesz podstawowe prawa moralne autorów tego kodu.

Każda linijka kodu, którą kiedykolwiek przesłałem Linusowi, jest na -czystym- GPL. Nosi nagłówek GPL. W to włączona jest moja część pracy nad vmalloc_to_page. Nigdy nie była ona dostępna modułom nie będącym na GPL. Wziąłeś kod, który jest mój i wielu innych i zrobiłeś z tego bibliotekę dla użytkowników, którzy nie używają GPL. Jeśli użyją go w ten sposób, to pogwałcą prawa autorskie i *dostaną* listy namawiające do zaprzestania takich praktyk.

Wszyscy, którzy używają mojego kodu z jądra z kodem nie będącym na GPL robią to, opierając się o doktrynę prawną, która określa co jest, a co nie jest pracą pochodną i robią to na własną odpowiedzialność prawną. Zabieranie kodu, którego jestem jednym z autorów i sprawianie, że jest on wygodny w używaniu w kodzie nie będącym na GPL dla ludzi takich jak veritas to zupełnie inna sprawa. To po prostu czysta kradzież.

Cóż, nikt z was nie ma racji, bthththt...

Usunięcie .._GPL() w tym przypadku jest poprawne, ale nie z któregokolwiek z wymienionych powodów, ale po prostu dlatego, że nawet Ingo zgodził się, że nie powinno to być _GPL, bo jest pomyślane dla sterowników, które nie powinny wiedzieć nic o wewnętrznych rozwiązaniach w VM. Na GPL lub nie.

Kod ten był przeniesiony z 2.5.x wraz z _GPL, które tam były tylko przez pomyłkę, częściowo dlatego, że nie dostałem uaktualnień od Ingo...

Zatem Linusowi wolno dowolnie wystawiać na zewnątrz to, co stworzyli inni? Sądzę, że musimy zrobić z tym porządek i ustalić, co ludzie uważają za obowiązujące zasady. Jak rozumiem oryginalny kod był:

1. wyłuskany z bttv i jest to kod, który, w części, jest autorstwa mojego i Dave'a M
2. przesłany przez Gerda, który wykonał nad nim dodatkową pracę i utrzymał go jako _GPL, gdy po raz pierwszy go wyeksportował. (w 2.4 ma to znaczenie, jako że mamy interfejsy V4L1 a nie V4L2)

Nie wydaje się by ktoś tu pamiętał o pytaniu o pozwolenie.

Nie.

Ja przesłałem jedynie kod przeniesiony na 2.4.x, a jedynym powodem dla którego wyeksportowałem go jako _GPL było to, że był on _GPL w 2.5.x. Byłoby w bardzo złym stylu gdyby ten symbol był bez _GPL w 2.4, ale z _GPL w 2.5 i mogłoby zdenerwować ludzi, którzy zaczęliby używać tej funkcji w 2.4, a później, że zauważyli, że w 2.5 jest eksportowane z większymi ograniczeniami ...

Z przyjemnością podeślę Marcelo łatkę usuwającą _GPL, gdy tylko to nastąpi w drzewie 2.5 Linusa.

Kod w 2.5.x (który wziąłem do przeniesienia) był przesłany przez Ingo i zaktualizowany przez Linusa, tak mówi lista zmian w moim BK. Ingo oczywiścnie *nie* zrobił prostego kopiuj&wklej kodu Dave'a M z bttv. Funkcja vmalloc_to_page() w 2.5.x obsługuje pte-highmem i jądra z wywłaszczaniem, a tego kodu nigdy nie było w bttv.

Trywialna zmiana modutils, zachowująca zgodność wstecz, tak by EXPORT_SYMBOL_GPL == EXPORT_SYMBOL_INTERNAL.

Kiedy prawnicy i pieniacze zgodzą się co tak naprawdę rozumieją przez EXPORT_SYMBOL_GPL lub jego zastępnik i wszyscy zdecydują jakie to powinno byś słowo kluczowe, to dajcie mi znać, a ja opublikuję nowe modutils. W innym wypadku, nie wciągajcie mnie w wojnę bluzgów.

Spójrzmy najpierw na możliwy projekt, najpierw dla 2.5, potem dla 2.4.

Znaczenie EXPORT_SYMBOL_INTERNAL jest takie, że może być to używane do eksportowania symboli przez podstawowe podsystemy jądra (statyczne lub modularne) do innych podstawowych podsystemów jądra, które mogą być skompilowane jako moduły. Zatem, jeśli jakiś symbol jest eksportowany przez coś, o czym można myśleć jako o ,,podstawowym jądrze'', to powinny go używać tylko moduły, które zgłoszą się jako ,,podstawowe jądro''. Podobnie, jeśli coś jest eksportowane przez sterownik, to tylko moduły blisko związane z tym sterownikiem (dla sterowników podzielonych na wiele modułów) powinny móc go używać.

Innymi słowy, eksportowanie symboli nie powinno być oparte od licencję dla konsumenta, bo jest to technicznie niewłaściwe kryterium.

Implementacja EXPORT_SYMBOL_INTERNAL mogłaby być może wyglądać tak:

EXPORT_SYMBOL_INTERNAL(runqueue_lock, "scheduler");

a odpowiadający moduł, który implementuje ,,scheduler'' może zgłaszać swoje prawa przez:

MODULE_CLASS("scheduler");

Moduł powinien oczywiście móc należeć do wielu klas, to znaczy można by było podać zarówno ,,scheduler'' by skorzystać z runqueue_lock, jak i ,,filesystem'', by mieć get register_filesystem().

Zatem, modutils sprawdzałyby klasy modułu i rozwiązywały lub zabraniały użycia odpowiednich symboli. A EXPORT_SYMBOL(sym) znaczyłby ,,wyłącz sprawdzanie klasy przez modutils dla tego symbolu''.

Nie proponuję wyrzucenia MODULE_LICENSE z .modinfo, tylko, że to nie powinno mieć związku z eksportowaniem symboli (to znaczy powinno funkcjonować tak, jak poleca autor/opis itp).

Dalej, wszystko to co powyżej nie wygląda jak coś, co nadaje się do 2.4, to powinno prawdopodobnie być zaimplementowane w 2.5. Dla 2.4 być może powinna to być po prostu sprawa zmiany obecnej nazwy EXPORT_SYMBOL_GPL na EXPORT_SYMBOL_INTERNAL, co w .kstrtab, w miejsce GPLONLY_ wstawiłoby INTERNAL_. A to co powinno łączyć to z modułem, to nie powinno być MODULE_LICENSE, ale nowe makro:

MODULE_SYMBOLS_INTERNAL;

Moduł, który nie zgłasza żadnych specjalnych żądań (dla zgodności) dostaje jedynie symbole eksportowane przez EXPORT_SYMBOL, a moduł, który chce dostępu do symboli MODULE_SYMBOLS_INTERNAL, dostaje także te wyeksportowane przez EXPORT_SYMBOL_INTERNAL.

Nie powinno być żadnych ,,implikacji wynikających z licencji'', wystarczy po prostu (udokumentowany) fakt, że jeśli ktoś, kto pisze nie-wolny moduł jest na tyle głupi, że używa symboli w swoim module, jego moduł będzie się psuł dużo częściej ze względu na istnienie _i_ semantykę/implementację pozycji eksportowanych tylko ,,wewnętrznie''. Ale to już ich problem -- nie powinniśmy im ani pomagać, ani powstrzymywać ich przed wykonywaniem pracy i zarabianiem na życie. To jest moje zdanie. Jeśli producent ma tyle zasobów, że może ich używać na monitorowanie rozwoju jądra Linuksa (i w ten sposób nie uniknie zaangażowania i _pomocy_ w tym rozwoju!) tak, by być na bieżąco z każdą implementacją wewnętrznych symboli, to w porządku -- nawet lepiej dla Linuksa. Ale jeśli chcą oni pisać stabilne i utrzymywalne moduły, to nigdy nie użyją MODULE_SYMBOLS_INTERNALS. Zawsze powinniśmy przekonywać autorów kodu zamkniętego naszą przewagą technologiczną, zamiast utrudniać im życie podpierając się tym, że pozwolenie na używanie eksportowanych symboli zależy od wybranej licencji.

Proste, etyczne i wszystkim się podoba, albo przynajmniej tym, którzy rozumieją, że uniksowe systemy operacyjne zostały zaprojektowane tak, że powinny wyróżniać się przewagą techniczną zamiast używać marketoidalnej broni (kto mieczem wojuje, ten od miecza ginie).

Tak byłoby _tylko_ przy jeszcze jednej interpretacji GPL. To co jest dziwne z GPL to to, że jest tak wiele jej interpretacji do wyboru :)

Twoja interpretacja jest dobra, a moja nie, więc jak mam cię przekonać? Ale jestem przywiązany do zdania, że twoja interpretacja jest, w pewnym sensie, zła. Nazywając rzeczy po imieniu, w tym sensie, że jest niespójna z podobną sytuacją dotyczącą bibliotek albo nawet wołań systemowych. Nie widzę dlaczego eksportowanie symboli jądra powinno być tak radykalnie różne i ekstremalnie wrażliwe na licencję konsumenta w przypadku niektórych symboli, a w przypadku innych nie...

Tigran, ta różnica jest bardzo, bardzo podstawowa, pomyśl o tym proszę i proszę spróbuj pominąć fakt, że pracujesz dla Veritas. Moduły z wewnątrz jądra, będącego na GPL, to tylko techniczna modularyzacja kompletnej i ujednoliconej pracy, która jest na GPL. Chcielibyśmy by zostało to spójne, chcemy, żeby *nasza* praca była w pełni debugowalna, byśmy byli w stanie oferować wsparcie dla naszych produktów i byśmy mogli rozumieć i rozwijać każdą jego część. Takie są nasze intencje.

w chwili, w której zacząłeś kłócić się o to ,,dlaczego nie możemy po prostu dodać tego zbioru EXPORT-ów i umieścić modułów jedynie binarnych tu i tam'', podważyłeś w gruncie rzeczy naszą wolność do określenia licencji naszej pracy. Psujesz wewnętrzny mechanizm modularyzacji tak, by użyć czegoś w kodzie, którego nie możemy debugować, przeczytać, rozwijać i oferować wsparcia w żaden sensowny sposób. To tak, jakbyś chciał wymienić kernel/sched.o na twoją implementację, dostępną tylko w formie binariów, bez publikacji kodu źródłowego. Jeśli chcesz grać w takie gierki, to musisz zaimplementować także pozostałe 4 miliony linii, nikt cię od tego nie powstrzyma.

wołania systemowe są publikowanym, szanowanym, utrzymywanym interfejsem. Aplikacje z przestrzeni użytkownika są niezależnymi projektami, nie są w żaden sposób pochodnymi jądra, które jest na GPL. Oto wyjątek.

historycznie patrząc, wybraliśmy takie rozwiązanie by dostarczyć różnych typów API mniej lub bardziej wydzielonym fragmentom kodu, takim jak niezależnie rozwijane sterowniki sprzętu nie będące na GPL. Niech cię nie zdziwi fakt, że pewien techniczny mechanizm jest także używany do łączenia na żądanie oddzielnych, mniejszych części jądra.

Wpływ modułów pozostających jedynie w formie binarnej na architekturę jądra nie jest zerowy, ale też niespecjalnie znaczący, więc większość z nas jest po prostu pragmatyczna w tej w kwestii, tak długo, jak długo producenci takich modułów nie nadużywają tego mechanizmu by wpływać na integralność jądra i tworzyć dzieła pochodne bez przestrzegania zasad GPL. I jest jasne, że wewnętrzne symbole to właśnie to: wewnętrzne, część pracy wykonanej nad jądrem. [a bezpośrednim tego wynikiem jest to, że przestrzegane jest GPL.]

Przez ,,nadużycie'' rozumiem na przykład pochodną jądra ze ,,zmodyfikowanym'' schedulerem. W dniu, w którym będzie możliwe umieszczenie sched.o dostępnego jedynie w formie binariów, przestanę robić cokolwiek dla Linuksa. Nie jestem tutaj by rozwijać pewną ,,lekką'' wersję systemu operacyjnego, gdzie wszystkie interesujące rzeczy dzieją się za zamkniętymi drzwiami. Nie jestem też tu by patrzeć jak spada jakość tego systemu powodowana niewprawnym programowaniem w szeroko używanych modułach, które są dystrybuowane jedynie w formie binarnej i nie jest możliwe ich naprawienie.

Zasady GPL chronią teraz naszą pracę przed nadużyciem jej w taki sposób - nielegalne jest dostarczenie sched.o w formie jedynie binarnej i skompilowanie z tego jądra, bo wynikowe jądro jest ciągle całością, a całość musi być na GPL. Równie nielegalne jest wyodrębnienie z końcowego obrazu jądra sched.o i zlinkowanie jądra w trakcie wykonywania ze sched.o dystrybuowanym jedynie w postaci binariów. Tak samo nielegalne jest osiągnięcie tego efektu przez wewnętrzny interfejs modułów.

Pomyśl o tym, każde pojedyncze .o w jądrze Linuksa może być równoważnie opisane w regułach eksportowanych interfejsów modułów, nagłówków będących na GPL i modułów z zamkniętymi źródłami. To jest dobry powód, dla którego GPL zabrania dodawania tak dowolnie zdefiniowanych ,,interfejsów modułów''. Pomyśl o GPL jako o cenie, którą płacisz za to, że możesz używać kodu źródłowego Linuksa i możesz do niego coś przyłączać - nie jesteś w żaden sposób do tego zmuszany.

i nie, nie masz *prawa* dołączać do jądra Linuksa sched.o dostępnego jedynie w formie binariów - nawet jeśli rozwijałeś sched.c ,,osobno'' - i intuicyjnie czuć, że to jest w jakiś sposób zupełnie inna praca, wynik końcowy cały czas jest pochodną jądra. Takie pogwałcenie licencji jest nielegalne w większości krajów, a w części państw jest to nawet przestępstwo.

Po przemyśleniu (i uważnym przeczytaniu twoich wyjaśnień) muszę stwierdzić, że twoje widzenie sprawy jest prawdopodobnie bezpieczniejsze, to znaczy w dłuższym okresie ochrona statusu jądra Linuksa, zgodna z tym co napisałeś, jest dla niego lepsza, nawet jeśli nie jest aż tak ,,miła'' czy ,,dla wszystkich wygodna'' jak schemat o którym ja mówiłem.

Jeśli chodzi o to, co powinno być, a co nie powinno być uważane za pochodną, z twojego listu wynika (i nie sądzę, że jest to złe), że jądro Linuksa jest chronione w taki sposób, by zapewnić to, że ,,interesująca'' funkcjonalność jest w jądrze lub istnieje jako moduł będący na GPL.

Żeby trochę rozjaśnić moje przemyślenia, załóżmy, że nie istnieje system plików z księgowaniem dla Linuksa, który jest na GPL (to znaczy reiserfs, ext3 i inne nagle zniknęły). Wtedy, aby twoje myślenie było spójne, musiałbyś wyłączyć eksportowane interfejsy wymagane dla rozwijania systemu plików z księgowaniem. W innym wypadku, pracowałbyś bowiem nad ,,lekkim'' systemem operacyjnym i ,,interesujące rzeczy działyby się za zamkniętymi drzwiami''. Tak jak powiedziałem to niekoniecznie jest ,,złe'', to znaczy być może dla przetrwania Linuksa byłoby to konieczne i dlatego jestem za tym. Myślałem tylko, że jest w tym coś _technicznie_ nieprzyjemnego czy ,,niewłaściwego''... Być może ,,niewłaściwe'' jest niewłaściwym słowem, ale wiesz o co mi chodzi.

Uwaga na boku: to działa tylko częściowo.

Na przykład, z 297 zbiorów zmian w 2.5.8-pre1, 147 było przysłanymi pocztą łatami (odsetek 50% wydaje się być niezmienny w czasie: około połowa rzeczy, które dostaję to łaty w starym stylu, a połowa to łączenia w BK. Oczywiście, zaletą BK widoczną dla mnie jest to, że łączenia BK w połowie przypadków wymagają _mniej_ niż 50% czasu).

W każdym razie: ze 147 łat, 125 były łączeniami z drzewem Dave'a Jonesa (tylko 123 dało sie włączyć od ręki - dwie łaty wymagały ręcznego poprawiania przez bezpośrednie edytowanie listów).

Z tych 123 zbiorów zmian zaznaczonych jako pochodzące od Dave'a, większość była oczywiście napisana przez innych, a Dave działał tylko jako ich intergrator (co nie jest oczywiście nieważne - 99% tego co ja sam teraz robię to tylko integracja).

Statystyki są zatem zaburzone przez takie szczegóły jak ten - to tylko częściowe wskazanie tego, kto naprawdę _napisał_ łatkę.

(Ta sama prawda dotyczy czasem samych łatek z BK, nie tylko łatek z listów elektronicznych, które dostaję do integratorów takich jak Dave, który wciąż używa diffów przy łączeniu ze mną. To oczywiście zależy od tego, kto i jak stworzył oryginalny zbiór zmian BK).

Myślę, że rozumiem. Jeśli dostajesz łatkę GNU od kogoś takiego jak Dave, który dostaje ją od kogoś innego, to ona pokazuje się jako łatka Dave'a w na twojej liście zmian. Hmm. Nie sądzisz, że warto spróbować i zrobić jakieś dodatkowe parsowanie wiadomości, tak, żeby ustawiać $BK_USER na właściwą osobę, jeśli wiadomość zawiera taką informację. Dave i tak wpisuje takie coś:

Opis łaty...
Pierwotnie pochodzi od Matta Domscha.

Jeśli to trochę sformalizujemy to mamy szansę otrzymać właściwe informacje. Wiem, że to może brzmieć jak napad na czyjeś ego, ale jest dość użyteczne, gdy patrzy się na historię zmian i szuka się, kto coś zrobił, łatwiej jest taką osobę namierzyć i przesłać jej nowe zmiany/sugestie/itp. Tia, to sprawia, że łatwiej jest też dręczyć ich pytaniami, ale to się i tak dzieje.

Czas leci. Uruchomiłem statystyki na drzewie Linusa.

Linus stworzył swoje drzewo 2002-04-03 17:03:45-08:00.

3177 zbiorów zmian (logicznych zmian/łatek/jakkolwiek chcesz je nazywać). 55000 delt w 11832 plikach.

Te informacje w BitKeeperze, to znaczy rzeczy związane ze zbiorami zmian, nieskompresowane zajmują 7MB. Na początku było to około 1.5MB, zatem rośniemy około 3MB miesięcznie, a to jest problem.

Skoro już piszę, oto lista rzeczy, które obecnie nas obchodzą i nad którymi pracujemy dla drzewa jądra Linuksa:

1. Wydajność uaktualnień. Same uaktualnienia się w sumie szybkie, to co boli, to sprawdzanie integralności. Wypuściliśmy już nową wersję, która robi mniej sprawdzeń integralności po włączeniu partial_check: yes w pliku konfiguracyjnym.
2. Narzut przestrzeni dyskowej. Struktury danych trzymające dane zbiorów zmian nie skalują się wystarczająco dobrze, a my wiemy jak to poprawić.
3. LODy. Rozważaliśmy dyskusje, które wystąpiły tutaj i dotyczyły całego: ,,chcę mieć ludzi, którzy to przetestują, więc to musi być w BK, ale później chcę to wyrzucić z BK''. Mamy taki projekt LOD, że staje się to możliwe i daje nazwane pojemniki dla każdego opiekuna, pozwala wybierać coś ze środka, itp.
4. Zagnieżdżone repozytoria. To da możliwość pocięcia jądra i trzymania na dysku tylko jego części, tych, które są naprawdę potrzebne, taka jest przynajmniej teoria. Mamy klientów komercyjnych, którzy tego naprawdę chcą, a sądzę, że dla jądra to także będzie użyteczne.

To są te najważniejsze i wystarczy nam zajęcia na przynajmniej kilka następnych miesięcy.