Moim zdaniem tak, ponieważ tak, ponieważ wszelka użyteczna ekspozycja na świat zewnętrzny (nieuprzywilejowany tryb procesora) wymagałaby najpierw procesu działającego w świecie zewnętrznym. Wymagałoby to systemu plików, nawet tymczasowego systemu plików w pamięci RAM.
Inny inżynier nie zgadza się ze mną, ale nie mogę tego udowodnić poza wszystkimi (nieznanymi mi) przypadkami.
Czy odpowiedź na to pytanie zależy od definicji „biegania”?
filesystems
linux-kernel
Peter L.
źródło
źródło
useful exposure to the outside worldinit(pierwszy proces przestrzeni użytkownika), a to się nie powiedzie.Odpowiedzi:
To raczej dziwne pytanie, ponieważ nie uruchamiasz jądra tak, jak uruchamiasz program. Jądro jest platformą do uruchamiania programów. Oczywiście istnieje kod konfiguracji i zamykania systemu, ale nie jest możliwe samodzielne uruchomienie jądra. Zawsze musi istnieć główny proces „init”. Jądro wpadnie w panikę, jeśli go nie będzie. Jeśli init spróbuje wyjść z jądra, również wpadnie w panikę.
Obecnie proces inicjowania przypomina systemd. Jeśli nie podano inaczej, jądro spróbuje uruchomić program z listy lokalizacji zaczynającej się od
/sbin/init. Zobacz init Param tutaj http://man7.org/linux/man-pages/man7/bootparam.7.html w sytuacji awaryjnej, z którą możesz uruchomić Linuksainit=/bin/bash. Zauważ jednak, że zawsze określasz plik w systemie plików, który chcesz uruchomić.Jądro wpadnie w panikę, jeśli się uruchomi, i nie ma systemu plików, ponieważ bez niego nie ma sposobu na załadowanie init.
Pewne zamieszanie może wynikać z sytuacji kurczaka i jaja, w której jądro musi załadować sterowniki, aby uzyskać dostęp do swojego systemu plików. Aby obejść ten problem, początkowy ramdysk jest ładowany z obrazu na dysku zawierającym niezbędne sterowniki i skrypty instalacyjne. Są one wykonywane przed załadowaniem systemu plików. Ale nie pomylcie się, początkowy ramdysk sam jest systemem plików. Z początkowego ramdysku
/initjest wywoływany (który jest przechowywany na początkowym ramdysku). W wielu dystrybucjach to właśnie wzywa/sbin/init. Ponownie bez systemu plików jest to niemożliwe.źródło
init.$DEV.rcskryptu.Odpowiedź będzie zależeć od tego, czy masz na myśli dosłownie bez systemu plików, czy też pytanie ma być interpretowane nieco inaczej niż to, co zostało powiedziane. Odpowiedzi na niewielkie różnice w interpretacji pytania są następujące:
Powody, dla których musisz przepisać części kodu jądra, aby działający system bez systemu plików to:
execvewywołanie systemowe, które wymaga pliku wykonywalnego z systemu plików.Po uruchomieniu programu
execvemożliwe jest usunięcie mapowania pliku wykonywalnego, z którego został uruchomiony, ale aby to zrobić bez natychmiastowego awarii, najpierw należy utworzyć mapowanie pamięci wykonywalnej, które nie jest zabezpieczone przez plik, i musi zainicjować to pewnym użytecznym kodem przed przejściem do niego i odmapowaniem pliku wykonywalnego.Tak więc działający program w trybie użytkownika może istnieć w stanie, w którym nie ma mapowań pamięci wspieranych przez pliki i może zamykać wszystkie deskryptory plików wspierane przez pliki. Nie może przestać mieć katalogu głównego i bieżącego katalogu roboczego, ale może się od nich powstrzymać.
Więc chociaż w tym stanie można zaimplementować kod jądra, aby zgrać system plików spod programu i nadal go uruchamiać, nie brzmi to tak, jakby było przydatne. A wejście w ten stan końcowy bez przechodzenia przez stan pośredni korzystania z systemu plików będzie jeszcze więcej pracy bez żadnej pożytecznej korzyści.
Przydatna konfiguracja dla niektórych specjalistycznych przypadków użycia
Przydatne może być unikanie korzystania z urządzeń blokowych. Podczas uruchamiania jądro tworzy system plików pamięci i może również zapełnić ten system plików zawartością
cpioarchiwum przed uruchomienieminit. W ten sposób możesz uruchomić system w całości z systemu plików opartego na pamięci, bez żadnego urządzenia blokującego, które by go wspierało.Może to być przydatne w systemach, w których nie chcesz zachować żadnego stanu i na przykład, gdy system uruchamia się z czystej listy po ponownym uruchomieniu.
Oczywiście jądro i archiwum cpio muszą jakoś istnieć w pamięci, zanim jądro przejmie kontrolę. Jak się tam dostali, jest zadanie dla modułu ładującego. Program ładujący mógł załadować je z urządzenia blokowego, nawet jeśli końcowy system nie używa urządzeń blokowych. Ale moduł ładujący może również uzyskać jądro i archiwum cpio bez użycia urządzenia blokowego, na przykład poprzez rozruch przez sieć.
źródło
W Linuksie prawie każde urządzenie jest plikiem , więc musisz mieć system plików, aby go uruchomić.
źródło
eth0,wlan0etc.) nie są, na przykład.Jądro JEST programem, tak jak każdy inny. Domyślnie jądro Linux próbuje uzyskać dostęp do systemu plików, jednak zachowanie to można w trywialny sposób wyeliminować poprzez modyfikację jądra (w rzeczywistości jedynie dodanie funkcji „arch_call_rest_init ()”). W celu wykonania „użytecznej pracy” spodziewamy się, że programista może uwzględnić wątki jądra (kthreads), perhapos w niestandardowym sterowniku, aby wykonać pewne pożądane obciążenie związane z inicjalizacją i typem aplikacji. Jądro Linux zawiera już wiele wątków, ale przede wszystkim do wykonywania prac pomocniczych w stosunku do jądra lub sterowników. Interfejsy API dostępne w kontekście jądra są zupełnie inne niż interfejsy dostępne w przestrzeni użytkownika systemu Linux. Duża część funkcji wywołań systemowych stałaby się bezużyteczna w scenariuszu braku systemu plików.
Tak, Linux domyślnie oczekuje dostępu do systemów plików. Nie, zmodyfikowane jądro z pewnością mogłoby zostać wykonane w celu wykonywania użytecznej pracy bez jakiegokolwiek systemu plików. Praktyczne wykorzystanie systemu plików Linux bez systemu IMO jest dość ograniczone, ale nie ma go wcale. FWIW, w przeszłości wiele jąder czasu rzeczywistego było wbudowanych w tę samą przestrzeń nazw i pliki binarne, co aplikacje RT.
źródło