Instrukcja wezwania przełożonego

Ten artykuł zawiera szczegółowe instrukcje dotyczące komputerów mainframe IBM System/360 i następców oraz kompatybilnych maszyn. Aby zapoznać się z ogólną koncepcją instrukcji wydawania wywołań do systemu operacyjnego, zobacz Wywołanie systemowe .

Instrukcja Supervisor Call ( SVC ) to instrukcja sprzętowa używana przez rodzinę komputerów mainframe IBM System / 360 aż do współczesnych zSeries , Amdahl 470V/5, 470V/6, 470V/7, 470V/8, 580, 5880, 5990M i 5990A i inne; Univac 90/60 , 90/70 i 90/80 i ewentualnie inne; Fujitsu M180 (UP) i M200 (MP) i inne; i jest również używany w komputerze mainframe typu open source Hercules oprogramowanie do emulacji. Powoduje, że przerwanie żąda usługi od systemu operacyjnego . Procedura systemowa dostarczająca usługę jest nazywana procedurą SVC . SVC to wywołanie systemowe .

Racjonalne uzasadnienie

Komputery mainframe IBM z rodziny System/360 i następców działają w jednym z dwóch stanów: stan problemu lub stan nadzorcy oraz w jednym z szesnastu kluczy dostępu do pamięci masowej (od 0 do 15). W stanie problemu dla programu użytkownika dostępny jest duży zestaw nieuprzywilejowanych instrukcji ogólnego przeznaczenia. W stanie nadzorczym programy systemowe mogą dodatkowo korzystać z niewielkiego zestawu uprzywilejowanych instrukcje, które są zasadniczo przeznaczone do pełnienia funkcji nadzorczych. Funkcje te mogą wpływać na innych użytkowników, inne procesory lub cały system komputerowy. W kluczu pamięci 0 program może uzyskać dostęp do całej adresowalnej pamięci, w przeciwnym razie jest ograniczony do obszarów pamięci z pasującym kluczem. Program może uzyskać dostęp do określonych funkcji nadzorczych tylko po dokładnym sprawdzeniu autoryzacji przez system operacyjny: DEBCHK (SVC 117), TESTAUTH (SVC 119) i ewentualnie dodatkowych testach. Programy, które nie zdadzą żadnego z tych testów, są ABENDed, czyli nienormalnie zakończone i natychmiastowego zaprzestania przetwarzania. Niektóre z tych testów nie były dostępne w OS/360, ale zostały dodane w OS/VS1 , SVS lub MVS/370 , ale wszystkie były dostępne w MVS/370 lub kolejnych wydaniach i są nadal dostępne do dnia dzisiejszego.

W OS/VS1 , OS/VS2 (SVS) , MVS/370 i kolejnych wersjach systemu operacyjnego funkcja MODESET (SVC 107) wyeliminowała potrzebę wielu SVC napisanych przez użytkownika, ponieważ ten system SVC uwzględnił obie zmiany w trybie (stan problemu do stanu nadzorcy) i klawisz (8-15 [użytkownik] do 0-7 [system]) w jednej operacji, a wiele SVC napisanych przez użytkownika było pierwotnie przeznaczonych do prostych zmian trybu i klawiszy, a następnie jedynego specjalnego wymagania polegało na tym, że krok zadania był autoryzowany przez APF i że program wywołujący MODESET był rezydentem w konkatenacji bibliotek, z których wszystkie zostały zidentyfikowane jako autoryzowane, a to bezpieczne podejście było całkowicie pod kontrolą instalacji. Takie podejście ogólnie uprościło kontrolę użytkownika nad autoryzacją, chociaż wymagało to pewnych prostych zmian w aplikacji. Ogólnie rzecz biorąc, instalacje użytkowników faworyzowały to podejście, co znacznie poprawiło ogólną niezawodność systemu.

