Aritoni Ovidiu Sisteme de operare 1 Introducere

A.Scopurile software-ului I/O

Un concept cheie proiectarea software-ului I/O este cunoscut ca independenta dispozitivului. Acest lucru inseamna ca ar trebui sa se poata scrie programe care sa poata citi fisiere de pe un floppy disk, hard disk sau cd-rom fara a fi nevoie sa se modifice programul pentru fiecare tip diferit de dispozitiv. Ar trebui sa se poata tasta o comanda cum ar fi

sort output

care sa functioneze cu intrare de pe floppy disk, hard disk sau tastatura si rezulatul sa mearga la floppy disk, hard disk sau chiar la monitor. Sistemul de operare este cel care trebuie sa rezolve problemele cauzate de faptul ca aceste dispozitive chiar sund diferite si necesita diferite driver-e de dispozitiv pentru a scrie datele pe dispozitive de afisare a rezultatului.

Strans legat de independenta dispozitivului este scopul de numirea uniforma. Numele unui fisier sau al unui dispozitiv ar trebui sa fie pur si simplu cuvant sau un tot si sa nu depinda de dispozitiv in nici un fel. In UNIX toate discurile pot fi integrate impreuna in ierarhia sistemelor de fisiere in moduri arbitrare astfel incat utilizatorul nu are nevoie sa stie carui dispozitiv ii corespunde un nume. De exemplu un floppy disk poate fi urcat in varful dosarului /usr/ast/backup astfel ca daca copiem un fisier in usr/ast/backup/Monday fisierul se va copia pe floppy disk. Astfel atat fisierelor cat si dispozitivelor ne adresam in acelasi mod: printr-un “path name”.

Un alt punct important pentru software-ul I/O este tratarea erorilor. In general erorile ar trebui tratate pe cat posibil, in cat mai stransa legatura cu hardware-ul. In cazul in care controller-ul descopera o eroare de citire ar trebui sa incerce sa o corecteze daca poate. Daca nu poate, atunci driverul dispozitivului ar trebui sa o corecteze, probabil prin simpla incercare de a reciti blocul respectiv. Multe dintre erori sunt trecatoare, cum sun erorile de citire cauzate de fire de praf aparute pe capul de citire, si vor disparea odata cu repetarea operatiei. Straturile superioare trebuie informate de eroare doar daca straturile inferioare nu o pot remedia. In multe cazuri eroarea poate fi reparata in straturile de jos fara ca straturile superioare sa afle de eroarea respectiva.

Totusi, un alt punct cheie il reprezinta transferurile sincronizate (blocate) versus cele nesincronizate (intrerupte). Cea mai mare parte dintre componentele fizice I/O sunt nesincronizate – procesorul initiaza transferul si apoi continua cu alte sarcini pana in momentul intreruperii. Programele utilizatoare sunt mult mai usor de scris daca operatiile I/O se blocheaza-dupa ce a primit comanda “citeste” programul este automat suspendat pana cand datele sunt disponibile in buffer. Sistemul de operare este cel care trebuie sa faca in asa fel incat operatiile care sunt de fapt intrerupte sa para blocate pentru programele utilizatoare.

Ultimul concept pe care-l vom trata aici il constituie dispozitivele comune versus dispozitivele dedicate. Unele dispozitive I/O cum sunt discurile pot fi folosite de mai multi utilizatori in acelasi timp. Faptul ca mai multi utilizatori au fisiere deschise de pe acelasi disk in acelasi timp nu cauzeaza probleme. Alte dispozitive cum sint driverele de banda trebuie sa fie dedicate unui singur utilizator pana cand acesta termina. Apoi alt utilizator poate beneficia de driverul de banda. In mod sigur nu se poate ca doi sau mai multi utilizatori sa scrie blocuri in acelasi timp si pe aceasi banda. Introducerea dispozitivelor dedicate (care nu pot fi impartite) produce si diferite probleme. Din nou sistemul de operare trebuie sa fie capabil sa lucreze ata cu dispozitivele dedicate cat si cu cele comune astfel incat sa evite problemele.

Aceste scopuri pot fi realizate intr-un mod eficient prin sctucturarea software-ului I/O in patru straturi:

1.remedierea intreruperilor (cel mai jos)

2.driver-ele dispozitivului

3.software-ul sistemului de operare independent de dispozitiv

4.software la nivel de utilizator (cel mai sus)
Aceste patru straturi sunt (nu intamplator) aceleasi patru straturi pe care le-am vazut in fig.2-26. in sectiunile urmatoare le vom analiza pe fiecare pe rand, incepand cu cel mai de jos. In acest capitol accentul se pune pe drive-ele de dispozitiv (stratul 2), dar vom rezuma si restul software-ului I/O pentru a arata modul in care conlucreaza diferitele componente ale sistemului I/O.

B.Remedierea intreruperilor

