Wstawienie dwóch pętli zawierających “strcmp” powoduje ‚zawieszenie’ się kernela

[overcq]

W tym kodzie menedżera nowo tworzonego systemu plików znajdującego się kernelu Linuksa zakomentowanie linii 3484-3499 powoduje, że działa on poprawnie dla testów tworzenia katalogów i plików, a odkomentowanie powoduje, że kernel się blokuje. Zamieniałem też linie z “strcmp” na

Kod: [Zaznacz]

&& !strncmp( H_oux_E_fs_Q_device_S[ device_i ].directory[ directory_i ].name, name_, n + 1 )

i nadal się blokuje.
Obecnie nie używałem jeszcze nazw plików i katalogów nigdzie oprócz ich zapisu na dysk i wczytywania z dysku; podczas tego drugiego są sprawdzane. Więc nie wiem, gdzie mogłyby zostać uszkodzone. Natomiast “directory_n” i “file_n” są wypisywane podczas zapisu na dysk i są małymi wartościami (mniej niż 10).
Naprawiłem już wiele błędów w tym menedżerze, ale tym razem kompletnie nie wiem, czego szukać. Czy “strcmp” nie może być użyte, a jest używane? Ale jak wyszukałem, to “strcmp” jest używane w innych miejscach w kernelu Linuksa.
Kernel się blokuje tak, jakby się zapętlił. Nie wypisuje żadnego komunikatu błędu.

[Paweł Kraszewski]

Nie będę dywagował o kodzie, bo jest 7 rano w niedzielę, przed kawą.

ALE:

QEMU jest równocześnie hostem debuggera. Jak skompilujesz swojego kernela z DebugInfo to możesz go puścić monitorowanego, z pełną obsługą pułapek, itp.

Jako program monitorujący (GUI do debuggera) najlepiej ze wszystkiego sprawdził mi się QtCreator:

* Uruchamiasz
* Bez tworzenia żadnego projektu wchodzisz w menu "Debug"->"Start debbugging"->"Attach to running debug server".
* Jako "local executable" wskazujesz uruchomiany w QEMU vmlinux (nie vmlinuz!)
* Jako "Working directory" i "Debug information" wskazujesz katalog źródłowy kernela

Ustawisz sobie pułapki na twoje funkcje i zobaczysz pod debuggerem z jakimi rzeczywistymi parametrami odpala się str(n)cmp.

[overcq]

Dzięki za pomoc. Natomiast obecnie mam problem z uruchomieniem w “qemu” minimalnego systemu, ponieważ potrzebuję w nim uruchomić program testujący.
Próbowałem w “qemu” zainstalować na podłączonym dysku “stage3” systemu Gentoo, ale po restarcie nie rozpoznał partycji “root”. Jeszcze raz spróbuję, ale teraz z zewnątrz, spreparować obraz dysku typu “raw” i uruchomić. Lecz to najwcześniej za tydzień.

[Paweł Kraszewski]

Jeszcze raz spróbuję, ale teraz z zewnątrz, spreparować obraz dysku typu “raw” i uruchomić.

Spróbuj zrobić minimalne środowisko testowe na statycznie kompilowanym busyboksie i zrób z niego initrd. Ja tak testuję swoje zabawki (ale wszystkie są czysto tekstowe).
EDIT

Pytanie poza konkursem: dlaczego w ogóle FS zrobiony jako nowe IOCTL-e a nie jako plugin do VFS-a, jak wszystkie inne FSy?

[overcq]

Mam inne założenia niż zuniwersalizowany system plików Linuksa i chcę wykorzystać szybkość tego systemu plików. Na przykład: każdy katalog oraz odrębnie każdy plik ma unikalny identyfikator w całym systemie plików, nie ma odrębnych “inode” na dysku (są tablice katalogów i plików). Stąd wiadomo, że będzie potrzebne inne środowisko użytkownika.

Ogólnie to staram się wydostać z założenia, że wszystko jest plikiem albo że używa się tekstu, i zrobić interfejsy binarne do konkretnych rzeczy, a nie traktowanych tak samo jak coś innego. Ten eksperymentalny system plików to dopiero początek. Jest on zoptymalizowany do jak najrzadszego zapisu metadanych na dysk i wykonywania wszystkiego w pamięci operacyjnej. Poza zapisem zawartości plików, która i tak zdaje się przechodzi przez pamięć podręczną kernela.

Dlatego chcę wykorzystać znajdujące się w kernelu sterowniki fizycznych urządzeń, a wszystko inne pominąć. Po zmianach to już nie będzie Linux. I dlatego to repozytorium nie jest przeznaczone do scalenia z tym, z którego powstał ‘fork’.

[Paweł Kraszewski]

Dlatego chcę wykorzystać znajdujące się w kernelu sterowniki fizycznych urządzeń, a wszystko inne pominąć.

To może zastanów się nad innym "nośnikiem"? Linux ma stopień zaplątania wszystkiego wywalony na 11. Do takich zabaw ciekawszy może być FreeBSD albo wręcz OpenBSD. Pisałem moduły jądra (co prawda głównie sieciowe) i dla Linuksa i dla FreeBSD i Frebzdowe mi się lepiej pisało. Prostszy kod, lepiej skomentowane istniejące rozwiązania.

[overcq]

Utworzyłem pomyślnie środowisko testowe bazujące na “qemu”.
Na dysku typu “raw” będącym plikiem zainstalowałem podstawowy system Gentoo Linux, w którym umieściłem kernel skompilowany na zewnątrz. Natomiast “qemu-system-x86_64” uruchamiam z parametrami, które tworzą prawie identyczną maszynę jak ‘host’, gdzie kompiluję. Dzięki temu nie muszę specjalnie dla kernela działającego w emulatorze włączać dodatkowych opcji poza tymi, których używam w rzeczywistym systemie.
Czyli “qemu” uruchamia system z podłączonego dysku, bez podawania opcji “-kernel” i “-initrd”. I mogę się normalnie w ‘konsoli’ zalogować na konto “root”, gdzie następnie uruchamiam program testujący.

Problemem podczas instalacji tego systemu było użycie przez program tworzący plik konfiguracyjny “grub” nieprawidłowych ‘uuid’ systemów plików będących na “/dev/loop*” w środowisku “chroot”. Musiałem ręcznie poprawić w pliku konfiguracyjnym na zwykłe “/dev/sda3”.

Włączyłem w konfiguracji kernela umieszczenie symboli do ‘debugowania’, z tym że skrypt “gdb” (tworzony poleceniem “make scripts_gdb” w katalogu źródeł kernela) podczas wczytywania do “gdb” wypisuje komunikat:
Python Exception <class 'gdb.error'>: 'hrtimer_resolution' has unknown type; cast it to its declared type
Więc raczej jest bezużyteczny.

Błąd opisywany w pierwszej wiadomości też poprawiłem. Był w innym miejscu niż wskazane pętle. Dodanie tych pętli musiało zmieniać postać wynikowego kodu maszynowego, co powodowało, że błąd się ujawniał.

Natomiast dlaczego modyfikuję kernel Linuksa, a nie systemu z rodziny BSD? Ponieważ ma lepiej działające sterowniki mimo skomplikowania całości.