Chociaż aplikacje mainframe są zwykle procesami synchronicznymi , sam system operacyjny jest naturalnie asynchroniczny , chociaż system obsługuje również wiele procesów, które są naturalnie synchroniczne . Gdy aplikacja żąda usługi systemowej, która jest naturalnie asynchroniczna , takich jak przetwarzanie wejścia/wyjścia, musi być zastosowany mechanizm synchronizacji aplikacji i systemu operacyjnego. Ten podstawowy mechanizm jest realizowany za pomocą funkcji wbudowanych w system operacyjny lub obsługiwanych przez system, w tym: CZEKAJ (tymczasowe wstrzymanie przetwarzania aplikacji do momentu wystąpienia zdarzenia zewnętrznego); POST (wskazuje wystąpienie zdarzenia zewnętrznego, aby przetwarzanie aplikacji mogło być kontynuowane); i SYNCH (zmiana trybu przetwarzania systemu — przełożony na użytkownika i klucz systemowy na klucz użytkownika — przy zachowaniu integralności systemu i synchroniczne wykonywanie funkcji w imieniu aplikacji, po czym przetwarzanie nadzorcy może być kontynuowane).

OS /360 SVCs wskazuje warunki, w których można zastosować te funkcje synchronizacji.

Realizacja

SVC to dwubajtowa instrukcja z szesnastkowym kodem operacji 0A ; drugi bajt instrukcji, numer SVC , wskazuje konkretne żądanie. Numer SVC może być dowolną wartością od 0 do 255, przy czym konkretny numer SVC zależy od wykonawcy systemu operacyjnego, np. w MVS IBM, SVC 3 służy do zakończenia programu, podczas gdy w UNIVAC VS / 9 i Fujitsu W tym samym celu wykorzystano systemy operacyjne BS2000, SVC 9.

Gdy program wystawia SVC, następuje przerwanie. PSW, 8-bajtowy (w systemach System 360 i S/370) lub 16-bajtowy (w systemach z/System), uprzywilejowany rejestr zawierający między innymi aktualny adres instrukcji do wykonania, bit uprawnień ( 1, jeśli jest uprzywilejowany) i klucz pamięci są zapisywane pod rzeczywistym adresem. To lokalizacje 32-39 na 360 i 370; 320-335 w z/System. PSW jest następnie ładowane z innego adresu rzeczywistego; to 96-103 na 360 i 370, 448-463 na z/system. Wykonywanie jest wznawiane pod adresem, który został załadowany do PSW. Bity 24-31 zapisanego PSW (rzeczywisty adres 35 w 360 i 370, 323 w z/System) zawierają numer wywoławczy przełożonego.

SVC wywołuje funkcję nadzorczą - zwykle implementowaną jako „zamknięty podprogram” systemu obsługi przerwań SVC . Informacje przekazywane do iz procedur SVC są przekazywane w rejestrach ogólnego przeznaczenia lub w pamięci.

W systemie OS/360 i następcach powrót z procedury SVC jest w przypadku procedur SVC typu 2, 3 i 4 przez wywołanie SVC 3 (EXIT), a w przypadku innych typów SVC przez uprzywilejowaną instrukcję Load PSW (LPSW) , która jest wykonywany w imieniu procedury SVC przez dyspozytora programu sterującego lub procedurę obsługi przerwań SVC.

W systemach operacyjnych innych niż IBM, takich jak MUSIC/SP opracowany przez McGill University w Montrealu w Kanadzie dla komputerów mainframe IBM i dla komputerów mainframe innych niż IBM, VS/9 opracowany przez firmę Univac (z systemu operacyjnego TSOS dla serii RCA Spectra 70 komputery) dla linii komputerów mainframe UNIVAC serii 90 oraz system operacyjny B800 (również opracowany na podstawie systemu operacyjnego TSOS) dla komputerów mainframe Fujitsu , wszystkie używają instrukcji LPSW do wyjścia z połączenia Supervisor.

Wybór, czy wywołanie przełożonego ma powrócić do programu wywołującego bezpośrednio za pomocą instrukcji LPSW, czy też w inny sposób, na przykład polecenie powrotu podprogramu lub samo wywołanie przełożonego, jest kwestią projektową. Nie ma oczywistego „właściwego” sposobu na zrobienie tego; mogą istnieć powody dla obu metod. Użycie instrukcji LPSW do wyjścia z procedury SVC pozwala na szybsze wykonanie, ale oznacza, że ​​faktyczne testowanie procedury musi zostać przeprowadzone na dedykowanej maszynie, na której uruchamiany jest kod w ramach rzeczywistego nadzorcy systemu operacyjnego. Jeśli kod został napisany jako zwykły podprogram, można go przetestować w taki sam sposób, jak każdy zwykły program i potencjalnie wdrożyć bez konieczności jego modyfikacji. Umożliwiłoby to również pomiar wskaźników określających, jak długo procedura wezwania przełożonego zajęła wykonanie zadania, co pozwoliłoby na analizę procedur, których czas wykonania jest zbyt długi (lub bardzo szybki).

