T4-Input/Output Management

T4-Input/Output Management
SO-Grade Q2

License Aquest document es troba sota una llicència Reconeixement - No comercial - Compartir Igual sota la mateixa llicència 3.0 de Creative Commons. Per veure un resum de les condicions de la llicència, visiteu:

Outline I/O Management Overview Requirements
Physical devices, Logical devices, Virtual devices (file descriptors) Data structures i-node. i-node table Open file’s. Open file’s table File descriptor’s. File descriptor’s table Basic System calls: open, read, write, close I/O for process communications: pipes Redirection Índex i punts a tractar el 1er dia

I/O management To provide a robust, usable and efficient device access

Input/Output manegement
Data movement between processes and devices, always from the point of view of the process Input: From the device to the process Output: From the process to the device It is one of the key activities of processes I/O management: Device management (privileged access) to offer a usable, shared, robust and efficient access to devices Devices Process Write data/send data/output Read data/receive data/input Process

Dispositius d'E/S

Accessing physical devices
Control Register State register Data register Controller Device Ports Bus Memory I/O Bus CPU mov ds:[XX], ax in ax, 10h out 12h, ax int Revisar conceptes de: arquitectura Vonn Neumann, bus, port, interrupció Revisar, sobre el dibuix, el funcionament de: programació del dispositiu, accés per enquesta, accés per interrupció Revisar, sobre el dibuix, els conceoptes de registres mapejats a memòria (per exemple, la VGA), accés per DMA Això seria un repàs dels conceptes d’E/S d’EC2

Too many device types To interact with users: display, keyboard, mouse To store data: hard disk, DVD, To transfer data: modem, network, WI-FI Too many possible characterizations Device management requirement design: to provide a standard API able to support very different types of devices and to include new ones (non existing yet) Estandarització: permet incorporar a les computadores i SO existents generacions millorades de dispositius, o nous dispositius. Nous tipus de dispositius: àmplia i creixent varietat de dispositius, que sens dubte és positiu, cal poder incorporar-los en els sistemes actuals. Per tant, independència dels dispositius, es tracta d’una solució que combina hardware i software: els elements bàsics del hw (controladors, ports, …) permeten cubrir una àmplia varietat de dispositius, mentre que el kernel encapsula els detalls i peculiaritats dels diferents dispositius en mòduls manegadors de dispositius (device drivers) que proporcionen una interfaç comuna d’accés als dispositius. Goal: I/O operations design independent from device characteristics

Design requirements Uniform I/O operations: Same system calls for all the devices Virtual devices: Programs doesn’t specify physical devices, only an abstraction provided by the O.S. It allows to connect virtual devices to different physical devices The same program, using the same virtual device, can be accessing different physical devices The same program, using different virtual devices, can be accessing the same physical device % programa < disp1 > disp2

Virtual, logical and physical devices
Proc 3 Proc 1 Proc 2 /dev/lpr1 /dev/tty /home/my_file /dev/hda /dev/lpr2 Physical devices

Three levels of abstractions
Physical, logical and virtual Each level has: A set of functions that implements device operations (initialize, read, write, configure, etc) A name space, a way to refer and identify the device (physical, logical or virtual)

Physical devices : operations
Physical devices are managed by the kernel by defining a set of common operations that all the manufacturers has to provide: device drivers Device drivers code Follows kernel specifications Low level code to initialize, read, write, configure (etc) the device Part of it is usually write in assembler API is a superset, manufacturers can provide some of them and define the rest as NULL functions Device drivers code are part of the kernel code (executed in privileged mode) To add a new driver we need to regenerate the kernel code By recompiling the kernel (and then rebooting the system) By using kernel provided tools to dynamically add code to the kernel without recompile and reboot (kernel modules) We will see in the lab!!!! Potser en aquest punt es poden introducir conceptes tals com: Canals a linux, canals estàndard 0, 1 i 2 Entrada estàndard Sortida estàndard Com es redireccionen l’E/S estàndard en linux

Physical devices: names
When adding a new device, system administrator has to specify (user root adds news devices): Type: Character or Block device Two numbers (physical device identifier): Major and Minor Major (identifier): identifies the device. Must be unique per each type (character or block) Minor: identifies a particular device of type major These two numbers are specified and reserved when inserting the device driver code into the kernel In case of physical devices, they are named by these two numbers

Logical devices Logical devices are abstractions of physical devices (the device driver must be previously inserted into the kernel) One logical device can represent One physical device Many physical devices combined emulating a new one One physical device configured with specific case to facilitate usability No physical devices, being a device implemented only in memory Operations to access logical devices have a common part, implemented in the kernel (by kernel programmers) and a specific part, implemented like calls to device driver specific operations Logical devices are offered to users (processes) as objects in the file system, that is, file names associated with physical devices (special files) Logical device names are the ones that users can see

Logical devices: names
The system administrator creates new special files by associating a file name with physical devices (identified by a device type (block/Character), major, and minor) Mknod command (or system call) creates a special file For instance: mknod /dev/mydevice c X Y (where X Y are two numbers that corresponds to the major and minor of a valid character device) Once we have a file name, it can be accessed by users (processes) through commands or/and system calls Open Read Write Close etc

Virtual devices (file descriptors)
Processes ask to the kernel specific accesses to a file name (logical device) With the system call open Specific accesses can be: read/write/read and write The kernel grants access to logical devices by creating one new (dynamic and local to the process) virtual device for each particular request We will refer to virtual devices as file descriptors (fd) File descriptors “names” are numbers (unsigned integers). Subsequent operations MUST refer to these numbers to access logical devices The access mode is restricted to the one specified previously These three levels of abstractions provides great flexibility and usability of devices One logical device can be accessed by many processes at the same time One process can access one logical device with many file descriptors

Standard file descriptors
All the processes have created, by default, three file descriptors 0 : standard input. Read access is allowed. By default it is associated with the console (stdin) 1 : standard output. Write access is allowed. By default it is associated with the console (stdout) 2 : standard error output. Write access is allowed. By default it is associated with the console (stderr) Processes usually use these tree standard file descriptors, we will see how to change the logical device associated with them (Redirection)

Accessing devices user kernel User process syscalls Virtual devices
Fdlogical dev. User process Read(fd)data write(fd)data Open(fileName)new fd user syscalls Virtual devices logical dev.physical dev. kernel Logical devices Comentar els nivells, destacant que el nivell virtual està entre espai d’usuari (arxius i llibreria de crides al sistema) i nivell sistema (dispositius virtuals = canals). Comentar, sobre el dibuix, què passa quan s’executa una operació del tipus open (en blau) i què passa quan s’executa una operació de tipus llegir/escriure (en morat). Device driver Device driver Device driver Device driver Physical devices Hardware

Example: Writing to a device
... printf(...) write(1,...) pushl $1 int 0x80 User code (calling the C library) C library implementation System library implementation user kernel syscall 1 2 Fd table Logical devices data management device driver: write_dev() Device access Return value I/O subsystem Explicar sobre el dibuix el procés: crida a la funció C d’escriure: printf execució de la llibreria de C execució de la llibreria de crides al sistema de linux crida al sistema: interrupció (software). Destacar que, entre altres paràmetres (incloent un enter que identifica quin servei de sistema es demana –identificador de la crida al sistema write) es passa el dispositiu virtual (canal 1) execució de la rutina de sistema, independent del dispositiu (nivell virtual). Es fan comprovacions del tipus: si el canal està obert, si està obert per escriptura, … execució de la rutina de sistema i accés a les dades del nivell lògic. De moment no entrem massa en detall sobre aquest nivell tot i que, de manera genèrica, es pot comentar que aquí s’implementen entre altres coses la majora de les optimitzacions d’E/S que es veuran al final del tema. Aquí hi ha també una taula d’apuntadors a les rutines específiques del driver: open, close, read, write, … execució de la rutina d’escriptura del device driver, que executarà les tasques pròpies d’aquest dispositiu: p.ex. posar el motor en marxa, programar els paràmetres de la operació d’escriptura, … i programar l’inici de lexecució de l’operació com que és una escriptura, en un principi, no cal esperar a la finalització de l’operació i un cop s’ha iniciat l’operació, la rutina ja retorna i retorna el resultat corresponent

Example: Reading from a device
... scanf(...) read(0,...) pushl $0 int 0x80 User code (calling the C library) C library implementation System library implementation user kernel syscall 1 2 Fd table Logical devices data management device driver: read_dev() Device access Return value I/O subsystem RSint() interrupt En aquest cas, la diferència principal és que el procés es bloqueja fins que acabi l’operació de lectura. Un cop acaba l’operació, el controlador del dispositiu envia una interrupció i s’executa la Rutina de Servei a la Interrupció (RSint), que llegeix les dades i retorna el resultat corresponent. El procés es desbloqueja i es coloca a la cua de processos preparats per a l’execució. Quan el planificador decideixi, doncs, el procés reanuda l’execució amb els resultats de la lectura.

Accessing slow devices
Devices have slow access times compared with CPU or memory  it is normal that processes have to wait for data Operations are classified in three types: Synchronous with process blocking: They block processes if data transfer is not available at the moment Synchronous without process blocking: The process never blocks Asynchronous: The I/O operation is programmed and the process doesn’t block

Synchronous with process blocking
The process asks for a data transfer of N bytes (input or output) If some data transfer is immediately available, data transfer is performed and the process returns to user mode Not necessarily all the bytes requested by the user If no data transfer is available (0 bytes availables), the process blocks The process leaves the CPU and it goes to BLOCKED state The scheduling policy is applied to select the next process to run In case of round robin, the first process of the ready queue is selected When the I/O is finished, the process is unblocked and it is moved to the ready queue The system call always returns the number of bytes transferred (read or write)

Synchronous without process blocking
The process asks for a data transfer of N bytes (input or output) The kernel performs the data transfer available and the process returns to user mode Even though no data transfer is available The system call always returns the number of bytes transferred (read or write)

