EntradaSaida prova 3
29 pág.

EntradaSaida prova 3


DisciplinaSistemas Operacionais I9.183 materiais182.212 seguidores
Pré-visualização3 páginas
do SO, usualmente bem
escondidos
\u2022 Tendo o driver iniciado uma operação de E/S o mesmo é bloqueado até
que a operação se complete e uma interrupção ocorra
\u2022 Operações sobre semáforos, receive mensagem
\ufffd Ocorrendo a Interrupção a rotina de interrupção faz sua tarefa
\u2022 Em seguida libera o driver que iniciou a operação de E/S
\u2022 Processar uma interrupção não é apenas interceptar uma interrupção, 
sinalizar o driver e executar um IRET
\u2022 Existe trabalho adicional realizado pelo SO 
16
5-1.31INE5355 \u2013 Sistemas Operacionais I
Tratadores de Interrupção (2)
\ufffd Passos que devem ser realizados em software depois da interrupção ser 
completada
1. Salvar regs ainda não salvos por hardware
2. Inicializar contexto para rotina de interrupção(TLB, MMU, tab. páginas)
3. Inicializar pilha para rotina de interrupção
4. Atender controlador de interrupções, reabilitar interrupções
5. Copiar registradores de onde foram salvos (pilha) para tabela de 
processos
6. Executa rotina de tratamento, extrai informações dos registradores do 
controlador do dispositivo que está interrompendo
7. Escolhe próximo processo a executar. 
8. Estabelece contexto MMU para próximo processo
9. Carrega registradores do próximo processo (PSW)
10. Inicia execução do processo
5-1.32INE5355 \u2013 Sistemas Operacionais I
\ufffd Posicionamento lógico dos drivers de dispositivos
\ufffd Comunicações entre os drivers e os controladores dos dispositivos
acontece através do barramento
Tipos:
Bloco 
Caracter
Interface padrão
Kernel / usuário
Estáticos/dinâmicos
Programação do 
dispositivo
Reentrantes
Interação com o SO 
Drivers de Dispositivos
17
5-1.33INE5355 \u2013 Sistemas Operacionais I
Software Independente de dispositivo
\ufffd Interface uniforme para os drivers dos dispositivos
\u2022 Padrão de interface para o SO
\u2022 Nomes dos dispostivos : /dev/disk0
\u2022 Padrão de proteção (rwx)
\ufffd Armazenamento em Buffer
\u2022 Dispositivos de bloco \u2013 manter até bloco inteiro ser escrito 
\u2022 Dispositivos de caracter \u2013 escrita + rápida que saída, 
entrada chega antes 
\ufffd Relatório de erros
\u2022 Erros reportados independente do dispositivo
\ufffd Alocação e liberação de dispositivos dedicados
\ufffd Tamanho de bloco independente de dispositivo
\u2022 Nem todos os discos tem o mesmo tamanho de setor
5-1.34INE5355 \u2013 Sistemas Operacionais I
Software Independente de dispositivo (2)
(a) Sem uma interface padrão do driver
(b) Com uma interface padrão do driver
Tamanho de bloco
independente de dispositivo
Alocação e liberação de 
dispositivos dedicados
Relatório de erros
Armazenamento em Buffer
Interface uniforme para os
drivers dos dispositivos
18
5-1.35INE5355 \u2013 Sistemas Operacionais I
Figure 3.13. I/O buffers.
5-1.36INE5355 \u2013 Sistemas Operacionais I
Software de E/S no espaço
do usuário
\u2022 Bibliotecas de E/S - write(fd,buffer,nbytes), printf(\u201c....\u201d), scanf, ..
\u2022 sppoling (daemon) \u2013 gerencia dispositivos dedicados 
19
5-1.37INE5355 \u2013 Sistemas Operacionais I
Camadas do sistema de E/S e as funções principais de cada
camada. 
Ex: leitura de arquivo (bloco)
5-1.38INE5355 \u2013 Sistemas Operacionais I
UNIX SVR4 E/S
20
5-1.39INE5355 \u2013 Sistemas Operacionais I
Figure 3-16. Two ways of structuring user-
system communication.
5-1.40INE5355 \u2013 Sistemas Operacionais I
Figure 3-18. Outline of the main procedure of 
an I/O device driver.
21
5-1.41INE5355 \u2013 Sistemas Operacionais I
Figure 2-46. (a) Worst case for reading a block requires eleven 
messages. (b) Best case for reading a block requires four 
messages.
5-1.42INE5355 \u2013 Sistemas Operacionais I
Linux Input and Output
\ufffd Linux splits all devices into three classes:
\u2022 block devices allow random access to completely 
independent, fixed size blocks of data
\u2022 character devices include most other devices; they don\u2019t 
need to support the functionality of regular files.
\u2022 network devices are interfaced via the kernel\u2019s networking 
subsystem
Silberschatz, Galvin and Gagne \uf6d92002
22
5-1.43INE5355 \u2013 Sistemas Operacionais I
Linux Device-Driver Block Structure
Silberschatz, Galvin and Gagne \uf6d92002
5-1.44INE5355 \u2013 Sistemas Operacionais I
Block Devices
\ufffd Provide the main interface to all disk devices in a system.
\ufffd The block buffer cache serves two main purposes:
\u2022 it acts as a pool of buffers for active I/O
\u2022 it serves as a cache for completed I/O
\ufffd The request manager manages the reading and writing of 
buffer contents to and from a block device driver.
Silberschatz, Galvin and Gagne \uf6d92002
23
5-1.45INE5355 \u2013 Sistemas Operacionais I
Character Devices
\ufffd A device driver which does not offer random access to 
fixed blocks of data.
\ufffd A character device driver must register a set of functions 
which implement the driver\u2019s various file I/O operations.
\ufffd The kernel performs almost no preprocessing of a file 
read or write request to a character device, but simply 
passes on the request to the device.
\ufffd The main exception to this rule is the special subset of 
character device drivers which implement terminal 
devices, for which the kernel maintains a standard 
interface.
Silberschatz, Galvin and Gagne \uf6d92002
5-1.46INE5355 \u2013 Sistemas Operacionais I
Linux Device Management
\ufffd Each time the device is given a command, for example 
``move the read head to sector 42 of the floppy disk'' the 
device driver has a choice as to how it finds out that the 
command has completed. 
\ufffd Two basic approaches to device management in Linux
are available:
\u2022 Use Polling to determine when a device has completed an
operation. 
\u2022 Use interrupts.
Gary Nutt \uf6d92001
24
5-1.47INE5355 \u2013 Sistemas Operacionais I
Linux Device Management
\ufffd Polling case, the user process performs an I/O request
(read()) at the system call interface. This cause the
device driver to start the device.The task polls the device
to determine when the operation is completed. 
Gary Nutt \uf6d92001
5-1.48INE5355 \u2013 Sistemas Operacionais I
Linux Device Management
\ufffd Interrupts - An interrupt driven device driver is one where the hardware 
device being controlled will raise a hardware interrupt whenever it needs 
to be serviced. For example, an ethernet device driver would interrupt 
whenever it receives an ethernet packet from the network. The Linux 
kernel needs to be able to deliver the interrupt from the hardware device 
to the correct device driver. This is achieved by the device driver 
registering its usage of the interrupt with the kernel. It registers the 
address of an interrupt handling routine and the interrupt number that it 
wishes to own. 
\ufffd You can see which interrupts are being used by the device drivers, as 
well as how many of each type of interrupts there have been, by looking 
at /proc/interrupts: 
\u2022 0: 727432 timer 
\u2022 1: 20534 keyboard 
\u2022 2: 0 cascade 
\u2022 3: 79691 + serial 
\u2022 4: 28258 + serial 
\u2022 5: 1 sound blaster 
\u2022 11: 20868 + aic7xxx 
\u2022 13: 1 math error 
\u2022 14: 247 + ide0 
\u2022 15: 170 + ide1 
\ufffd http://www.tldp.org/LDP/tlk/tlk.html
Gary Nutt \uf6d92001
25
5-1.49INE5355 \u2013 Sistemas Operacionais I
Linux Device Management
\ufffd A device driver, IRQ, ISR, and a device bottom half might
be involved in carrying out the operation.
\ufffd When a process issues an I/O request to the kernel the
device driver checks the status of the device and, if the
device is available, starts it on the I/O operation.
\ufffd The task blocks in state TASK_INTERRUPTIBLE
\ufffd Meanwhile, the device operates until it completes the
operation, at which time it issues an IRQ to the CPU 
Gary Nutt \uf6d92001
5-1.50INE5355 \u2013 Sistemas Operacionais I
Linux Device Management
\ufffd The IRQ causes the ISR that is associted with the IRQ to 
be executed
\ufffd The ISR performs a minimum of the processing tasks
associated wth the completion of the operation and marks
its bottom half for later processing if needed.
Gary Nutt \uf6d92001
26
5-1.51INE5355 \u2013 Sistemas Operacionais I
Linux Device Management
\ufffd Once the ISR, and all other ISRs that might have
interrupted the original ISR, have completed, the
ret_from_sys_call code block is executed.
\ufffd