W systemie OS/360 i późniejszych wersjach systemu operacyjnego punkty wejścia gałęzi i łącza stanowią alternatywę dla wywołań SVC dla niektórych procedur trybu nadzorcy. W MVS/SP V1R3 i późniejszych wcieleniach systemu operacyjnego wpisy wywołania programu (PC) rozszerzyły SVC do wywołań wielu funkcji nadzorczych zarówno przez autoryzowane, jak i nieautoryzowane programy; a niektóre funkcje mogą być wywoływane tylko przez wpisy gałęzi lub PC, np. STARTIO . (Ma to również tę zaletę, że uniemożliwia uruchamianie systemów operacyjnych IBM na sprzęcie innych producentów).

Różne systemy operacyjne IBM mają niewielką kompatybilność pod względem używanych kodów lub usług nadzorcy, które mogą być wywoływane. Systemy VM/370 i z/VM wykorzystują instrukcję DIAG w podobny sposób, pozostawiając SVC do użytku przez systemy operacyjne działające na maszynach wirtualnych. Większość SVC OS/360 została utrzymana dla „starszych” programów, ale niektóre SVC zostały „rozszerzone” w miarę upływu czasu.

OS/360 i następca systemu SVC

W systemach OS/360 i systemach następczych numery SVC od 0 do około 127 są definiowane przez IBM, a numery od 255 w dół są dostępne do użytku przez programistów systemów instalacji. z / OS zmienił to na numery SVC od 0 do około 200 dla IBM i 255 w dół dla instalacji, ponieważ dodatkowe usługi systemowe, głównie wspierające szyfrowanie / deszyfrowanie, były wdrażane przez IBM przy użyciu SVC. Procedury SVC muszą mieć nazwy modułów w określonym formacie rozpoczynającym się od IGC.

Zgodnie z projektem systemu, termin „wyłączony” oznacza wyłączony dla wszystkich przerw z wyjątkiem przerw w sprawdzaniu komputera w systemach starszych niż MVS/370 oraz z utrzymywaną „lokalną blokadą”, ale nie „wyłączony” dla jakichkolwiek przerw w MVS/370 i wszystkie późniejsze systemy. Pierwsza to blokada fizyczna, druga to blokada logiczna, ponieważ „blokada lokalna” przestrzeni adresowej ma taki sam wpływ na jej przestrzeń adresową, jak blokada fizyczna, ale nie ma wpływu na inne przestrzenie adresowe.

OS/360 zdefiniował cztery typy procedur SVC, zwane „Typem 1” do „Typu 4”; MVS / 370 dodał dodatkowy „Typ 6”, który jest podobny do „Typu 1”, z wyjątkiem tego, że procedura SVC jest fizycznie wyłączona. „Typ 5” nie został zdefiniowany ani wdrożony. Poniższe informacje, będące częścią tabeli dla OS/360, rozszerzonej dla MVS/370 i systemów następczych, dają wyobrażenie o rozważaniach związanych z pisaniem procedury SVC.

Konwencje Typ 1/Typ 6 typ 2 typ 3 typ 4
Część programu kontroli mieszkańców Tak Tak NIE NIE
Rozmiar procedury (OS/360) Każdy Każdy
Pojedynczy moduł ładowania ≤ 1024 bajty
Każdy moduł ładowania ≤ 1024 bajty
Rozmiar procedury (OS/VS1) Każdy Każdy
Pojedynczy moduł ładowania ≤ 2048 bajtów
Każdy moduł obciążenia ≤ 2048 bajtów
Rozmiar rutyny (SVS, MVS) Każdy Każdy Każdy Każdy
Odświeżalny NIE NIE Tak Tak
Powtarzalna rutyna Opcjonalne, ale musi nadawać się do seryjnego ponownego użycia Tak Tak Tak
Może zezwolić na przerwy NIE Tak Tak Tak
Zarejestruj zawartość przy wejściu Rejestry 3, 4, 5, 6, 7 i 14 zawierają wskaźniki komunikacyjne; rejestry 0, 1 i 15 są rejestrami parametrów.
Może zawierać dane przenośne Tak Tak NIE NIE
Może przekazywać kontrolę innym typom procedur SVC Nic Każdy
Może wydać CZEKAJ NIE Tak, używając funkcji „OCZEKAJ” (SVC 1)
Może wystawić POST Tak, ale należy użyć wyłączonego wpisu gałęzi „Opublikuj”. Tak, używając „POST” (SVC 2)
Może zaplanować synchroniczne wyjścia Tak, ale należy użyć wpisu wyłączonej gałęzi „Exit Effector”. Tak, używając „SYNCH” (SVC 12)
Może zaplanować nienormalne zakończenie Tak, użycie wpisu oddziału „Abterm” wyłączyło Tak, używając „ABEND” (SVC 13)
Tabela skondensowana z IBM System / 360 Operating System System Programmer's Guide C28-6550-2