Asynchronous operations
The process asks for a data transfer of N bytes (input or output) and it returns to user mode immediately It is useful in those cases were data is not required at that moment, it’s a pre-fetch of data Data transfer finalization is notified to the process in two ways: By modifying a global variable of the process With a software interrupt (similar to a signal processing) If data is required before the transfer finish, the process can execute a blocking system call to wait for data In our case, we will always use the first case: synchronous with process blocking

Some device characteristics

Some device characteristics: console
Console (/dev/tty in the labs) It is a logical device that abstracts two physical devices together: keyboard and display The standard input/output/output_error fd’s of processes is associated with the console Read: If there are characters in the keyboard buffer, it gets them, otherwise the process is blocked until the user press as many keys as requested and press enter (or ^D which represents the end of input data for the console) Write: The message is written in the display without blocking It is an ascii device, input data is received in ascii format and output must be in ascii format Cal matitzar, en la lectura a fitxers, quan diu que “si EOF el procés no es bloqueja” que si arriba a EOF en mig d’una operació de lectura aleshores llegeix el que hi hagi, retorna el nombre de caracters llegits, i acaba. El mateix passa a l’escriptura. A més, quan a l’escriptura poso “es bloqueja (o no)” ho dic per que el sistema pot realitzar optimitzacions d’aquesta operació de manera que no cal esperar a la finalització real de l’operació d’escriptura: encua una petició d’escriptura a la cua d’operacions pendents i acaba. Aquest és el motiu pel qual abans de desmuntar un pen drive USB cal executar “Extraer de forma segura”, ja que hi podrien haver operacions d’escriptura, en teoria ja realitzades, però que realment estan pendent de fer-se.

Some device characteristics: regular file
Regular (ordinary) file Logical device that represents a sequence of bytes stored at disk This device offers sequential access, each open file has associated a current position in the file Read: The process blocks if required If current offset is equal to file size at the beginning of the read, the read returns 0 Write: The process blocks (or not) until the writing is finished Only in case the disk is full the writing will return a number of bytes different from the requested ones Cal matitzar, en la lectura a fitxers, quan diu que “si EOF el procés no es bloqueja” que si arriba a EOF en mig d’una operació de lectura aleshores llegeix el que hi hagi, retorna el nombre de caracters llegits, i acaba. El mateix passa a l’escriptura. A més, quan a l’escriptura poso “es bloqueja (o no)” ho dic per que el sistema pot realitzar optimitzacions d’aquesta operació de manera que no cal esperar a la finalització real de l’operació d’escriptura: encua una petició d’escriptura a la cua d’operacions pendents i acaba. Aquest és el motiu pel qual abans de desmuntar un pen drive USB cal executar “Extraer de forma segura”, ja que hi podrien haver operacions d’escriptura, en teoria ja realitzades, però que realment estan pendent de fer-se.

Main data structures System calls Linux management

I/O managemant subsystem
I/O subsystem disk caches char drivers user processes linux kernel tty dsk dvd lpr eth syscalls interface hardware control process & memory management IPC block drivers Virtual File System I/O managemant subsystem Explicar la figura, recordant el concepte de device drivers, i recordant el concepte de càrrega dinàmica de mòduls. Aquí potser si que es pot explicar que a linux existeixen dos tipus de drivers: els de caràcter (teclat, mouse, …) i els de bloc (disc, CD, DVD, …) que utilitzen device drivers de tipus diferent, ja que uns (els de bloc) s’aprofiten de certs mecanismes d’optimització: p.ex. disk caches. Això provoca que, internament, el kernel els tracti de manera molt diferent (els drivers de bloc i els de char) tot i que, de cara a l’usuari, s’accedeix de la mateixa manera (independència dels dispositius / uniformitat de les operacions).

i-node The i-node is the data structure that represents a logical device (which is the object managed by the kernel) It contains all the attributes of a logical device (not all of them are used by all the devices). Some basics are: i-node identifier (i-node number) User ID of the owner Group File size, if it is a regular file Device ID Some timestamps Device driver operations (pointers to) … It is to device management the same than the PCB to process management File name’s are decouple from i-node data. Users uses file name’s, which are more user friendly than i-node numbers. We will see in File System management how it is defined this relationship

Accessing logical files
Processes accesses logical devices (files) creating a new file descriptor that grants access to that logical file with specific access flags This is done through the open system call Each open system call creates one new open_file object (a new data structure), with the dynamic link between inode number, access flags, and current offset The offset is only used if the device provides a sequential access Open_file’s are organized in an global open_file table (shared by all the processes) Each open also creates a new file descriptor that simply links with the newly created open_file object This new level of abstratcion will provide processes with a high flexibility new_fd open(file_name, access_flags)

Data structures 3 levels of data corresponding with the three levels of abstractions: File descriptors table(per process): Each process has N created file descriptors. The table is indexed by the FD number. Open file’s table(global): Files currently in use with specific access flags (Each open allocates one new open_file entry) i-node table(global) : in memory copy of i-nodes currently in use ... write(1,...) attributes User code Kernel data structures process Fd’s table Open file’s table i-node table virtual logical physical 1 2 off access Device driver operations Included in PCB, one per process Global (shared) Aquí cal incidir en què tots els dispositius estan representats el en sistema dins del Virtual File System (propera transparència). Per tant, en aquest punt s’utilitza el concepte “fitxer” en el sentit més ampli de la paraula: un objecte en el VFS. En aquest tema ens interessa centrar-nos en els “fitxers” que representen un dispositiu (possiblement físic) i, generalitzant, es considera un fitxer de dades com a un objecte dins del dispositiu físic “disc”. Tot i que el proper tema es tractarà en més detall el concepte de fitxers de dades i, en general, el VFS. 1 2 1 1 2

Data structures fields
Each i-node entry of the i-node table has: Number of references: defines how many open_file entries are linked with the i-node entry Copy of i-node (in disk) attributes, that includes a link to i-node device driver operations One i-node Each open_file entry of the open_file table has: Number of references: defines how many file descriptors entries are linked with the open_file entry Access mode: READ/WRITE/READ_WRITE Current offset: 0..(file_size-1) i-node entry number Each fd entry of the fd table has: Open_file entry number

Espai de noms: VFS (1) Tots els dispositius tenen un nom al VFS (tema 5) Això permet que qualsevol procés hi pugui accedir Generalment es troben al directori /dev Per tant, es poden considerar com fitxers especials. Cada un té associat: major: identificador de tipus de dispositiu minor: instància de dispositiu del tipus “major” tipus: [char / block] Comanda per a la creació d’un fitxer especial: mknod nom c|b major minor Crida al sistema per a la creació d’un fitxer especial mknod(pathname, mode, dev); on mode codifica el tipus c|b i les proteccions del fitxer on dev codifica el major i el minor Destacar que els arxius de dades NO tenen major ni minor, i que àquest concepte es veurà amb més detall en el tema 5. De fet, si s’executa un “ls –l”, en els arxius tipus dispositiu hi surt el major i el minor. I si es tracta d’un arxiu de dades hi surt, en el seu lloc, el tamany de l’arxiu. Recordar que el tipus (bloc, char) existeix a linux per que el sistema implementa certes optimitzacions (relacionades amb millorar l’eficiència de la transferència de dades) i, per aquest motiu, manté dos tipus de drivers: de char (no són crítics en quant a transferència de dades) i de bloc (aquests si).

Espai de noms: VFS (2) dev name type major minor description /dev/fd0
Alguns exemples: dev name type major minor description /dev/fd0 b 2 floppy disk /dev/hda 3 first IDE disk /dev/hda2 second primary partition of first IDE disk /dev/hdb 64 second IDE disk /dev/tty0 c terminal /dev/null 1 null device Per suposat, els noms exactes poden variar d’una instal·lació a una altra. Però aquests poden ser il·lustratius. Coses a comentar: hda i hda2 tenen el mateix major, ja que es tracta del mateix disc, però diferent minor, ja que són dos dispositius (dues particions) diferents. hda i hdb tenen el mateix major ja que, tot i ser dos dispositius diferents, funcionen exactament igual i, per tant, estaran gestionats pel mateix device driver. Per suposat, el minor ha de ser diferent. hda i tty0 tenen el mateix major i minor. Com pot ser això? Per que un es un dispositiu de block i l’altre de char! Per tant, són dos dispositius completament diferents (un disc dur i una consola) i es gestionen de manera diferent.

System calls

Basic system calls System call description Open
Creates a new open_file that links logical device with specific access flags and offset. It also creates a new fd (return value) that grants access the process to that open_file object Read Reads bytes from a fd to memory Write Write bytes from memory to fd close Removes the fd

Basic system calls for I/O:open
fd = open(file_name, flags); It creates a new open_file object that grants access to that file with this specific access mode and offset. The file MUST previously exist!! The open_file object is a kernel object, the process has access to it through a new file descriptor The open system call implements security checks, once created the fd, permissions are not validated again Following accesses will be performed using the fd Valid flags MUST include one of the following: O_RDONLY: read access is requested O_WRONLY: write access is requested O_RDWR: read and write access is requested We will explain later! Compte! La crida open pot portar un tercer paràmetre si està obrint i creant un arxiu nou. Però en tot cas deixem aquest detall pel tema de VFS. Al igual que les crides al sistema creat i lseek.

Open (cont): Modifications in kernel data structures If i-node is not in memory, the kernel loads it from disk and adds it to the in memory i-node table (references=1), otherwise references++ One new entry in the open_file’s table is reserved and initialized i-node entry points to the entry number of i-node table Current offset set to zero Access_mode set to acces_mode argument References set to 1 One new fd entry (the first one available in sequential order) in the fd’s table is reserved and initialized Open_file entry set to the entry number of the open_file’s table Potser, tornar a recordar que els processos tenen “habitualment” oberts, per defecte, els canals d’entrada (0), sortida (1) i error (2) estàndard.