Intreruperile sunt o realitate neplacuta. Acestea ar trebui ascunse cat mai adanc in centrul sistemului de operare, asfel incat o cat mai mica parte a sistemului sa stie de ele. Cel mai bun mod de a le ascunde este de a face sa se blocheze fiecare proces care a inceput o operatie I/O, pana in momentul intreruperii cand I/O a incheiat. Procesul se poate bloca daca executa una din comenzile JOS la bariera, ASTEAPTA la o variabila de conditie sau PRIMESTE la un mesaj, de exemplu.

Atunci cand are loc intreruperea procedura de intrerupere face tot ce este necesar pentru a debloca procesul care a initiat-o. La unele sisteme prin comanda SUS la o bariera. La altele un SEMNAL la o variabila de conditie din monitor, iar la altele se va trimite un mesaj procesului blocat. In toate cazurile efectul de retea va fi ca un proces pana acum blocat acum va putea rula.

C. Driver-e de dispozitiv

Toate codurile dependente de dispozitiv sunt trimise la driver-ele de dispozitiv. Fiecare driver de dispozitiv trateaza un tip de dispozitiv sau, cel mult, o clasa de dispozitive asemanatoare. De exemplu, ar fi probabil o idee buna sa existe un singur driver de terminal chiar daca sistemul suporta mai multe tipuri de terminaluri, putin diferite intre ele. Pe de alta parte, un terminal prost, o copie hard mecanica si un terminal inteligent cu grafica pe schema de biti si un mouse sunt atat de diferite incat se impune folosirea unor driver-e diferite.

Pana acum in acest capitol am analizat functia controller-elor de dispozitiv. Am vazut ca fiecare controller are unul sau mai multi registri de dispozitiv utilizati pentru a ii da comenzi. Driver-ele de dispozitiv emit aceste comenzi si verifica indeplinirea corecta a lor. Astfel, disk driver-ul este singura parte a sistemului de operare care stie cati registri cre controller-ul respectiv si pentru ce sunt folositi. Doar el stie despre sectoare, piste, cilindri, capuri de citire, miscarea bratului, factori de inserare, motor, momentul de asezare al capului de citire si alte mecanisme care fac ca disk-ul sa functioneze cum trebuie.

In termeni generali sarcina unui driver de dispozitiv este de a accepta cererile abstracte venite de la software-ul independent de dispozitiv superior lui si sa aiba grija ca aceste cereri sa fie indeplinite. Una din cererile obisnuite este sa se blocheze n. daca driver-ul nu lucreaza in momentul in care soseste o cerere, incepe imediat sa execute sarcina. Totusi, daca deja este ocupat cu alta cerere va inscrie cererea pe o lista de asteptare cu cereri care trebuie tratate cat mai curand posibil.

Primul pas in tratarea unei cereri I/O pentru disk de exemplu, este traducerea ei din termeni abstracti in termeni concreti. Pentru un disk driver acest lucru inseamna localizarea blocului pe disk, verificarea daca motorul ruleaza, daca bratul se afla pe cilindrul corespunzator si asa mai departe. Pe scurt, trebuie sa decida care operatii ale controller-ului sunt necesare si in ce sectiune.

Odata ce a stabilit care comenzi trebuie transmise controller-ului incepe sa le emita inscriindu-le in registrii dispozitivului controller-ului. Unele controllere pot sa trateze doar cate o comanda. Alte controller-e pot sa accepte o lista de comenzi pe care le trateaza singure fara alt ajutor din partea sistemului de operare.

Dupa ce comanda sau comenzile au fost emise se va aplica una din cele doua situatii. In multe cazuri driver-ul de dispozitiv trebuie sa astepte pana cand controller-ul ii da ceva de lucru, astfel ca se blocheaza pana in momentul in care se produce intreruperea care il deblocheaza. Totusi, in alte cazuri operatia se incheie fara intarzieri, astfel ca nu este nevoie ca driver-ul sa se blocheze. Un exemplu al acestei situatii este ca derularea ecranului pe unele terminale nu necesita decat scrierea catorva bytes in registrii controller-ului. Nu este nevoie de nici o miscare mecanica, astfel ca intreaga operatie poate fi incheiata in cateva microsecunde.

In primul caz driver-ul blocat va fi repornit de intrerupere. In cel de-al doilea nu se va bloca deloc. In oricare din cele doua cazuri dupa ce operatia s-a incheiat trebuie verificata sa nu aiba erori. Daca totul este in regula, se poate ca driver-ul sa aiba date de transmis softare-ului independent de dispozitiv (ex. Un bloc tocmai a fost citit.). in cele din urma, returneaza unele informatii de statut pentru raportarea erorilor inapoi la apelant. Daca mai exista alte cereri pe lista una dintre ele poate fi acum selectata si initiata. Daca nu exista nici o sarcina pe lista de asteptare, driver-ul se blocheaza in asteptarea cererii urmatoare.