1.3 Concepte principale
Interfata intre SO si Programele utilizaotr se determina prin setul de "instructiuni extinse" oferite de SO. Traditional aceste instructiuni se numesc apeluri de sistem. Pentru a intelege posibilitatile SO, trebuie de studiat aceasta interfata. Apelurile de sistem se pot imparti in doua categorii:
1- apeluri pentru lucru cu procesele
2 - apeluri pentru lucru cu sistemul de fisiere
1.3.1 Procese
Cuvintul cheie in SO este - proces. Proces - este programa in momentul executiei. Cu fiecare proces este legat saptiul de adrese al acestuia (lista de adrese in memorie de la un oarecare minimum(de obicei zero) pina la un oarecare maximum), pe care procesul le poate citi si in care poate scrie. Spatiul de adrese contine programa, datele si stiva programei. Cu procesul se leaga un set de registri, incluzind contorul de comenzi, pointer la stiva si alte registre, plus restul informatiei necesara pentru executarea programei.
In multe SO toata informatia fiecarui proces, adaugind si prorpiul spatiu de adrese se pastreaza in tabelul SO. Acest tabel se numeste tabelul proceselor si reprezinta un masiv (sau lista inlantuita), cite o astfel de structura pentru fiecare proces existent la un moment dat. In asa fel procesul care este in pauza contine prorpiul spatiu de adrese, denumit core image, si componentele tabelului procesului, care contine, pe linga alte valori si valorile registrilor sai.
Principalele apeluri de sistem, care administreaza procesele sunt apelurile legate de initierea si terminarea procesului. Exemlu: Procesul numit iteratorul de comenzi, sau shell (invelis), citeste comenzi de la terminal. Utilizatorul scrie comanda care contine o cerere de compilare a programei. Dupa asta, iteratorul de comenzi trebuie sa initieze un nou proces,care porneste compilatorul. Cind procesul termina compilarea, el executa un apel de sistem, care termina lucrul sau.
Daca procesul poate genera alte procese., si aceste procese la rindul lor pot genera iarasi alte procese , acest lucru se numeste arborele proceselor. Procesele dependente - sunt procesele care sunt unite pentru a rezolva o oarecare problema, si lor le este necesar de a transmite des datele de la un proces la altul, cit si de a sincroniza activitatea lor.
Alte apeluri de sistem sunt destinate pentru interogari despre memoria, asteptarea terminarii proceselor urmasi, si pentru axecutarea unor programe in mod overline.
1.3.2 Fisiere
Alta grupa de apeluri de sistem se refere la sistemul de fisiere. Principala functie a SO este de a ascunde modul de lucru al discurilor si al dispozitivelor de I/O si prezentarea utilizatorului a unui model abstract al acestor dispozitive. Apleurile de sistem sunt necesare pentru crearea,citirea si scrierea fisierelor. Inainte ca fisierul sa fie citit, el trebuie plasat pe disc si trebuie deschis, iar dupa citire trebuie inchis. Toate aceste operatii le fac apelurile de sistem.
Oferind spatiu pentru pastrarea fisierelor, SO foloseste notiune de derectiry ca metoda de a uni fisierele in grupe. Pentru crearea si stergerea acestori directoare, de asemenea trebuie apeluri de sistem. Ele asigura si plasarea fisierului in director cit si stergerea lui. Diretoarele pot contine fisiere si alte directoare. Acest model reprezinta ierarhia sistemului de fisiere.
Ierarhia proceselor si a fisierelor sunt organizate in forma de arbori, doar aceasta este asemanarea intre procese si fisiere. Ierarhia proceselor exista putin timp, iar a fisierelor poate dura si ani. Mecanizmele de aparteneta si siguranta sunt deosebite pentru procese si pentru fisiere. De obicei doar procesul parinte poate administra procesele urmasi.
Fiecare fisier in ierarhiea directorului se poate determina, prin numele complet al fisierului (patch). Aceasta cale incepe cu virful structurii fisierelor, numir directorul radacina.
In fiecare moment de timp fiecare proces are directorul curent de lucru. Procesele isi pot modifica directorul de lucru folosin apelurile de sistem.
In MINIX 3 fiecarui fisier si catalog i se atribuie un cod de siguranta din 11 biti. Acest cod contine trei cimpuri: 1 - pentru proprietarul; 2 - pentru grupele de utilizatori; 3 - pentru restul. In fiecare cimp este cite un bit pentru acces la citire, unul pentru acces la scriere si unul pentru acces la executie. Acesti trei biti impreuna se numesc rwx-biti.
Inainte de a citi sau scrie un fisiere, acesta trebuie deschis, in acelasi timp se verifica permisiunea de acces. Daca accesul este permis, sistema retureneaza un numar intreg numit descriptorul fisierului, si care se foloseste ulterior in operatii. Daca accesul este interzis, se retureneaza codul erorii (-1).
In MINIX 3 este si notiune de - fisier special. Acesta este folosit ca echipamentele de I/O s arate ca niste fisiere. Si de aceia se poate de citit informatia din aceste fisiere speciale sau se poate srie in ele , cu ajutorul acelorasi apeluri de sistem, care se folosesc la citirea si scrierea in fisier. Exista doua tipuri de fisiere speciale: 1 - Fisiere speciale de tip BLOC; 2 - Fisiere speciale de tip CARACTER. Fisierele de tip BLOC se folosesc entru modelarea echipamentelor, care contin seturi de blocuri de adrese arbitrare, cum ar fi discurile. Daca se deschide un fisier special de tip BLOC si citind , de ex., blocul 4, programa poate sa primeasca acces direct la blocul 4 al echipamentului fara a se adresa la sistemul de fisiere al acestui achipament. An mod asemanator fisierele speciale de tip caracter se folosesc pentru modelarea printerlor, modemurilor si al altor echipamente,care primesc sau transmit caractere. Fisierele speciale se pastreaza in directorul /dev.
Inca o notiune este cea de - canal(pipe), care are tangente si cu procesele si cu fisierele. Pipe reprezinta un pseudofisier, care se poate de folosit pentru a lega doua procese. Daca procesele A si B vor sa foloseaca un canal, acesta trebuie sa fie creat din timp. Cind procesul A trimite date procesului B, el le scrie in canal, ca si cum ar fi un fisier de iesire. Procesul B poate citi datele din Pipe ca si cum ar citi de pe un fisier de intrare. In asa fel lucrul intre procese seamana cu citirea si scrierea in fisiere in mod obisnuit. Doar creind un apel de sistem special, procesul poate depista ca fisierul de intrare nu este unul real .
1.3.3 Shell
SO reprezinta o programa, care executa apelurile de sistem. Redactoarele, compilatoarele, asebly, linker, si interpretorii de comenzi nu sunt parte al SO. Se va analiza interpreoturl de comenzi MINIX 3, denumit shell. Shell nu face parte din SO, dar se foloseste de multe funtii ale SO si de asta esete un bun exemplu pentru a afla cum lucreaza apelurile de sistem. In afra de asta Shell-ul, reprezinta principala interfata intre utilizaor si SO, daca acesta nu foloseste interfata grafica. Exista un sir de Shell-uri, incluzind csh, ksh, zsh si bash. Toate sustin functionalitatea descrisa aici al shell-ului sh.
Cind utilizatorul intra in sistema, se porneste shell-ul. Echipamentul standart de I/O pentru shell se numeste terminal. Shell incepe lucru cu invitatia (prompt) - semnul dolar, care spune utilizatoprului ca asteapta introducerea comenzilor.Dupa asta utilizatorul poate introduce comenzi. De ex: date.
In acest caz shell creaza un proces fiu si porneste programa date. Cit tipm precesul fiu ruleaza, shell asteapta finalizarea acestuia. Dupa finalizare shell iarasi afiseaza invitatie pentru a introduce comanda si incearca sa citeasca urmatorul rind introdus. Utilizatorul poate redirectiona introducerea standart de date in fisier date > file.
1.4 Apelurile de sistem
Apelurile de sistem sunt interfata intre So si programele utilizator. De facto mecanizmul de adresare la functiile de sistem sunt dependente de masina si des trebuie realizate in asembler, exista biblioteci de proceduri, care fac posibila adresarea la procedurile de sistem din programe in C si din din alte limbaje.
Trebuie de avut in vedere ca orice calculator monoprocesor poate executa doar o comanda intr-o uinitate de timp. Daca procesul executa programa in regim utilizaotr si cere sustinere de la SO(ex.: citire din fisier), sunt necesare intreruperi sau apeluri de sistem, pentru a transmite controlul SO-ului. So determina cererea procesorului dupa parametrii transmisio, executa apelurile de sistem si returneaza controlul comenzii, care urmeaza dupa apel. In acest sens apelurile de sistem seamana cu apelurile de proceduri, doar ca apelurile de sistem executa intrare in nucleul si alte componente ale SO.
Pentru a clarifica acest mecanizm, vom analiza apelul de sistem read. Acesta are trei parametri: primul pentru sarcina fisierului, al doilea indica la bufer, al treilea determina numarul de Byte, care trebuie cititi. In limbajul C poate arata astfel: count = read(fd, buffer, nbytes);
Apelul de sistem (si procedura de biblioteca) retureneaza numarul de byte cititi in variabila count. De obicei aceasta marime coincide cu parametrul nbytes, dar poate fi si mai mic, daca, de exemplu in procesul de citire a fost intilnit simbolul de sfirsit de fisier
Daca apelul de sistem nu poate fi executat sau din cauza parametrilor eronati sau a unei erori de disc, valoaea variabilei count devine -1, si numarul erorii se plaseaa in variabila globala errno.
Programele intotdeauna trebuie sa verifica rezultaul apelului de sistem, pentru a urmari aparitia erorii.
SO MINIX 3 sustine 53 apeluri de sistem principale. Mai sunt si alte apeluri, dar ele au un rol foarte de specific. Aceste apeluri de functii deterrmina posibilitatile SO, asa cum posibilitatile de administrare a resurselor in PC-uri, sunt reduse la minimum.
| pid = fork() | Creaza un proces fiu, identic cu cel parinte |
| pid = waitpid(pid, &statloc, options) | asteapta terminarea procesului fiu |
| s = wait(&status) | versiunea veche al waitpid |
| s = execve(name, argv, envp) | transmite imaginea memoriei procesului |
| exit(status) | termina procesul si returneaza statusul |
| size = brk(addr) | instaleaza marimea segmentului de date |
| pid = getpid() | returneaza identificatorul procesului, care a facut apelul |
| pid = getpgrp() | returneaza identificatorul grupei de procese pentru procesul care a apelat |
| pid = setpid() | deschide o sesiune noua, si returneaza pentru ea identificatorul grupului de procese |
| I = ptrace(req, pid, addr, data) | se foloseste pentru |
| s = sigaction (sig, &act, &oldact) | instaleaza o reactie la semnal |
| s = sigreturn(&context) | se returneaza din prelucratourl de semnal |
| s = sigprocmask(how, &set, &old) | determina sau instaleaza masca semnalului pentru proces |
| s = sigpending(set) | determina un set de samnale pentru blocare |
| s = sigsuspend(sigmask) | instaleaza masca semnalelor pentru proces si il pune in pauza |
| s = kill(pid, sig) | transmite semnal procesului |
| residual = alarm(seconds) | instaleaza semnalul timer |
| s = pause() | pune procesul in pauza pina la urmatorul semnal |
| fd = creat(name, mode) | mod invechit de a crea fisier |
| fd = mknod(name, mode, addr) | creaza un index al nodului directorului obisnuit, special sau referential |
| fd = open(file, how,...) | deschide fisier pentru citire, scriere sau ambele |
| s = close(fd) | inchide fisier |
| n = read(fd, buffer, nbytes) | citeste date din fisier in bufer |
| n = write(fd, buffer, nbytes) | scrie date din bufer in fisier |
| pos = Iseek(fd, offset, whence) | misca pointerul fisierului |
| s = stat(name, &buf) | primeste informatie despre starea fisierului |
| fd = dup(fd) | asociaza fisierului deschis un descriptor nou |
| s = pipe(&fd[0]) | creaza un canal |
| s = iocti(fd, request, argp) | actiuni speciale cu fisierele |
| s = access(name, amode) | verifica accesibilitatea fisierului |
| s = rename(old, new) | redenumire fisier |
| s = fcnti(fd, cmd,...) | acapareaza fisierul si executa alte actiuni. |
| s = fstat(fd, &buf) | primeste informatie despre starea fisierului |
| s = mkdir(name, mode) | creaza catalog |
| s = rmdir(name) | sterge un direcor gol |
| s = link(name1, name2) | creaza un element cu numele name2, care face referinta la name1 |
| s = unlink(name) | sterge elementul din director |
| s = mount(special, name, flag) | monteaza sistema de fisiere |
| s = umount(special) | demonteaza sistemma de fisiere |
| s = sync() | arunca blocurile cash-ate pe disc |
| s = chdir(dirname) | modifica directorul de lucru |
| s = chroot(dirname) | modifica directorul radacina |
| s = chmod(name, mode) | modifica bitii protectiei fisierului |
| uid = getuid() | determina identificatorul utilizatorului pentru apelat |
| gid = getgid() | determina identificatorul grupei pentru apelat |
| s = setuid(uid) | instaleaza identificatorul utilizatorului pentru apelat |
| s = getuid(gid) | instaleaza identificatorul grupei pentru apelat |
| s = chown(name, owner, group) | schimba identificatorul proprietarului fisierului |
| oldmask = umask(complmode) | modifica regimul mascarii |
| seconds = time(&seconds) | primeste timpul, trecut de la 1 ianuarie 1970 |
| s = stime(tp) | instaleaza timpul, trecut de la 1 ianuarie 1970 |
| s = utime(file, timep) | instaleaza timpul ultimei accesari a fisierului |
| s = times(buffer) | determina timpul de lucru al procesului utilizator in sistema |
1.4.1 apelurile de sistem pentru constrolul proceselor
Apelul fork - ramificare este unica metoda de crearea a unui nou proces in MINIX 3. El creaza o copie perfecta al procesului initial, incluzind descriptorii de fisier, registri etc. Dupa apelul fork, procesul initial si copia se dezvolta independent. Toate variabilell au marimi identice in momentul apelarii fork, dar pe urma modificarile facute intr-un proces nu influenteaza variabilele din celalalt. (Textul programei , care nu se modifica, se distribuie intre procesul parinte si procesele fii). Apelul fork, returneaza o valoare, egala cu zero in procesul fiu si egala cu identificatorul procesului fiu in procesul parinte. Folosind identificatorul returnat al procesului (Process IDentifier, PID), doua procese pot clarifica, care din ele este parinte si care este fiu.
In majoritatea cazurilor dupa apelul fork, proceul fiu trebuie sa execute codeul programei, deosebit de codul procesuluib parinte. Analizam exemplul shell: Ea citeste comanda de la terminal, porneste procesul fiu, asteapta, pina cind procesul executa comanda, si citeste urmatoarea comanda dupa terminarea lucrului procesului fiu. Asteptind , pina cind procesul fiu va termina lucrul, procesul parinte executa apelul de sistem waitpid, care asteapta terminarea procesului fiu Apelul waipid poate astepata terminarea unui proces fiu determinat sau a oricarui alt proces fiu, pentru asta trebuie de dat primului parametru al apelului egal -1. Cind apelul waitpid este executat, pointerul celui de-al doilea parametru statloc, arata statusul terminarii procesului fiu. Al treilea parametru detemina diferite setari ne importante.
Cum apelul fork foloseste shell-ul? Cind se scrie comanda, shell creaza un proces fiu, care trebuie sa execute comanda utilizatorului. Shell-ul face acest lucru cu apelul de sistem execve, schimbind imaginea memoriei cu fisierul indicat in primul parametru
1.4.2 Apelurile de sistem pentru controlul semnalelor
De obicei interactiunea intre procese este planificata, dar exista situatii, cind trebuie o actiune neplanificata. De exemplu utilizatorul intimplator a cerut redatorului de text sa afiseze continutul unui fisier foarte mare si a observat greseala, atunci trebuie sa fie un mod de a termina lucrul redactorului. utilizatorul poate accesa Ctrl+C, aceasta combinatie trimite redatorului de text un semnal. Primindul , redactorul intrrupe afisarea. Semnalelele se pot folosi si pentru a intercepata unele exceptii hardware, de exemplu instructiuni nepremise, sau depasirea la operatii in virgula mobila. Retinerile la fel se realizeaza prin semnale.
Daca procesul nu sia anuntat dorinta de a raspunde la semnal, atunci, primind semnalul, el pur si simplu se termina. Pentru a raspunde la semnale, procesul poate folosi apelul de sistem sigaction, care permite de a indica o noua adresa procedurii pentru prelucrarea semnalului si pentru a afla adresa procedurii anterioare. Dupa ce acest apel a fost efectuat, la primirea semnalului corespunzator (ex. Ctrl+C) starea procesului se pastreaza in stiva si apelat de prelucratorul de semnale. Prelucratorul de semnale poate lcra oricit de mult timp si afce orice apeuri de sistem. In practica prelucratorii de semnale sunt scurti. Terminind lucrul, prelucratorul face apelul sigreturn, pentru a continua lucrul procesului din locul in care a fost intrerupt. Apelul sigaction schimba apelul de sistem signal, care este realizat acum in biblioteci.
1.4.3 Apelurile de sistem pentru controlul fisierelor
Multe apeluri de sistem au legatura cu sistemul de fisiere. Pentru crearea unui nou fisier folosim apelul creat. Cu patametrii - numele fisierului si drepturile de acces, ex: fd = creat("abc", 0751);
Aceasta comanda creaza un fisier cu numele abc si cu dreptul de acces 0751. 9 bitii mici indica ca, proprietarul acestui fisier are dreptul de acces rwx (7 - dreprul la citire scriere si executare), membrii grupe au dreprul la citire si scriere (5), iar restul doar la executare (1).
Apelul creat nu doar creaza un fisier, dar si il deschide pentru scriere independent de regimul indicat. Scrierea in continuare in fisier se face prin descriptorul fd, valoarea caruia se returneaza de apel. Daca executam apeluol creat pentru un fisier existent, fisierul se micsoreaza la lungimea zero(daca avem dreptul). La moment in loc de creat se foloseste open.
Pentru a crea un fisier special, trebuie ca in loc de creat de executat epelul mknod. EX:
fd = mknod("/dev/ttyc2", 020744, 0x0402);
Aceasta comanda creaza un fisier cu numele /dev/ttyc2, si indica la dreptul de acces 020744 (rwxr--r--). Al treile parametru este compus din perechea de bytes, din care cel superior indica la echipamentul primar(4), iar al doilea - echipamentul secundar (2). Echipamentul principal poate fi oricare, iar al doilea pentru fisierul /dev/ttyc2 trebuie sa fie egal cu 2. Apelul mknod poate fi executat doar de superutilizator, in caz contrar se returneaza eroare.
Pentru a citi sau scrie in fisier, initial trebuie deschis cu apelul open. Pentru asta se indica numele fisierului si codul O_READONLY, O_WRONLY sau O_RDWR, care inseamna ca fisierul se deschide pentru citire, scriere sau pentru ambele. pentru crearea unui fisier nou este codul O_CREAT. Descriptorul returnat al fisierului pe urma se poate folosi la citire sau scriere. Apoi fisierul se inchide cu apelul close, careface descriptorul fisierului accesibil pentru urmatoarele apeluri creat sau open.
Cele mai folosite apeluri, sunt read si write.
Majoritatea programelor citesc si scriu fisiere in mod secvential, dar unele programe trebuie sa poata accesa orice parte a fisierului. Pointerul legat de fisier contine pozitia curenta in fisier. Cind citirea/scrierea se face secvential, el indica byte-ul, care va fi citit/scris uramtorul. Apelul lseek poate modifica valoarea pozitiei pointerului, asa ca urmatorul apel read sai write incepe operatia in alta parte a fisierului.
Apelul lseek are trei parametri:
1 - identificatorul fisierului
2 - pozitia in fisier
3 - indica pozitia celui de-al doilea parametru fata de inceputul fisierului, fata de pozitia curent, sau fata de sfirsitul fisierului
Apelul lseek returneaza pozitia absoluta in fisier dupa modificarea pointerului
Pentru fiecare fisier MINIX pastreaza urmatoarele date: tipul de fisier (simplu, special, director), marimea , timpul ultiomei modificari si alte informatii. Programa poate apela aceste inforamtii prin apelurile de sistem stat si fstat. Ele se deosebesc doar prin faptul ca , primul cere numele fisierului, iar al doilea se bazeaza pe descriptorul fisierului, si este util pentru pentru fisierele de I/O standart numele carora nu intotdeauna sunt cunoscute. La ambele apeluri al doilea parametru indica la structura, unde trebuie de introdus informatia.
La lucrul cu descriptorul fisierului citeodata se poate de folosit apelul de sistem dup. De exemplu, sa analizam programa care inchide Out-putul standart (descriptorul 1), care pune in calitate de out-put standart alt fisier, apeleaza functia care scrie in fisier, apoi revine la starea initiala. Daca doar inchidem out-putul standart si deschidem un fisier nou, atunci acest fisier va deveni out-putul standart, dar revenirea la starea initiala nu este posibila. Rezolvarea o da urmatoarea comanda in care se foloseste apelul de sistem dup:
fd = dup(1);
La executarea acestei comenzi in variabila fd se initiaza cu un descriptor nou, care va corespunde aceluiasi fisier, ca si cel standart. Apoi out-putul standart se poate de inchis, dupa care de deschis un fisier nou si folosit. Cind trebuie de returnat la starea initiala, trebuie de inchis descriptorul 1 si de executat codul n = dup(fd);
In rezultat cel mai mic descriptor de fisiere, mai exact 1, va corespunde aceluiasi fisier ca si fd. Si in sfirsit, fd se poate de inchis, iar in rezultat ne intoarcem la aceiasi situatie, de unde am pornit
Apelului de sistem dup are si a doua varianta, cu ajutorul careia se poate de legat descriptorul nefolosit cu fisierul deja deschis. El se descrie astfel: dup2(fd, fd2);
Aici fd - este descriptorul fisierului deschis, iar fd2 - descriptorul care se va referi la acelasi fisier. In asa fel, daca fd se refera la out-putul standart (descriptorul = 0), iar descriptorul fd2 = 4, atunci dupa executarea apelului, si 0 si 4 vor corespunde out-putul standart
1.4.4 Apelurile de sistem pentru administrarea directoarelor
mkdir si rmdir - creaza si sterg director.
link - permite unui fisier sa apara cu doua sau mai multe nume, deseori in diferite directoare. Acest apel se face de obicei cind mai multi programatori, care lucreaza intro echipa, trebuie sa utilizeze in comun un singur fisier.
chdir si chroot: primul modifica directorul curent iar al doilea directorul radacina
1.4.5 Apelurile de sistem pentru securitate
In MINIX 3 pentru fiecare fisier este determinat un cod din 11 biti (mode) Acest cod include 9 biti, cita trei (citire, scriere si executare) pentru propriecatr, pentru membrii grupei proprietarului si pentru alti utilizatori. Apelul de sistem chmod prezinta posibilitatea de a modifica codul regimului pentru fisiere. De exemplu, urmatorul apel ofera tuturor , in afara de proprietar acces la fisier doar pentru citire: chmod("file", 0644);
Alti doi biti, 02000 si 04000, se numesc SETGID si SETUID
- umask - instaleaza masca pe biti de sistem
1.4.6 Apelurile de sistem pentru administrarea timpului
- time - returneaza timpul curent
- stime - setarea timpului (doar super utilizatorii)
- utime - permite modoficarea valoarea timpului, inscris in nodul de indexi al fisierului.
- times - cit timp a folosit procesorul la executarea unui proces si cit timp pentru sistema, plus la asta se sumeaza timpul total al sistemei si al proceselor urmasi.
1.5.1 Structura SO. Sisteme MONOLIT
- So se scrie ca un set de proceduri, fiecare din ele poate apela alte proceduri.La folosirea acestei tehnici, fiecare procedura are o interfata determinata strict in termenii parametrilor si rezultatelor si fiecare are posibilitatea de a apela oricare alta procedura.
pentru construirea unei sisteme monolit trebuie de compilat toate procedurile si apoi de legat intr-un singur obiect.
Cum se executa apelurile de sistem? EX:
count = read(fd, buffer, nbytes);
La apelarea procedurii read, care de fapt apeleaza apelul read, programa apelata initial introduce parametrii in stiva. Primul si al treilea parametru se transmit prin valoare, iar al doilea prin referinta. Asta inseamna ca procedura read primeste adresa buferului (cu semnul &), dar nu continutul. In continuare se face apelul procedurii de biblioteca
O asa organizare a SO are urmatoarea strutura:
- Programa principala, care apeleaza procedura
- Setul de proceduri, care executa apeluri de sistem
- Setul de utilitati, care deservesc procedurile de sistem
1.5.2 Sisteme multinivel
Organizarea SO in forma de ierarhie de nivele. Prima So a fost THE, care avea 6 nivele:
NIvelul 0 - administra timpul procesorului. Sistema era compusa din procese secventiale.
Nivelul 1 - administra memoria. El oferea proceselor spatiu in RAM si la in bobina magnetica pentru partile procesului care nu incapeau in RAM
Nivelul 2 - administra interactiunea intre consola operatorului si procese.
Nivelul 3 - adiministra echipamentelele de I/O
Nivelul 4 - lucraru programele utilizator
Nivelul 5 - procesul operatorului de sistem
1.5.3. Masini virtuale
Sistema de impartire a timpului asigura : multisarcini, o masina extina cu interfata comoda.
inima sistemei, denumit monitoprul masinii virtuale,lucreaza cu echipamentul si asigura multisaracina, oferind nivelului superior mai multer masini virtuale
1.5.4 Exonucleu
In sistemul VM/370 fiecare proces primeste o copie a masinii reale.
la nivel jos in regim nucleu lucreaza programa, care se numeste exokernel. Ea adminisitreaza resursele pentru masinile virtuale, si dupa asta verifica folosirea lor
1.5.5. Modelul Client - Server
Sistema VM/370 are prioritate prin simplitate datorita transmiterii unei parti al codului, SO traditional la un nivel superior, in sistemul CSM.
In sarcina nucleului intra doar administrarea interactiunilor intre client si server