bs Dateien als Segmente Idee:Datei = persistentes Segment Konsequenzen:  Datei kann in virtuellen Adressraum eingeblendet werden (memory-mapped file)  keine spezielle Ein/Ausgabe für Dateien, kein Blockpuffer Geschichte:reicht zurück bis MULTICS (M.I.T )

bs Programmladen über Seitenfehler (demand-paged program loading) Code-Teil der Programmdatei wird wie Code-Segment im Sekundärspeicher behandelt: exec richtet Segmentstruktur des Prozesses ein (wie üblich), überträgt aber keinen Code in den Primär- oder Sekundärspeicher. In Unix erstmalig mit Version System V, heute bei den meisten Betriebssystemen üblich.

bs-6.53 Ablauf: 1. exec : Segmente des Prozesses einrichten (gemäß Beschreibung in Programmdatei) : Datei aktivieren: reqDesc liefert dno dno im Deskriptor des Code-Segments notieren (für Nicht-Code-Segmente ist dieses Feld 0) Seitendeskriptoren einrichten: - spezielle Markierung „von Datei einlagern“ - Blocknummer innerhalb der Datei 2.Ausgezeichnete Startseite einlagern und starten 3. Bei Bedarf – gesteuert durch Seitenfehler – Rahmen für einzelne Seite finden und Codeseite einlagern 4. Verdrängen erfolgt ohne physisches Kopieren

bs Dynamisches Binden (dynamic link libraries, DLLs, shared libraries) Varianten für das Einbinden von vorübersetzten Prozeduren, Modulen, Klassen etc. aus Bibliotheken:  statisch: nach der Übersetzung, vor dem Laden;  zur Ladezeit gemäß Angaben in Programmdatei: entsprechende Segmente einrichten bzw. mitbenutzen;  zur Laufzeit bei Bedarf – „dynamisch“.

bs-6.55  Binder (linker, linkage editor) entnimmt Code aus Bibliothek und fügt ihn mit dem anderen Code zusammen (mit Adressverschiebung und Auflösung externer Bezugnahmen); kein Sharing!  Bindender Lader (linking loader) bindet beim Laden und berücksichtigt dabei Codesegmente, die bereits von anderen Prozessen benutzt werden (  Sharing); Achtung:Adressierungsproblem, wenn nicht jeder Code einem bestimmten (virtuellen) Segment zugeordnet ist! Das tatsächliche Laden der Codesegmente erfolgt seitenweise bedarfsgesteuert, wie in skizziert, also nicht durch den Lader.

bs-6.56  Vertreterroutinen (stubs) für externe Prozeduren werden statisch eingebunden; sie veranlassen beim jeweils ersten Aufruf Segmenterzeugung bzw. -anbindung sowie entsprechende Aufrufumlenkung; die Bereitstellung des Codesegments erfolgt durch einen speziellen Systemaufruf (  6.5.3).

bs Einblenden beliebiger Dateien (memory-mapped files)  mittels geeigneter Systemaufrufe  erübrigt Blockpuffer (und damit Kopiervorgang!)  erübrigt Systemaufrufe read, write, seek  erübrigt eigenen Mechanismus für dynamisches Binden  erübrigt eigenen Mechanismus für Sharing (5.4.3  )5.4.3

bs ohne Capabilities addr = open(name,mode) (Segment/Datei einblenden) etabliert die Datei als Segment (falls nicht schon geschehen), d.h. richtet Segmentdeskriptor und Seitentabelle ein; blendet das Segment an geeigneter Stelle in den Adressraum ein und liefert die Adresse der ersten Zelle. Danach z.B. x = addr[0]; Zugriff auf erste Zelle... x = addr[37];... close(addr); Segment wird ausgeblendet, ggfls. in Datei zurückkopiert

bs-6.59 Beispiel Kopieren einer Datei: cp src dst... from = open(src, READING); stat(src,attr); length1 = attr.st_size; to = open(dst,WRITING); stat(dst,attr); length2 = attr.st_size; if(length2 == 0) for(int i=0; i<length1; i++) to[i] = from[i]; close(from); close(to);

bs Bemerkungen:  read, write, seek als einfache Bibliotheksroutinen  Semantik eines weiteren open ? (Datei über 2 virtuelle Segmente erreichbar??)  Ausnutzung in höheren Programmiersprachen: benutzerdefinierte Dateitypen möglich – und damit persistente Objekte.

bs mit Capabilities cap = lookup(name,mode) * etabliert die Datei als Segment (falls nicht schon geschehen), d.h. richtet Segmentdeskriptor und Seitentabelle ein, und liefert eine Berechtigung für dieses Segment (vgl  )

bs addr = map(cap) blendet das mit cap identifizierte Segment an geeigneter Stelle in den Adressraum ein und liefert die Adresse der ersten Zelle (vgl  ) unmap(addr) blendet das Segment wieder aus

bs Ähnlich in POSIX, Solaris, Linux,...: fildes = open(...); normales Öffnen einer Datei, fildes  Berechtigung a = mmap(addr,length,prot,flags,fildes,offset) blendet Datei in den Adressraum ein und liefert Adresse der ersten Zelle *. prot ist NONE oder Kombination von R,W,X. flags erlaubt u.a. SHARED, PRIVATE (private Kopie) munmap(a,length) blendet wieder aus (bis length )

bs und in Windows  Dateien sind – wie bei POSIX – sowohl normal als auch als memory-mapped files benutzbar  Berechtigungen für „File-Mapping-Objekte“ (  Segmente) kommen zum Einsatz  DLLs werden über diesen Mechanismus realisiert  Gemeinsame Segmente sind nur über diesen Mechanismus möglich

bs  fHandle = OpenFile(name,access,...) liefert open file handle  fmHandle = CreateFileMapping( fHandle, wenn –1, Segment ohne Datei... name) Segmentname liefert Berechtigung für Segment Für Sharing: statt Weitergabe des fmHandle auch fmHandle = OpenFileMapping(...,name)

bs  addr = MapViewOfFile(fmHandle,...) blendet das Segment an geeigneter Stelle ein und liefert Adresse der ersten Zelle. ODER mit explizitem Adressenwunsch: addr = MapViewOfFileEx(fmHandle,..., address)  x = addr[0]; usw.

bs  UnmapViewOfFile(addr) Ausblenden des Segments  CloseHandle(fmHandle) Berechtigung für Segment aufgeben  CloseHandle(fHandle) Berechtigung für Dateiobjekt aufgeben