Example: How are kernel data structures updated with these two system calls?? fd=open(“file”,O_WRONLY); write(fd,”hola”,4); Potser, tornar a recordar que els processos tenen “habitualment” oberts, per defecte, els canals d’entrada (0), sortida (1) i error (2) estàndard.

The file MUST previously exist??
For special files, we must previously create them with the mknod command (or mknod system call) For regular files, we can create and open the file with the open system call with a different format fd = open(file_name, flags, permissions); Flags can be bitwise-or'd in flags with one of the following: O_CREAT: If the regular file doesn’t exists, create it, otherwise it hasn't effect O_TRUNC: truncates the content of the file, the file size is set to zero. Permissions specifies the permissions to use in case a new file is created

Creating Data files Example:
fd = open(“f1”, O_WRONLY|O_CREAT|O_TRUNC, S_IRUSR|S_IWUSR ); We open the f1 file for writting If the file f1 doesn’t exists, it is created with read and write permissions for the owner. If the file f1 exists, it just opens it for writing but the file size is set to zero because of the O_TRUNC flag

Basic system calls for I/O:read
n = read(fd, buffer, count); Asks the kernel to read count bytes from the device pointed by fd and to store them in the memory area pointed by buffer At the position defined by the offset Count is the desired maximum number of bytes to read, it usually matches the buffer size It could block the process depending on the device It always returns the number of bytes read: If n>0 and n<= count, the read has been ok If n==0 it means the end of the input data. That “situation” depends on the device If n<0 some error has occurred The current offset of the open_file pointed by fd is advanced by n Això ja es va explicar en la sessió anterior, però es pot recordar: * Explicar diferents possibilitats de l’EOF: arxiu quan s’ha llegit tot consola, quan es pitja ^D pipe i socket quan està buida i no hi ha cap possibilitat que ningú hi escrigui Tot i que qualsevol d’aquests comportaments (per defecte) es poden configurar al gust

Basic system calls for I/O: write
n = write(fd, buffer, count); Asks the kernel to write count bytes from the memory area pointed by buffer to the device pointed by fd At the position defined by the offset Count is the desired maximum number of bytes to write, it usually matches the buffer size It could block the process depending on the device It always returns the number of bytes written: If n>0 and n<= count, the write has been ok If n==0 indicates nothing was written If n<0 some error has occurred The current offset of the open_file pointed by fd is advanced by n Això ja es va explicar en la sessió anterior, però es pot recordar: * Explicar diferents possibilitats de l’EOF: arxiu quan s’ha llegit tot consola, quan es pitja ^D pipe i socket quan està buida i no hi ha cap possibilitat que ningú hi escrigui Tot i que qualsevol d’aquests comportaments (per defecte) es poden configurar al gust

Basic system calls for I/O:close
close(fd); It releases the fd entry from the fd table It propagates the close request to the open_file entry pointed by fd and, if required, to the i-node entry It depends on the number of references of each entry

Basic system calls for I/O
Example of reading a file and writing it to the standard output

