Pisanie wielozadaniowego systemu operacyjnego dla procesora bez MMU


9

Myślałem o napisaniu hobby systemu operacyjnego dla niektórych procesorów ARM. Istnieje wiele popularnych komputerów jednopłytkowych z ARM MPU, więc po prostu chciałem kupić jeden z nich (wybierając jeden z bardziej otwartą dokumentacją). Byłem zaskoczony, gdy dowiedziałem się, że nawet płyty z naprawdę wystarczającą pamięcią nie mają MPU z modułem zarządzania pamięcią.

Ponieważ zawsze pracowałem z procesorami i386 + i nigdy niczym innym (oprócz niektórych PIC Microchip), jestem teraz zdezorientowany i nie jestem pewien, czy można napisać działający system operacyjny, którego funkcjonalność nie byłaby ograniczona w porównaniu do napisanych systemów operacyjnych dla MPU z MMU.

Mógłbym wymyślić kilka rozwiązań dla „zastępowania” lub „symulowania” MMU i mam kilka pytań:

  • W procesorach Intel w trybach 16 i 32-bitowym istnieje sposób użycia segmentów i selektorów segmentów do wykorzystania różnych bloków pamięci do różnych zadań. Oznacza to, że mogłem zmienić przestrzeń pamięci, zmieniając zawartość rejestrów segmentów podczas przełączania zadań na x86. Czy istnieją jakieś ogólne koncepcje segmentacji pamięci, które można by zastosować w architekturze ARM?
  • Wczytując plik obiektu połączonego zamiast pliku wykonywalnego, mogłem używać relokacji (poprawek) lub pozycjonować niezależny kod do wskazywania zadań na fragmentach pamięci w taki sam sposób, jakbym mapował pamięć za pomocą struktur stronicowania. Czy byłoby to wystarczająco skuteczne?
  • Przeczytałem też coś o modułach ochrony pamięci na procesorach ARM. Czy mogą być pomocne?

Czy są jakieś „zwykłe” sposoby zarządzania zadaniami w systemach bez MMU?

Odpowiedzi:


16

W rzeczywistości nie jest tak trudno zaprojektować system operacyjny, który nie wymaga MMU. Jest kilka udogodnień, z którymi trzeba się obejść, ale nic nie do pokonania.

  • Ponieważ różne zadania będą musiały być ładowane pod różnymi adresami, cały kod (z wyjątkiem jądra, biblioteki standardowej i każdego innego kodu, który jest częścią podstawowego środowiska wykonawczego) musi zostać skompilowany jako niezależny od pozycji. Oznacza to względne skoki i podstawowy adres dostępu do sterty przechowywany w rejestrze. Wydanie jednego rejestru jako adresu bazowego może wydawać się kosztowne, jeśli jesteś przyzwyczajony do czterech rejestrów ogólnych x86-32, ale większość współczesnych architektur ma więcej, a nawet 8088 ma rejestry segmentowe właśnie do tego.
  • Architektura podobna do Uniksa musi zostać zmieniona, ponieważ nie można jej zaimplementować fork. W porządku, większość systemów operacyjnych nie ma fork. (Możesz mieć vfork.)
  • Nie można wstępnie przydzielić dużych porcji miejsca bez przydzielenia odpowiedniej pamięci. Oznacza to brak powiększania stosu lub sterty w locie poprzez przydzielanie jednej strony na raz.

Jeśli masz MPU, Twoje zadania można nadal oddzielać jak zwykle w wielozadaniowych systemach operacyjnych. Bez MPU separacja pamięci może być kooperatywna tylko wtedy, gdy pozwalasz zadaniom na wykonanie dowolnego kodu. Jednym ze sposobów uzyskania separacji pamięci bez MPU jest ograniczenie zadań do używania tylko zweryfikowanego kodu na maszynie wirtualnej i wdrożenie ochrony pamięci w oprogramowaniu jako części silnika VM.

uClinux to projekt oparty na jądrze Linux, który działa na procesorach (w tym ARM Cortex-M) bez MMU. Jej ograniczenia wielozadaniowość są w zasadzie to, co opisano powyżej.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.