Ograniczenia rozmiaru dla procedur SVC typu 3 i 4 są konieczne, ponieważ są one ładowane do wyznaczonych „obszarów przejściowych” (PLPA w post-MVT) po wywołaniu.

  • Przykładem Typu 1 jest SVC 10, używany zarówno dla GETMAIN, jak i FREEMAIN, który odpowiednio przydziela obszar pamięci głównej do zadania i następnie go zwalnia. SVC 10 jest nieformalnie znany jako „REGMAIN”, ponieważ wymienia parametry tylko za pośrednictwem rejestrów ogólnego przeznaczenia i może przechowywać zarówno GET, jak i FREE. SVC 4 i SVC 5 mogą wykonywać odpowiednio podobne funkcje GET i FREE, ale wymieniają parametry za pośrednictwem list parametrów w pamięci.
  • Przykładem typu 2 jest SVC 42, ATTACH, który tworzy nowe zadanie.
  • Przykładem typu 3 jest SVC 33, IOHALT, który kończy operacje we/wy na urządzeniu innym niż DASD. Ten SVC został zmieniony na typ 2 w OS/VS, ponieważ IOHALT jest intensywnie wykorzystywany w wielu systemach opartych na teleprzetwarzaniu.
  • Przykładem typu 4 jest SVC 19, OPEN, używany do udostępniania zestawu danych do użytku przez program użytkownika, który zawiera moduły wspólne dla wszystkich metod dostępu i wywołuje dodatkowe moduły specyficzne dla każdej metody dostępu . OPEN obsługuje również zestawy danych, które mają być obsługiwane przez metodę dostępu „zmień własną”, taką jak te, do których dostęp uzyskuje się za pomocą EXCP .
  • Przykładem Typu 6 jest SVC 107, MODESET, który nie uzyskuje żadnych blokad, ale jest w stanie zmienić tryb systemu i klucz systemowy, zgodnie z przekazanymi parametrami.

Bezpieczeństwo

OS/360 generalnie nie miał żadnego sposobu na ograniczenie użycia SVC. W rezultacie istniała spora liczba niezamierzonych narażeń na integralność systemu i danych, które były możliwe dzięki zastosowaniu pewnych sekwencji SVC i innych instrukcji. Próby odkrycia tych ekspozycji stały się powszechną praktyką wśród ciekawskich użytkowników, ale niektórzy programiści systemowi używali tych ekspozycji zamiast opracowywać własne SVC napisane przez użytkowników.

Począwszy od MVS / 370, IBM uważał za wadę produktu , jeśli błąd w projekcie systemu pozwoliłby aplikacji na wejście w stan nadzorcy bez autoryzacji. Nakazali, aby wszystkie IBM SVC były chronione, aby zamknąć wszystkie narażenia na integralność systemu i danych. „Gwarantowali” zamykanie takich ekspozycji w miarę ich odnajdywania. Do wydania 3.7 MVS / 370 w 1977 r. Prawie każda taka ekspozycja została rzeczywiście zidentyfikowana i zamknięta, kosztem 100 000 raportów z analizy autoryzowanych programów (APAR) i powiązanych tymczasowych poprawek programu (poprawki PTF). Było to niezwykłe osiągnięcie, ponieważ „czas sprawności” systemu był odtąd mierzony w latach , a nie w dniach czy nawet godzinach .

Notatki

Dalsza lektura

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Supervisor_Call_instruction&oldid=1123222810 ”