I/O and process management
The fd’s table is included in the PCB, what happens at fork and execlp? Fork: The fd table of the child is a private copy of the fd table of the parent It allows to share the open_file entry (including the current offset References of the open_file entries must be updated Execlp: It doesn’t affect the fd table El comentari que “permet compartir l’accés” es refereix a que, al compartir punter de L/E, si un procés llegeix del fitxer, quan llegeixi l’altre procés, llegirà els bytes que hi ha a continuació (accés seqüencial). En quant “als següents open ja seran independents” significa que el sistema assignarà nous punters de L/E per cada nou open. La seqüència d’aquesta figura és: 1. El procés 1 obre el fitxer f1 (assumint que els canals 0, 1 i 2 ja estaven oberts) 2. El procés 1 executa fork: es duplica el procés i la TC. La TFO queda igual (excepte el comptador canals que apunten a cada entrada: no cal insistir gaire en això) 3.1. El procés 1 obre novament el fitxer f1: nova entrada a la TFO (i nou punter de L/E). Els accessos seran independents 3.2. El procés 2 obre el fitxer f1: nova entrada a la TFO i nou punter de L/E. Els accessos seran també independents

Example What happens internally when executing the following code?
fd=open(“f1”,o_rdonly); fork(); fd1=open(“f2”,o_wronly);

E/S i execució concurrent (2)
La nova imatge manté les estructures internes d’E/S del procés El fet d’executar fork+exec permet realitzar redireccions abans de canviar la imatge usuari sistema open(“f1”...) if (fork()==0){ close(0); open(“f2”...) exec(...) procés 1 TC TFO inodes 1 2 3 4 std in std out std err ref f1 pL/E A la figura, s’entén que el codi que mostra el procés 2 en el fork, és el que hi ha a continuació (punts suspensius (...)) del codi que mostra el procés 1. És a dir, que els dos processos tenen els canals oberts segons s’ha vist en la transparència anterior i, posteriorment, el procés 2 fa el exec. fork+exec, en contraposició a una crida del tipus pthread_create (que crea un nou procés el qual executa un nou codi), permet primer crear un nou procés, després executar el codi que es desitgi (per exemple, realitzar totes les redireccions que es creguin oportunes) i, posteriorment, canviar la imatge del nou procés. Destacar que això permet donar moltíssima potència a les redireccions dels processos: P.ex. el que fa l’intèrpret de comandes (shell) quan fem: % prog > fitxer < fitxer o bé % prog1 | prog2 info gral. rutines device driver nou codi procés 2 pL/E @rutines 1 2 3 4 (...) ref f2 close(0); open(“f2”...) exec(...) std out std err ref f1

I/O and signal management
What happens if the process is blocked in a read or write and it receives a signal? Two diferent behaviors: The signal is processed and the I/O operation continues automatically The process unblocks, the signal is processed, and the system calls returns error (-1). The errno variable is set to EINTR The type of behavior depens on: The management associated to the signal: If sigaction had the flag SA_RESTART set  the operation continues Otherwise  the operation returns error The blocking operation (for example, operations on sockets or operations to wait for signals always retorn an error if they are interrupted by a signal) Example: how to detect an error due to a signal delivering and repeat the operation: while ( (n = read(...)) == -1 && errno == EINTR );

I/O for process communication

I/O for process communication
How to proceed to read/write data from/to other processes? The kernel provides processes with a specific device for process communication: Pipes We can create a special file (FIFO) using mknod or we can create a temporal pipe P1 P2 ???????

Pipes FIFO buffer where bytes are removed as soon as they are read (they cannot be read two times) It is designed for process communication. Processes must be in the same computer. (Unnamed) Pipe. (It is a special case) It’s a temporal device without name in the system file. It is created totally in memory and only accessible by the creator or by heritage (It doesn’t have a name to refer to it) Created with the pipe system call Named Pipe: Special device with a name in the file system Created with the mknod system call (or command) Opened with the open system call De fet, els dispositius de xarxa reben habitualment un tractament diferent, en qualsevol llibre de SO, a la resta de dispositius d’E/S, ja que tot i l’intent d’uniformitzar-los amb la resta de dispositius, són diferents. La implementació interna dins del kernel és també un cas apart.

Pipes It is a blocking device
Read: If some bytes are available, they are read (even partially). Otherwise (empty pipe), the process blocks until new bytes become available. If there aren’t writers, this is interpreted like the end of the communication and blocked processes (readers) will be unblocked Write: If the pipe is not full, the write is performed (even partially). Otherwise (full pipe), the process blocks until some space is available If there aren’t readers, it is is interpreted like the end of the communication and blocked processes (writers) will be unblocked. In that case, the kernel will additionally send the SIGPIPE signal to writters De fet, els dispositius de xarxa reben habitualment un tractament diferent, en qualsevol llibre de SO, a la resta de dispositius d’E/S, ja que tot i l’intent d’uniformitzar-los amb la resta de dispositius, són diferents. La implementació interna dins del kernel és també un cas apart.

(unnamed ) Pipes creation
int fd_pipe[2]; pipe(fd_pipe); It creates one new temporal device of type pipe. The i-node is only created in the i-node table, it doesn’t exist in the file system It creates two new open_file entries in the open_file table, one with read access and the other with write access. It creates two new fd’s, linked with these two new open_file entries. These two fd’s are returned to the process in fd_pipe[0] and fd_pipe[1] respectively fd_pipe[0] contains the fd number with read permissions fd_pipe[1] contains the fd number with write permissions The kernel uses the number of “readers” and “writters” to interpret the end of the communication take care with unused fd’s since they affect the references of open_file’s entries. NOTE: Named pipes are accessed using open, refer to open to see data structures modifications

Redirection It consists of changing the open file linked with a specific file descriptor When running programs that use standard file descriptors, it is required a mechanism to change open files pointed by standard input, output and error output We can do it with the dup or dup2 system calls, they copy an existing fd entry in a new entry in the fd table The “normal” usage is to duplicate a previously created fd in entries 0, 1 or 2

Redirection newfd = dup(fd);
It duplicates an fd entry (fd is the entry number) in the first fd entry available in the fd’s table The fd entry number allocated is returned If ok, after the system call we will have two entries with the same information newfd = dup2(fd, newfd); It duplicates an fd entry (fd is the entry number) in the entry number specified by newfd In both system calls, the reference of the open_file pointed by fd must be updated Això ja es va explicar en la sessió anterior, però es pot recordar: * Explicar diferents possibilitats de l’EOF: arxiu quan s’ha llegit tot consola, quan es pitja ^D pipe i socket quan està buida i no hi ha cap possibilitat que ningú hi escrigui Tot i que qualsevol d’aquests comportaments (per defecte) es poden configurar al gust

Processes in different computers: socket
Logical device implemented only in memory (there isn’t a physical device named socket) It offers a FIFO buffer where bytes are removed as soon as they are read (they cannot be read two times) It is designed for process communication. Processes CAN be at different computers with a network in the middle. The behavior is very similar to a pipe but internal implementation is much more complicated (network protocols must be implemented) De fet, els dispositius de xarxa reben habitualment un tractament diferent, en qualsevol llibre de SO, a la resta de dispositius d’E/S, ja que tot i l’intent d’uniformitzar-los amb la resta de dispositius, són diferents. La implementació interna dins del kernel és també un cas apart.

Exemple: Operacions bàsiques d’E/S
Lectura per l’entrada estàndard i escriptura per la sortida estàndard Observacions: Generalment, els canals estàndard ja estan oberts per defecte Es llegeix fins EOF (n==0), que depèn del tipus de dispositiu Es pot executar redireccionant com vulguem Igual, però llegim blocs de caràcters Compte! Cal escriure n chars Quines diferències hi ha en quant a rendiment? while ((n = read(0, &c, 1)) > 0) write(1, &c, 1); char buf[SIZE]; ... while ((n = read(0, buf, SIZE)) > 0) write(1, buf, n); En quant a les diferències de rendiment, se m’acut que: La segona proposta és més eficient ja que executa menys crides al sistema Però necessita més memòria Però perd granularitat, en cas d’aplicació concurrent o paral·lela

Exemple: Ús bàsic d’una pipe
int fd[2]; ... pipe(fd); pid = fork(); if (pid == 0) { // Codi del fill while (read(0, &c, 1) > 0) { // Llegeix la dada, la processa i l’envia write(fd[1], &c, 1); } else { // Codi del pare while (read(fd[0], &c, 1) > 0) { // Rep la dada, la processa i la escriu write(1, &c, 1); Compte! El pare ha de tancar fd[1] si no es vol quedar bloquejat! Teniu disponible aquest codi a: pipe_basic.c

Exemple 1 Què fa aquest fragment de codi? ...
fd = open(“fitxer.txt”, O_RDONLY); pid = fork(); while ((n = read(fd, &car, 1)) > 0 ) if (car == ‘A’) numA++; sprintf(str, “El número d’As és %d\n”, numA); write(1, str, strlen(str)); Teniu disponible aquest codi a: exemple1.c Típic compta As (ja feia temps que no el veieu, eh? ) en el qual cada procés en comptarà una part. La suma dels dos comptatges dona el nombre total. Exemple d’accés compartit a un dispositiu.

Exemple 2 Què fa aquest fragment de codi? ... pid = fork();
fd = open(“fitxer.txt”, O_RDONLY); while ((n = read(fd, &car, 1)) > 0 ) if (car == ‘A’) numA++; sprintf(str, “El número d’As és %d\n”, numA); write(1, str, strlen(str)); Teniu disponible aquest codi a: exemple2.c Compte! En aquesta versió cada procés compta TOTES les As independentment. Cal veure que l’open s’ha fet DESPRÉS del fork! Exemple d’accés independent a un dispositiu

Exemple 3 Què fa aquest fragment de codi? ... pid = fork();
if ( pid == 0 ) { close(0); fd1 = open(“/dev/disp1”, O_RDONLY); close(1); fd2 = open(“/dev/disp2”, O_WRONLY); execv(“programa”, “programa”, (char *)NULL); } Executa la comanda: % programa < /dev/disp1 > /dev/disp2 Recordar que la crida open agafa sempre el primer canal disponible. Per tant, close(0)+open fa el mateix que open+close(0)+dup(fd)+close(fd) però, evidentment, és més eficient.

Exemple 4 ... pipe(fd); pid1 = fork(); if ( pid1 != 0 ) { // PARE
close(fd[0]); close(fd[1]); while (1); } else { // FILL 2 close(0); dup(fd[0]); execv(“programa2”, “programa2”, NULL); else { // FILL 1 close(1); dup(fd[1]); execv(“programa1”, “programa1”, NULL); Executa la comanda: % programa1 | programa2 Molt important! Cal tancar els canals de la pipe que no s’han d’utilitzar (els del pare, i els dels fills que no vagin a utilitzar). Altrament els processos fills es quedarien bloquejats indefinidament a la pipe: error molt habitual! Seria interessant que se’ls fes dibuixar com va evolucionant la TC de cada procés Comentar també què passaria si es fa primer fork i després pipe (...)

Exercicis a classe (1) Escriviu un fragment de codi que creï dos processos p1 i p2, i els connecti mitjançant dues pipes pels canals d’E/S estàndard: en la primera p1 hi escriurà i p2 hi llegirà, en la segona p2 hi escriurà i p1 hi llegirà Escriviu un fragment de codi que creï una seqüència de N processos en cadena: cada procés p_i crea un sol descendent p_i+1, fins arribar a p_N. Cada procés s’ha de comunicar en cadena amb l’ascendent i el descendent mitjançant una pipe pel canal d’E/S estàndard, de manera que el que escrigui el primer procés pugui ésser enviat per cadena fins al darrer procés P2 P1 Compte amb el tancament de les pipes!!! P2 P1 P3 PN ...

Exercicis a classe (2) Escriviu un fragment de codi que creï N processos en seqüència: el procés inicial crea tots els descendents p_1 fins arribar a p_N. Cada procés s’ha de comunicar amb el procés pare mitjançant una pipe; el pare ha de poder escriure a totes les pipes (a través dels canals 3..N+2) i els fills han de llegir de la pipe per la seva entrada estàndard. P2 P1 P3 PN ... Pinicial

Índex Conceptes Gestió de l’E/S Gestió de l’E/S a linux
Subsistema d’E/S a linux Operacions d’E/S a linux Descripció de les operacions bàsiques d’E/S E/S i execució concurrent de processos Exemples Dispositius amb accés específic Modificacions de les operacions Optimitzacions de l’E/S Buffering Caching Spooling Planificació de l’E/S Lectures anticipades Escriptures retardades Gestió de l’energia Índex i punts a tractar el 3er dia

Dispositius amb accés específic (1)
Consola Dispositiu lògic que representa un conjunt teclat+pantalla Històricament era l’únic mètode d’accés, ara es diu consola als terminals que treballen en mode text Els sistemes actuals poden tenir múltiples consoles actives El sistema manté, per cada consola, un buffer intern per guardar els caràcters teclejats. Això permet esborrar caràcters abans de ser tractats Posix defineix una funcionalitat particular a certs caràcters especials: ^H: esborrar un caràcter ^U: esborrar una línia ^D: EOF o final de fitxer (final de l’entrada) Pot tenir també un buffer d’escriptura per cada consola i implementar certes funcions especials, del tipus “pujar N línies”, “avançar esquerra” Cada controlador pot implementar la consola tan complicada com vulgui. P.ex. que es pugui modificar text del mig de la línia Habitualment (si no hi ha hagut una redirecció) constitueix l’entrada i sortida estàndard dels processos

Consola: Funcionament Lectura El buffer guarda caràcters fins que es pitja el CR Si hi ha procés bloquejat esperant caràcters, li dona els que pugui Altrament ho guarda; quan un procés en demana li dona directament ^D provoca que la lectura actual acabi amb els caràcters que hi hagi en aquell moment, encara que no n’hi hagi cap: while ( (n=read(0, &car, 1)) > 0 ) write(1, &car, 1); Això, per convenció, s’interpreta com a final de fitxer (EOF) Escriptura Escriu un bloc de caràcters Pot esperar que s’escrigui el CR per ser visualitzat per pantalla El procés no es bloqueja Aquest comportament bloquejant pot ser modificat mitjançant crides al sistema que canvien el comportament dels dispositius

Pipe Buffer temporal amb funcionament FIFO. Les dades de la pipe es van esborrant a mesura que es van llegint Lectura Si hi ha dades, agafa les que necessita (o les que hi hagi) Si no hi ha dades, es queda bloquejat fins que n’hi hagi alguna Si la pipe està buida i no hi ha cap possible escriptor (tots els canals d’escriptura de la pipe tancats), el procés lector rep EOF Cal tancar sempre els canals que no es facin servir Escriptura Si hi ha espai a la pipe, escriu les que té (o les que pugui) Si la pipe està plena, el procés es bloqueja Si la pipe està plena i no hi ha cap possible lector, rep SIGPIPE Aquest comportament bloquejant pot ser modificat mitjançant crides al sistema que canvien el comportament dels dispositius

Dispositius de xarxa Tot i ser un dispositiu d’E/S, la xarxa té un comportament que no pot ser cobert amb les operacions genèriques d’accés als dispositius La gestió dels dispositius de xarxa es realitza de manera separada P.ex: /dev/eth0 no disposa ni de inode ni de device driver Disposen de crides al sistema específiques, i hi ha múltiples propostes La més habitual, és la interfície socket de xarxa Habitualment implementant el protocol IP Tot i què hi ha moltes altres propostes d’interfícies i protocols de comunicació de xarxa que també estan implementades a linux (AppleTalk, IPX, ...) o que són específiques d’altres sistemes operatius, com Windows NT, Unix, … Explicar breument el concepte de xarxa de computadors, internet, adreces IP per identificar un computador, ports (no sé si cal), i socket, com a mecanisme per crear un punt de comunicació d’un procés+computador cap a un altre procés+computador.

Socket: Funcionament Funciona similar a una pipe, excepte que per comptes de dos canals (fd[2]) utilitza un únic canal per la lectura i l’escriptura del socket Es crea un socket, que es connecta al socket d’un altre procés en una altra màquina, connectada a la xarxa Es pot demanar connexió a un socket remot Es pot detectar si una altra es vol connectar al socket local Un cop connectats, es poden enviar i rebre missatges read /write o, més específicament, send /recv Es disposa de crides addicionals que permeten implementar servidors concurrents o, en general, aplicacions distribuïdes P.ex: select P.ex: sendto, recvfrom per usar el protocol UDP Habitualment, s’executen aplicacions amb un model client-servidor Comentar la diferència entre read/write, que funcionen a la xarxa de manera “estàndard” per mantenir la uniformitat de les operacions d’E/S, i les operacions send/revc que permeten configurar el mode de funcionament, segons les característiques pròpies dels dispositius de xarxa. La crida select permet atendre a diversos sockets simultàniament, retornant informació sobre quins d’aquests sockets tenen alguna novetat (event). Aquesta funció ha estat dissenyada exclusivament per operacions de xarxa, encapsulant el comportament particular d’aquest dispositiu. Potser caldria explicar breument les diferències entre TCP i UDP i, per tant, el significat que tenen les crides send/recv i sendto/recvfrom

Socket Socket: Example (pseudo-code) Client ... sfd = socket(...)
connect(sfd, ...) write/read(sfd, ...) Server ... sfd = socket(...) bind(sfd, ...) listen(sfd, ...) nfd = accept(sfd, ...) read/write(nfd, ...) Explicar el pseudo-codi Explicar cada una de les crides... Compte: el servidor utilitza dos fd diferents: un per acceptar peticions de connexió i un altre per comunicar-se amb el procés amb el que s’ha connectat Recordar que també es poden utilitzar les crides send/recv que tenen més funcionalitats específiques dels sockets

Modifying device and file characteristics
It is possible to modify the default behavior of file descriptors and devices Fcntl: Manipulates file descriptor default characteristics Example: close on exec flag. Specifies that fd must be closed if the process mutates int fcntl(fd, cmd, [, args]); Ioctl: Manipulates the underlying device parameters of special files Example: Echo or not echo for keyboard (canonical) int ioctl(fd, cmd [, ptr]);

Modifying file descriptor characteristics
Existeix una crida d’escapament, o porta del darrera (backdoor), que permet fer ajustos dependents d’un dispositiu: ioctl (a linux) Permet que una aplicació accedeixi a qualsevol funcionalitat que pugui ser implementada per un device driver, sense necessitat de crear una nova crida al sistema específica ioctl(fd, cmd [, ptr]); fd és l’identificador del dispositiu cmd selecciona la comanda a executar; depèn de cada dispositiu ptr, si escau, és un apuntador a memòria a una estructura de dades genèrica el contingut de la qual depèn del tipus de request (i de dispositiu)

Modificacions de les operacions (2)
Exemple d’ioctl: Canvi de les característiques del teclat #include <sys/ioctl.h> #include <termio.h> struct termio valors; /* llegeixo els valors actuals */ ret=ioctl(0, TCGETA, &valors); /* modifico el flag de canonical: el dispositiu ja no és canònic */ valors.c_lflag = valors.c_lflag & ~ICANON; /* modifico el nombre màxim de caracters que espero a l’entrada */ valors.c_cc[VMIN] = 2; /* afegeixo límit de temps */ valors.c_cc[VTIME] = 10; /* actualitzo els valors */ ret=ioctl(0, TCSETA, &valors); Hi ha alguna pàgina web a una descripció completa del terminal i la programació de les característiques del terminal? Posar-la… Canònic= Habitual, no rebem els caracters fins que es pulsi CR No canònic= rebem totes les tecles: VMIN: Indica nombre màxim de tecles que llegim VTIME: Estableix un time-out en la lectura struct termio { tcflag_t c_iflag; // input modes tcflag_t c_oflag; // output modes tcflag_t c_cflag; // control modes tcflag_t c_lflag; // local modes cc_t c_cc[N]; // control chars }; Teniu disponible aquest codi a: teclat.c

Modificacions de les operacions (3)
fcntl Modifica el comportament d’un canal (file descriptor) fcntl(fd, cmd, [, args]); fd és l’identificador del dispositiu cmd selecciona la comanda a executar args, si escau, és qualsevol informació addicional que requereixi la comanda; pot ser de tipus long o apuntador a memòria Exemples modificar el fet que el canal es mantingui obert en executar una crida al sistema del tipus exec (close-on-exec) establir diferents tipus de bloquejos (a zones especificades) sobre diferents tipus d’accés (lectura, escriptura, ...) a un fitxer establir el comportament de les operacions d’E/S sobre aquest canal en rebre signals

Índice Introducción Servicios Básicos El Sistema de Ficheros
Organización y Gestión del Disco Acceso a los Ficheros Otros SFs & Arquitecturas

Introducción ¿Qué es un Archivo o Fichero? ¿Qué es un Directorio?
Links. Ficheros especiales Protección. Permisos Introducción

¿Qué es un archivo o fichero?
Conjunto de información relacionada organizada como una secuencia de bytes (espacio de direcciones lógico contiguo) que tiene un nombre Se clasifican según criterios del usuario Datos (alfanumérico, binario, etc.) Programa (fichero ejecutable) Son dispositivos lógicos gestionados por el SO Los programas acceden con las llamadas de sistema de E/S open, read, write, close, .. Y algunas llamadas específicas unlink, chmod, chown, ... Se pueden definir reglas de acceso para que sean compartidos

Tipos de fichero / extensión

Directorio Estructura lógica que organiza los archivos. Puede contener
atributos tipo de archivo tamaño propietario permisos fechas de creación, acceso, modificación, ... ... ubicación en el dispositivo de almacenamiento Es un archivo especial gestionado por el SO no accesible directamente por los usuarios Permite traducir los nombres simbólicos de los ficheros a su ubicación física en el sistema de ficheros

Enlace (link) Nombre simbólico que referencia un objeto ya creado
Por lo tanto, las relaciones pueden ser N:1 Varios nombres para una en el disco 2 tipos de enlaces Enlaces duros (hard-links) No hay diferencia de implementación entre el original y el enlace Enlaces simbólicos (soft-links), o pseudo-enlaces Fichero especial que contiene el nombre de otro fichero

Estructura externa del directorio
Evolución desde 1 nivel, 2 niveles, estructura jerárquica o árbol … Existe un único directorio raíz Cada directorio puede contener ficheros y/o directorios Cada fichero/directorio se puede referenciar de dos maneras Nombre absoluto (único): Camino desde la raíz + nombre Nombre relativo: Camino desde el directorio de trabajo + nombre / separa los componentes del camino . indica el propio directorio .. indica el directorio padre en el árbol

Estructura externa del directorio
… hasta grafo (generalización de árbol) acceso a un fichero desde 2 o + sitios (ficheros/subdirectorios compartidos mediante hard-links o soft-links) Grafos Acíclicos vs Cíclicos Linux utiliza las dos implementaciones Acíclicos para hard-links Cíclicos para soft-links Grafo Acíclico el SF verifica que no se creen ciclos Grafo Cíclico el SF ha de controlar los ciclos infinitos

Problemas de los directorios en grafos
Backups (copias de seguridad) No hacer copias del mismo fichero Eliminación de un fichero Soft links El sistema no comprueba si hay soft links a un fichero Hard links Contar el número de referencias al fichero Borrarlo cuando éste llegue a cero

Protecciones de los archivos
El SF permite asignar diferentes permisos a los archivos De esta manera podemos establecer diferentes niveles de acceso según quién acceda y que operación intente realizar Algunos tipos de permisos: Ninguno Conocimiento Ejecución Lectura Adición Actualización Cambios de protección Borrado Algunas clases de usuarios: Usuario específico Grupo de usuarios El resto de usuarios Las clases pueden estar predefinidas o ser definidas por los usuarios (ACLs)

Listas de acceso y grupos
Algunas clases de usuarios: Usuario específico, Grupo de usuarios, El resto de usuarios Las clases pueden estar predefinidas o ser definidas por los usuarios (ACLs) Ejemplo Modos de acceso Leer (Read), Escribir (Write), Ejecutar (Execute) r w x a) propietario 7  r w x b) grupo 6  1 1 0 c) el resto 1  0 0 1 Revisar Tema 2 (Procesos)

Servicios básicos sobre ficheros
Llamadas al sistema Ejemplos de acceso Servicios básicos sobre ficheros

Servicios básicos sobre ficheros
Llamada a sistema Flags a revisar Crear/Abrir fichero open, creat O_TRUNC, O_CREAT Leer de / escribir en fichero read / write Modificar ptr lectura/escritura lseek SEEK_SET, SEEK_CUR, SEEK_END Crear / eliminar enlace a fichero link / unlink Cambiar permisos de un fichero chmod Cambiar propietario/grupo de un fichero chown / chgrp Obtener información del Inodo stat, lstat, fstat Falta: Explicar mejor cada CAS (parecido al T4) y poner algún otro ejemplo

Ejemplo: Acceso aleatorio a fichero
Qué hace el siguiente fragmento de código? Y este otro? fd = open(“abc.txt”, O_RDONLY); while (read(fd, &c, 1) > 0) { write(1, &c, 1); lseek(fd, 4, SEEK_CUR); } Encontraréis este código en: ejemplo1.c fd = open(“abc.txt”, O_RDONLY); size = lseek(fd, 0, SEEK_END); printf(“%d\n”, size); Encontraréis este código en: ejemplo2.c

Operaciones sobre directorios
Crear/borrar un directorio Cambiar/devolver el directorio de trabajo Directorio en el que se halla ubicado actualmente el usuario Crear/borrar una entrada Al crearse/eliminarse un archivo o subdirectorio Buscar una entrada Localizar en el directorio la entrada correspondiente a un fichero Actualizar entrada Al cambiar algún atributo de un archivo o subdirectorio Enumerar entradas Permite obtener una lista de todos los archivos o subdirectorios dentro del directorio Leer una entrada

Concepto Arquitectura VFS El sistema de ficheros

¿Qué es el Sistema de Ficheros?
Uno de los componentes más visibles del SO Proporciona el mecanismo para almacenar, localizar y recuperar datos y programas del SO y de los usuarios Es una colección de ficheros Y una estructura de directorios Establece un espacio de nombres a través del cual se puede organizar y referenciar unívocamente un fichero Provee abstracciones para gestionar los dispositivos de almacenamiento secundario que: Son no volátiles Se pueden compartir entre procesos Se pueden organizar Son independientes del dispositivo físico

¿Para qué necesitamos un SF?
Responsabilidades del Sistema de Ficheros Asignar espacio libre para los ficheros Liberar el espacio eliminado de los ficheros Encontrar/almacenar los datos de los ficheros Organizar los ficheros en el sistema Garantizar las protecciones de los ficheros ... y todo esto de manera transparente al usuario

Necesidades del sistema de ficheros
Traducir los accesos desde la solicitud de la interfaz de usuario/aplicación (nombre simbólico) hasta los drivers que controlan los dispositivos de almacenamiento (físico) Internamente deberá implementar el propio sistema de ficheros que se está utilizando Definir la apariencia del SF para el usuario Definir archivo y sus atributos Operaciones sobre archivos Estructura directorios para organizar archivos Definir algoritmos y estructuras para mapear SF lógico en los dispositivos físicos de almacenamiento secundario Proceso SF

Arquitectura por capas del SF
Proceso Sistema de ficheros lógico Proporciona la abstracción fichero para realizar la E/S Protección, seguridad Directorios Información sobre archivo para el siguiente nivel Modulo de organización archivos Archivos – bloques lógicos/físicos Administrador espacio libre Sistema de ficheros básico Emite comandos al driver para leer/escribir bloques físicos Llamadas a Sistema Sistema de ficheros lógico Modulo de organización archivos Sistema de ficheros básico Driver de disco Driver de cinta Driver de red

VFS: Virtual File System
Los SO soportan diferentes sistemas de ficheros Linux: ext2, ext3, FAT, ISO9660, XFS, RaiserFS, NTFS, ... Es necesaria una capa en la arquitectura de SF que permita abstraer todos los sistemas de ficheros que acepta el SO como si fuera uno sólo Virtual File System (VFS) proporciona un mecanismo orientado a objetos para implementar diferentes sistemas de ficheros VFS permite la misma interfaz de llamadas a sistema para ser usada con diferentes tipos de sistemas de ficheros Estructura en dos niveles: Estructuras independientes del sistema de ficheros Contiene descripciones de los sistemas soportados Las llamadas al sistema interaccionan con estas estructuras independientes Estructuras dependientes del sistema de ficheros Accedidas a través de las operaciones descritas en el VFS sys_open(), sys_read(), sys_write()… Estructuras internas para identificar ficheros, gestión de espacio de disco, etc

VFS: Virtual File System
Usuario Llamadas a Sistema (open,read,write,...) Virtual File System (VFS) EXT2 EXT3 XFS NTFS NFS Servidor de Bloques

Organización y Gestión del Disco
Estructura del disco Gestión del espacio ocupado Asignación contigua Asignación entrelazada Asignación indexada Gestión espacio libre Particiones Organización y Gestión del Disco

Contenido de una partición: Metadatos
Datos de gestión (metadatos) Datos Metadatos Sector de Arranque (BOOT) Información básica para arrancar el SO instalado en la partición Superbloque Formato del SF (tamaño bloque, #inodos (si el SF los utiliza), #bloques de datos, …) Qué bloques no están siendo utilizados (lista de bloques libres, inodos libres, ...) Qué bloques se han asignado a cada fichero Ejemplo: 2 particiones de sistemas de ficheros basados en Inodos: BOOT Superbloque Datos Inodos Partición 1 Partición 2

Contenido de una partición: Datos
Datos de gestión (metadatos) Datos 1 Bloque = N sectores Datos Información organizada en bloques Sector: unidad de transferencia (definida por el Hw) Bloque: unidad de asignación (definido por el SO) qué tamaño definimos? (Fijo/Variable, Grandes/Pequeños) Bloques Pequeños Aprovecha mejor el espacio, pero hay que hacer muchos accesos Bloques Grandes Aumenta el rendimiento (menos accesos a disco por KB), pero desperdicia espacio

Datos: Bloques de tamaño fijo
Todos los bloques tienen el mismo tamaño Muy sencillo de implementar Compromiso en el tamaño de bloque Eficiencia Fragmentación interna Bloques Sectores Espacio perdido

Datos: Bloques de tamaño variable
Bloques sin compartir sectores Fragmentación interna Bloques compartiendo sectores Uso eficiente del espacio Complejidad muy elevada en la implementación Bloques Sectores Espacio perdido Bloques Sectores

Asignación del espacio ocupado
Proporcionar espacio de almacenamiento secundario a los archivos El SF utiliza una estructura donde guarda la relación entre el archivo y su espacio asignado Normalmente accesible a través del directorio Almacenada en el SF (opcionalmente en memoria) El espacio se asigna en forma de bloques contiguos (secciones)… Cuantos bloques consecutivos? … o en forma de bloques remotos Diversos mecanismos de asignación, pero nos centraremos en: Asignación contigua Asignación enlazada en tabla (FAT) Asignación indexada multinivel

Asignación contigua Todos los bloques del archivo se asignan de manera consecutiva CDROM, DVDs, … Organización: se necesita una única entrada por archivo con Bloque inicial Longitud del archivo Ventajas Acceso eficiente al dispositivo Localización del bloque i-ésimo sencilla Desventajas: Se produce fragmentación externa Necesita asignación previa (determinar el tamaño a priori)

Asignación contigua

Asignación encadenada en tabla
Se enlazan los bloques con punteros En lugar de guardarse en los bloques de datos, los punteros se guardan todos juntos en una tabla Esta tabla se suele llamar FAT (File Allocation Table) Organización: se necesita una única entrada por archivo con Nombre + bloque inicial + tamaño (+ info adicional) Características Para acceder al bloque i-ésimo, basta con acceder a la tabla Se puede replicar la tabla para aumentar la fiabilidad Se puede utilizar para gestionar el espacio libre Inconvenientes Problemas con discos grandes (tabla grande)

Asignación encadenada en tabla
Directorio: Tabla de traducción de nombre simbólico a posición física. Contiene un lista con Nombre + bloque inicial + tamaño (+ info adicional) Tipo de archivo (data, dir, link, …) Propietario Protecciones Fechas Incluye siempre referencias a . y .. Enlaces de tipo soft-link Archivo especial que contiene la ruta (nombre simbólico) del archivo al que hace referencia

Asignación encadenada en tabla (FAT)
Falta: Ejemplos gráficos de SF con FAT

Asignación indexada multinivel
Se crea una estructura jerárquica de bloques índice (i-nodo) Cada apuntador permite acceder a un bloque de datos, pero… …en el bloque índice existen algunos apuntadores indirectos que apuntan a nuevos bloques índice Ventajas Muy pocos accesos, incluso en ficheros grandes Poca perdida de espacio en ficheros pequeños Inconvenientes Añadir o borrar datos que no están al final del fichero

I-nodo: ¿Qué es? Estructura que almacena toda la información relativa a un fichero tamaño tipo protecciones propietario, grupo tiempos de acceso, modificación, creación #enlances al inodo índices a los bloques de datos (indexación multinivel) Excepto el nombre

I-nodo: Ejemplo Tenemos punteros directos
Bloques de disco Bloques de I-Nodos Bloque de datos data data Bloque con direcciones de bloques Tenemos punteros directos Punteros indirectos de nivel: 1 nivel 2 niveles 3 niveles

I-nodo: Tamaño máximo Índices a los bloques de datos (1/4 Kb)
10 índices directos ( 10 bloques = 10/40Kb ) 1 índice indirecto ( 256/1024 bloques = 256Kb/4Mb ) 1 índice indirecto doble ( 65K/1M bloques = 65Mb/4 Gb) 1 índice triple indirecto ( 16M/1G bloques = 16Gb/4 Tb)

I-nodo: Ventajas Toda la información sobre el fichero está localizada en una única estructura Se carga a memoria cuando va a ser usada La mayoría de los ficheros en un sistema Unix son de pequeño tamaño Basta con los índices directos Los punteros a bloques indirectos permiten tener ficheros muy grandes Es poco costoso acceder a distintos bloques en ficheros grandes Aunque sean no consecutivos

Asignación indexada multinivel: organización
Directorio: Tabla de traducción de nombre simbólico a bloque índice (i-nodo). Contiene un lista con Nombre + referencia i-nodo El resto de info (bloques, tamaño, …) se encuentra en el i-nodo Incluye siempre referencias a . y .. Enlaces: soft-link y hard-link Soft-link: Archivo especial (tipo=link) que contiene la ruta (nombre simbólico) del archivo al que hace referencia Hard-link: Nombre simbólico asociado a un mismo i-nodo El i-nodo contiene un contador de referencias (#refs) Falta: Ejemplos gráficos de SF con i-nodos

Gestión del espacio libre
El SF debe tener una estructura que gestione el espacio libre del dispositivo: Tabla de asignación de disco Nos indica qué zonas del disco se encuentran libres Diversos mecanismos, pero nos centraremos en: Mapa de bits Lista de recursos libres Dedicar poco tiempo a los siguientes dos esquemas. Básicamente, centrarse en pros/cons de cada uno

Mapa de bits (bitmap) Contiene un bit por cada bloque del disco
0 = bloque libre 1 = bloque ocupado Ventajas Relativamente fácil encontrar un bloque libre o un grupo contiguo de bloques libres Ocupa poco espacio (se puede tener en memoria) 1 1 1 1 1 1 1 1 1 1

Lista de recursos libres
Puede ser por bloques o secciones (grupo de bloques consecutivos) Apuntamos al primer bloque de un grupo de bloques libres En ese bloque se guarda Si es por bloques Un puntero al siguiente bloque libre Si es por secciones Número de bloques libres consecutivos Dirección del siguiente grupo Ventajas No requiere espacio adicional para guardar qué bloques están libres Problemas La gestión de la lista puede ser ineficiente Si entran en juego muchos bloques Fragmentación

Particiones Partición o volumen o sistema de ficheros
Conjunto de sectores consecutivos al que se le asigna un identificador único y, por tanto, identidad propia para que sean gestionados por el SO como una entidad lógica independiente C:, D: (Windows); /dev/hda1, /dev/hda2 (UNIX) Cada partición tiene su propia estructura de directorios y ficheros independiente de las otras particiones Un disco puede estar sub-dividido en varias particiones Una partición puede tener asociados varios discos físicos Al formatear se está creando la estructura mínima necesaria para gestionar el sistema de ficheros Volumen y partición es lo mismo? En realidad NO es lo mismo, pero no estoy seguro si va a aclarar/confundir a los estudiantes diferenciarlos en esta slide

Acceso a particiones Para poder acceder al SF de un dispositivo primero se ha de montar Existe un dispositivo raíz que se monta en la “/” del sistema de ficheros Los demás dispositivos de almacenamiento se pueden montar en cualquier directorio del SF (punto de montaje) Montar: incluir el dispositivo (la partición) en el SF que maneja el SO para que sea accesible a través de un directorio (punto de montaje) Mount (para montar), umount (para desmontar) # mount –t ext2 /dev/hda1 /home # umount /dev/hda1 / bin etc usr mnt home cdrom dvd user user1 user2 user3 album1 album2 album3

Planificación de acceso a disco
Coste (en tiempo) de acceso a disco Ttotal = Tposicionamiento + Tespera + Ttransferencia Existen algoritmos para minimizar el coste de acceso Algunos de ellos son: First Come First Served Simple y justo No optimiza los accesos al disco Shortest Seek Time First ( SSTF ) Sirve primero las peticiones más cercanas Puede provocar inanición SCAN ( algoritmo del ascensor ) Se hace un barrido disco sirviendo las peticiones que se encuentra a su paso Cuando llega al final da la vuelta y sigue atendiendo peticiones LOOK Cómo SCAN pero si no quedan peticiones por atender en la dirección actual da la vuelta C-SCAN, C-LOOK Igual que las anteriores, pero siempre empiezan por el principio. Quitamos esta transparencia o le dedicamos poco tiempo??? En la última reunión no se comentó (o al menos no lo tengo anotado). Yo opto por quitarla ya que no entramos en tanto detalle

Acceso a Ficheros Estructuras de datos en Linux
Relación entre llamadas a sistema / estructuras de datos Ejemplos de compartición de ficheros Acceso a Ficheros

Estructuras Linux Visto en el T4 struct files_struct
(Tabla de canales) struct file (Tabla de ficheros abiertos) struct inode (Tabla de Inodos) f_pos, f_mode, f_count, ... d_iname, d_count Acceso compartido Acceso concurrente Visto en el T4

Estructuras Linux Tabla de ficheros abiertos Tabla de inodos
Información sobre cada obertura (y sus accesos) sobre un fichero La llamada “lseek” sólo implica actualizar el desplazamiento de la entrada correspondiente en esta tabla. NO implica acceso a disco Tabla de inodos Mantiene en memoria una copia de cada inodo que esté en uso Cache de inodos Cuando se hace un open, si no estaba, se carga en la tabla Cuando se hace el último close se libera de la tabla Buffer cache Cache de bloques Unificada para todos los accesos a dispositivos Pros y Contras en general… Pros: información en memoria  NO acceder al disco Contras: consumo de memoria

Relación syscalls-estructuras de datos (linux)
Las llamadas a sistema modifican las estructuras de datos y pueden generar accesos a disco (o no) Open Implica acceder a todos los bloques de datos de los directorios implicados y a todos los bloques que contengan los inodos necesarios El último acceso a disco es el del inodo del fichero que abrimos Modifica la tabla de canales, la tabla de ficheros abiertos y, potencialmente, la tabla de inodos (sólo si es la primera vez que accedemos al fichero)

Relación syscalls-estructuras de datos (linux)
Read Implica leer los bloques de datos (suponiendo que no están en la buffer cache) Puede suponer 1 o N accesos a disco dependiendo del tamaño de los datos que queremos leer También influye en el número de accesos si los bloques de datos están apuntados por índices directos (en el inodo) o índices indirectos (en bloques de datos) Objetivo: Saber calcular qué accesos a disco y de qué tipo generan las llamadas a sistema de gestión de E/S. Saber qué modificaciones generan en las tablas de gestión de E/S las llamadas a sistema de E/S

Ejemplo Open(/a/b..)  i-nodo 2 + bloque 3 + i-nodo 3 + bloque 5 + i-nodo 5 + bloque 1 + i-nodo 2 + bloque 3 + i-nodo 4 + bloque 4 + bloque 6 + i-nodo 8 12 accesos a disco sin buffer cache, 10 con buffer cache Read 1 acceso a disco Open(/a/b..)  i-nodo 2 + bloque 3 + i-nodo 3 + bloque 5 + i-nodo 5 + bloque 1 + i-nodo 2 + bloque 3 + i-nodo 4 + bloque 4 + bloque 6 + i-nodo 8 12 accesos a disco

Ejemplo de flujo de datos
Quitamos esta transparencia??? O dedicar poco tiempo????

Ejemplo del uso de las tablas internas
Un proceso “A” abre: fd1 = open(“/etc/passwd”, O_RDONLY); fd2 = open(“.cshrc”, O_RDWR); fd3 = open(“/etc/passwd”, O_WRONLY); Un proceso “B” abre:

El proceso “A” crea un proceso hijo, “C”: como afecta un fork

Optimització de l’E/S Buffering Caching Spooling Planificació de l’E/S
Lectures anticipades Escriptures retardades Gestió de l’energia En aquest punt NO incloc la planificació de les operacions d’E/S ja que, entenc, això té un efecte principalment sobre el disc. I aquest punt es tracta al Tema 5, oi??? Altrament el posaria aquí… Optimització de l’E/S

Optimització de l’E/S (1)
Buffering Buffer: Àrea de memòria que guarda dades temporalment Consisteix en mantenir un (o varis) buffers en el sistema per donar suport a l’execució d’algunes operacions d’E/S Objectius: Amortir la diferència de velocitat entre productor i consumidor Adaptar la transferència de dades entre dispositius que, físicament, utilitzen blocs de mida diferent Suportar la “semàntica de la còpia” en les operacions d’E/S El buffer guarda les dades, habitualment, mentre es transfereixen d’un dispositiu a un altre o mentre es transfereixen entre un dispositiu i un procés. P.ex. Transferència de dades entre un mòdem i un disc. El mòdem és uns 1000 cops més lent que el disc. Per tant, es llegeixen les dades del mòdem en un buffer. Quan aquest està ple, s’escriu al disc d’un sol cop. Tot i que l’escriptura a disc serà molt ràpida, caldria un buffer addicional per seguir llegint del mòdem mentre s’està escrivint al disc: doble buffer. Cal recordar que, a més, el sistema usa un tamany de bloc independent de qualsevol dispositiu. Per tant, aquesta tècnica és fonamental, per exemple, per escriure un bloc a un dispositiu que té tamany de bloc més gran que el del sistema. Aquest cas es refereix a que si una aplicació escriu un buffer a disc i, abans de que s’hagi realitzat la escriptura (recordar que la crida al sistema pot retornar abans), l’aplicació modifica el buffer. Cal fer una còpia interna d’aquest buffer d’usuari abans de retornar de la crida.

Caching Cache: Zona de memòria ràpida que conté còpies de dades Consisteix en utilitzar la còpia de la dada (cache), per comptes de la dada original, per augmentar la velocitat d’accés Exemples: Caches de disc: Mecanisme software que permet mantenir a memòria dades que normalment estarien a disc Si cal llegir varis cops el mateix bloc, es carrega un sol cop i es llegeix de la cache Si cal escriure varis cops el mateix bloc, s’escriu a la cache En algun moment, periòdicament, s’escriu a disc Explicar breument el concepte de caches de disc, tot i que segurament aquest concepte quadraria més en el Tema 5. Aquesta optimització permet, addicionalment, mantenir pendents vàries operacions de L/E a disc amb lo qual, indirectament, permet millorar la planificació de les operacions sobre disc.

Spooling Spool: Buffer que conté la sortida cap a un dispositiu que no pot acceptar fluxos de dades intercalats (P.ex: impressora, cinta) Permet que vàries aplicacions puguin escriure simultàniament a un dispositiu, tipus impressora, sense que es barregin els treballs Cal que el sistema implementi un mecanisme de cues de treballs pendents i un procés (daemon) que vagi processant un treball darrera l’altre Opcionalment, en funció del dispositiu físic, el sistema pot implementar també algun tipus d’optimització addicional en la planificació dels treballs

Planificació de les operacions d’E/S Aprofitant que les E/S són asíncrones No es processen al moment Es guarden en una cua i es van reactivant segons arriben les interrupcions de final d’operació …es reordenen per tal de millorar el rendiment Mínim moviment (rebobinat) de la unitat de cinta Mínim moviment del capçal del disc S’intenten solapar operacions a blocs consecutius a disc, per tal de realitzar les operacions amb una única programació del controlador El sistema disposa d’una rutina (strategy) que és l’encarregada d’implementar diferents polítiques d’optimització, en funció del dispositiu i del comportament del propi sistema

Altres optimitzacions: Lectura S’intenta mantenir a memòria una còpia de part de les dades que hi ha a disc (cache). A més, aprofitant la característica que molts arxius es llegeixen seqüencialment: Lectures anticipades (read ahead): es porta el bloc demanat, més altres blocs consecutius Es programen menys operacions de L/E Es produeix menys moviment del capçal Però si l’accés és random: problema! Hi ha un flag associat a l’arxiu que indica si cal fer read ahead Quan lseek el flag es posa a 0, quan read es torna a posar a 1

Altres optimitzacions: Escriptura Es guarden les dades a memòria (cache) i es realitza l’escriptura retardada, a intervals, aprofitant moments en què el dispositiu està parat Les escriptures no són crítiques, ja que els processos no s’esperen a que acabin S’escriu preferiblement en intervals en què el dispositiu està parat Això permet agrupar diferents escriptures d’un mateix bloc Es guarden les escriptures fins al “darrer moment” bdflush: escriu quan les caches estan plenes …tot i que cal minimitzar danys en cas de fallada del sistema kupdate: escriu cada cert interval de temps, definit com a part de la configuració del sistema threads de kernel bdflush i kupdate són threads de kernel que s’encarreguen de realitzar les escriptures de la buffer cache a disc. Els intervals del kupdate poden dependre també de la importància de la informació que han d’escriure: no tarda el mateix en escriure un bloc de dades que en escriure el superbloc de disc, si fos el cas. Cal tenir en compte que també es poden escriure els buffers a petició expressa de l’usuari, mitjançant certes crides al sistema: synch(), fsynch(), fdatasynch()

Gestió de l’energia (1) Un PC actual consumeix uns 200 watts d’energia
Amb una eficiència del 85%: el 15% es perd en calor Es calcula que hi ha constantment uns 100 milions d’ordinadors funcionant megawatts (equivalent a unes 20 centrals nuclears) Els principals consumidors d’energia són: pantalla, disc dur i CPU Aprox: 60%, 15-20% i 10-15% respectivament Aspectes hardware Bateries dels portàtils: tipus, consum, duració, contaminació CPU, memòria i perifèrics amb diferents modes de treball: en marxa, inactius i apagats La primera computadora, l’ENIAC, tenia tubs de buit i consumia watts de potència. Amb l’aparició dels transistors, el consum va baixar dràsticament (200 watts un PC actual) i, per tant, el consum energètic va deixar de ser prioritari. Però el nombre de computadores que constantment hi ha en funcionament és enorme. Es calcula que uns 100 milions simultàniament: això representa un consum d’uns megawatts! (equival a unes 20 centrals nuclears de tamany mitjà). La reducció del consum es pot fer des de dos perspectives: hardware i software, i sovint amb la cooperació dels dos nivells: el hardware proporciona diferents modes de treball per a què el software en tregui profit. En referència al hardware, es treballa en millorar les prestacions de les bateries en aspectes com: tecnologia de fabricació, cost i temps de càrrega, si cal que estigui descarregada abans de fer una nova càrrega, temps de vida de la bateria, i contaminació un cop es deixa de fer servir. Per altra banda, es treballa en proporcionar components i dispositius amb diferents modes de treball: en funcionament, inactius (per poc temps), en hibernació (per més temps) o apagats. En aquest cas hi ha un compromís entre reduir el consum i temps que es tarda en restablir el funcionament del dispositiu. És responsabilitat del sistema operatiu fer-ne un bon ús d’aquestes característiques.

Gestió de l’energia (2) El principal responsable d’implementar polítiques de reducció del consum energètic és el sistema operatiu Tot i que les aplicacions també es poden programar segons models d’execució de menor consum Dues estratègies, a nivell de sistema operatiu: Apagar components del sistema: principalment perifèrics Degradar la qualitat del servei que rep un procés Addicionalment, es pot dissenyar una interfície que permeti la cooperació entre el sistema operatiu i les aplicacions d’usuari El sistema informa sobre l’estat dels dispositius i l’aplicació utilitza aquesta informació per realitzar unes tasques o unes altres Tot i que les aplicacions també es poden escriure de manera que minimitzi el consum energètic (no és objectiu d’aquesta assignatura revisar els models), el sistema operatiu té més capacitat d’influència, ja que aquest administra els recursos i els serveis per a TOTES les aplicacions. En aquest cas, el repte és implementar polítiques que detectin a temps que es deixa d’usar un cert component del sistema i desactivar-lo: cal balancejar l’estalvi en apagar un component i el cost de tornar a posar-lo en marxa. En qualsevol cas, les estratègies d’estalvi energètic són, sovint, a cost de perdre qualitat de servei: temps d’espera per reactivar un dispositiu, baixa velocitat, pèrdua de qualitat d’imatge, … Finalment, es pot dissenyar una interfície que permeti coordinar el sistema operatiu i l’aplicació d’usuari: el sistema operatiu proporciona informació sobre l’estat dels dispositius i les aplicacions utilitzen aquesta informació per realitzar certes tasques en un moment o altre.

Gestió de l’energia. Exemples (3)
Pantalla Apagat automàtic, que habitualment es deixa que ho configuri l’usuari; el reactivat és quasi instantani Il·luminat de zona parcial de la pantalla, la que ocupi la finestra activa Disc dur Cal mantenir-lo constantment girant a alta velocitat: cost energètic! Es pot parar, però el cost de reactivar-lo és elevat en quant a temps i consum energètic Cal implementar una molt bona política de predicció d’ús Es pot complementar l’optimització mitjançant una bona cache de disc i mitjançant les escriptures retardades Cooperació sistema-aplicació: En programes tipus processador de texts es pot configurar que es salvi el document periòdicament però preferiblement en moments en els quals el disc estigui en estat actiu

Gestió de l’energia. Exemples (4)
CPU La CPU dels portàtils es pot posar en estat inactiu mitjançant software, i es torna a activar mitjançant una interrupció La CPU pot reduir la velocitat a la meitat, reduint el consum en ¾ parts Cal implementar polítiques de predicció de manera que el sistema configuri adequadament el mode de treball de al CPU Altres components Memòria: Buidar la cache i desactivar-la temporalment, o copiar-la completament a disc en estat d’hibernació La comunicació inalàmbrica consumeix molta energia, però si es desconnecta es perdria la informació: modificar el router per a què guardi la informació en un buffer i s’esperi a que es connecti la WiFI Quan puja la temperatura, valorar si posar en marxa el ventilador o posar els components en mode de baix consum

Dynamic Kernel Module Support

Dynamic Kernel Module Support
It enables kernel device drivers to be automatically rebuilt when a new kernel is installed. It allows to add/remove kernel code without restarting the system It is particularly used to add device drivers code - Quan es diu “... fabricar nous dispositiu ... Cal proporcionar...” es refereix a que el FABRICANT ha de proporcionar el driver amb aquestes característiques. I quan es diu “... afegir nous dispositius ... Cal que el SO...” es refereix a que el SO ha de proporcionar el mecanisme d’inserció dinàmica per facilitar la independència.

Device Drivers Set of functions and data that implements device management It follows kernel specifications (open, read, write, ...) Each O.S. defines its own API It implements device dependent operations (and code ) They usually include low level code (assembler) I/O ports and registers, interrupt management, ... We can find as many device drivers as device types, vendors, O.S., and models exists We can also find different device drivers versions for the same case

Linux Device Driver Device driver code content
Informació general sobre el DD: nom, autor, llicència, descripció, ... Implementació de les funcions genèriques d’accés als dispositius open, read, write, ... Implementació de les funcions específiques d’accés als dispositius Programació del dispositiu, accés als ports, gestió de les ints, ... Estructura de dades amb llista d’apuntadors a les funcions específiques Funció d’inicialització S’executa en instal·lar el DD Registra el DD en el sistema, associant-lo a un major Associa les funcions genèriques al DD registrat Funció de desinstal·lació Desregistra el DD del sistema i les funcions associades Exemple de DD: veure myDriver1.c i myDriver2.c de la S8 de laboratori

Inserció dinàmica de codi
El kernel ha d’oferir un mecanisme per afegir codi i dades al kernel, sense necessitat de recompilar el kernel Una recompilació completa del kernel podria tardar hores... Actualment la inserció es fa dinàmicament (en temps d’execució) Dynamic Kernel Module Support (linux) o Plug&Play (windows) Inserció dinàmica de codi de gestió dels dispositiu d’E/S Combina el concepte de mòdul + device driver S’empaqueta el codi+dades de gestió del dispositiu (device driver) S’insereix dinàmicament el driver en el kernel del sistema (mòdul) Permet connectar dinàmicament dispositius al sistema Permet afegir dinàmicament el codi de gestió dels dispositius al sistema En quant al funcionament, cal deixar clar que el driver es pot carregar dinàmicament, però també en el moment de boot si es deixa instal·lat permanentment. Cal explicar què és el major (tipus de dispositiu, i.e. quin driver es farà servir) i què és el minor (instància del dispositiu de tipus “major”, per exemple, en el cas de tenir dues impresores del mateix tipus). Per altra banda, personalment, no crec que sigui interessant, en aquest punt, entrar en detall sobre els dispositius de tipus char o tipus bloc. Així que ho obviaria… I en el moment d’explicar la comanda mknod en el laboratori posar l’argument c sense incidir en què significa.

Mòduls d’E/S a linux Funcionament:
Compilar el DD, si escau, en un format determinat: .ko (kernel object) Instal·lar (inserir) en temps d’execució les rutines del driver insmod fitxer_driver Recordar que el driver està associat a un major Crear un dispositiu lògic (nom d’arxiu en el FS) i lligar-lo amb el driver El dispositiu s’identifica amb 2 nombres major (tipus de dispositiu) minor (instància de dispositiu del tipus major) El dispositiu queda lligat al driver a través del major Comanda mknod mknod /dev/mydisp c major minor El dispositiu ja està llest per ser utilitzat, mitjançant el nom d’arxiu open(“/dev/mydisp”, ...); En quant al funcionament, cal deixar clar que el driver es pot carregar dinàmicament, però també en el moment de boot si es deixa instal·lat permanentment. Cal explicar què és el major (tipus de dispositiu, i.e. quin driver es farà servir) i què és el minor (instància del dispositiu de tipus “major”, per exemple, en el cas de tenir dues impresores del mateix tipus). Per altra banda, personalment, no crec que sigui interessant, en aquest punt, entrar en detall sobre els dispositius de tipus char o tipus bloc. Així que ho obviaria… I en el moment d’explicar la comanda mknod en el laboratori posar l’argument c sense incidir en què significa.

T4-Input/Output Management

Presentaciones similares

Presentación del tema: "T4-Input/Output Management"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

T4-Input/Output Management

Presentaciones similares

Presentación del tema: "T4-Input/Output Management"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback