IFPE. Disciplina: Sistemas Operacionais. Prof. Anderson Luiz Moreira

Transcrição

1 IFPE Disciplina: Sistemas Operacionais Prof. Anderson Luiz Moreira

2 SERVIÇOS OFERECIDOS PELOS SOS 1 Introdução O SO é formado por um conjunto de rotinas (procedimentos) que oferecem serviços aos usuários do sistema e suas aplicações, bem como outras rotinas do próprio sistema. Esse conjunto de rotinas é chamado núcleo do sistema ou Kernel. O SO é um prestador de serviços ao usuário. As principais funções do núcleo são: Tratamento de interrupções; Criação e eliminação de processos; Sincronização e comunicação entre processos; Escalonamento e controle dos processos; Gerência de memória; Gerência do sistema de arquivos; Operações de entrada e saída; Contabilização e segurança do sistema. 2 System Calls Na maioria dos projetos de sistemas operacionais existe a preocupação de proteger o núcleo do sistema e permitir acesso aos seus serviços, para isso são implementados mecanismos para evitar que uma operação realizada por uma aplicação danifique todo o sistema tornando-o comprometido e inoperante. O usuário e sua aplicação, quando deseja solicitar serviço do sistema, realiza uma chamada a uma de suas rotinas através de system calls (chamadas ao sistema), que são a porta de entrada para se ter acesso ao núcleo do sistema operacional. Para cada serviço existe uma system call associada e cada sistema operacional tem o seu próprio conjunto de biblioteca de chamadas, com nomes, parâmetros e formas de ativação específicas. aplicação System Calls NÚCLEO H A R D W A R E Figura 1 System Call Através dos parâmetros fornecidos na system call, a solicitação é processada e uma resposta é retornada à aplicação, em um dos parâmetros fornecidos na chamada. O mecanismo de ativação e comunicação entre a aplicação e o sistema é semelhante

3 ao mecanismo implementado quando um programa modularizado ativa um dos seus procedimentos e funções. Este mecanismo de chamadas de sistema pode ser observado no caso do comando read em um programa em C, que tem o seguinte formato: Count = read ( file, buffer, nbytes) ; O efeito de se executar um procedimento read, fazendo uma chamada à rotina READ do SO é o de fazer com que os dados de um determinado arquivo sejam lidos para um buffer, onde o programa possa então ter acesso a esses dados. O procedimento retorna em count o número de bytes efetivamente lidos. Este valor normalmente coincide com o de nbytes podendo ser menor, se, por exemplo, o símbolo de fim-de-arquivo (EOF) for encontrado durante a leitura. Se a chamada de sistema não puder ser realizada, por conta de um parâmetro inválido ou de um erro de disco, count é feito igual a 1, e o número correspondente ao erro é colocado em uma variável global, de onde o programa pode inspecioná-lo. Os programas devem verificar o resultado de suas chamadas de sistema, para ver se houve ou não a ocorrência de erro. As system calls podem ser divididas em grupos de função: Gerência de processos Criação e eliminação de processos; Alteração das características do processo; Sincronização e comunicação entre processos. Gerência de memória Alocação e desalocação de memória. Gerência de E/S Operação de entrada/saída em periféricos; Manipulação de arquivos e diretórios. Manutenção de informação Obter/atualizar data e hora; Informar número de usuários; Informar versão do SO; Apresentar quantidade de memória disponível; Etc...

4 3 - Funcionamento do System Call O usuário carrega os parâmetros necessários nos registradores indicados e executa uma instrução para chamar a função desejada. Imediatamente é gerada uma interrupção para a posição correspondente à função X no vetor de interrupções. Lá a CPU passa para o modo monitor ou Kernel e desvia sua execução para o início da função X. Terminada a execução da função X, muda-se novamente o modo CPU para modo usuário e retorna-se ao programa que chamou o system call Carrega parâmetros P Chama a função X Interrupção Retorna Desvio Vetor de interrupção Função X: Utiliza parametros P Executa função X Funções Do System Calls Área de usuário Área do SO Figura 2 Funcionamento de System Call 4 Modos de Acesso Algumas instruções não devem ser colocadas diretamente à disposição das aplicações de usuário, pois a sua utilização ocasionaria sérios problemas à integridade do sistema. Suponha que uma aplicação deseja atualizar um arquivo em disco. Como o disco é um recurso compartilhado, sua utilização deverá ser realizada unicamente pelo sistema operacional, evitando que a aplicação possa ter acesso a qualquer área do disco indiscriminadamente, o que poderia comprometer a segurança do sistema. Existem certas instruções como operações de E/S, que só podem ser executadas pelo SO, para impedir a ocorrência de problemas de segurança e mesmo violação do sistema. As instruções que tem o poder de comprometer o sistema são conhecidas como instruções privilegiadas, e as que não oferecem perigo ao sistema, são as instruções não-privilegiadas.

5 Para que uma aplicação possa executar uma instrução privilegiada, o processador implementa o mecanismo de modos de acesso. Existem basicamente dois modos de acesso implementados pelo processador: modo usuário e modo Kernel. Quando o processador trabalha no modo usuário, uma aplicação só pode executar instruções não-privilegiadas, tendo acesso a um número reduzido de instruções, enquanto no modo Kernel a aplicação pode ter acesso ao conjunto total de instruções do processador. O modo de acesso é determinado por um conjunto de bits, localizados em um registrador especial da CPU, que indica o modo de acesso corrente. Através desse registrador, o hardware verifica se a instrução pode ou não ser executada pela aplicação. Para controlar o acesso às instruções privilegiadas é necessário permitir que apenas o SO tenha acesso a elas. Sempre que uma aplicação necessita de um serviço que incorra em risco para o sistema, a solicitação é feita através de uma system call. A system call altera o modo de acesso do processador para um modo mais privilegiado (modo kernel). Ao término da rotina do sistema, o modo de acesso é retornado para o modo usuário. Caso um programa tente executar uma instrução privilegiada, sem o processador estar no modo kernel, uma exceção (erro) é gerada e o programa é encerrado. Um exemplo é o problema do acesso ao disco, apresentado anteriormente para o programa conseguir atualizar o arquivo, aplicação deve solicitar a operação ao sistema por meio de uma system call. A chamada altera o modo de acesso do programa para kernel. A rotina do sistema responsável pela leitura é então realizada e, a seguir, o modo de acesso volta ao estado usuário para continuar o processamento de programa. O núcleo do sistema operacional sempre é executado em modo kernel, pois deve possuir a capacidade de gerenciar e compartilhar todos os seus recursos, solucionando, em diversos níveis, os problemas de acesso às instruções privilegiadas.

6 Memória Principal desvio SO Rotina do sistema SO executa no modo kernel retorno Programa do usuário A Programa do usuário B System call Programas executam no modo usuário Figura 3 Chamadas do sistema 5 - Interpretador de comandos O SO executa suas funções seguindo as ordens que o usuário determina. O SO reúne os recursos necessários, e ativa o módulo responsável pela realização da tarefa. O processador de comandos consiste em alguns módulos, cada um dos quais executa uma única tarefa. Por exemplo, um módulo contém as instruções que dirigem o computador através do processo de copiar um programa do disco e carregá-lo na memória principal. Um outro contém as instruções que transferem o controle do computador para aquele programa. O programa mais importante para o SO é o interpretador de comandos. Cabe a ele interpretar os comandos pedidos pelo usuário e encaminhar a execução do programa adequado para tal tarefa. Alguns dos comandos pedidos pelo usuário estão embutidos no próprio interpretador de comandos. São os chamados comandos residentes. Os projetistas de SO levam em consideração dois fatores para colocar um comando como residente: 1) Utilização freqüente 2) Simplicidade do programa

7 Memória Principal Sistema Operacional Interpretador de comandos Executa programas Interpreta comandos Cria arquivos Carrega programas Outros comandos Outros módulos do SO Programas Aplicativos Figura 4 Interpretador de Comandos Em oposição aos residentes, têm-se os comandos transitórios, ou seja, aqueles que ficam armazenados em memória secundária, havendo necessidade do interpretador de comandos pedir ao SO para carregá-lo na memória principal a fim de serem executados. Nesse grupo estão: - Utilitários : programas fornecidos juntamente com o SO, são voltados à operação do sistema. - Aplicativos : são adquiridos separadamente do SO, são voltados para aplicações específicas (banco de dados, compiladores, processadores de texto, planilhas de cálculo, etc...)

8 Mensagem de erro Interpretador Comando Residente? NÃO Busca comando no Disco SIM Executa o comando Achou? NÃO Mensagens de execução SIM Carrega programa na memória Figura 5 O Funcionamento do Interpretador de Comandos 6 O Interpretador de comandos do Unix (Shell) O SO é o código executor das chamadas de sistema. O interpretador de comandos Shell do Unix é também a interface entre o usuário de um terminal e o SO. Quando um usuário abre uma sessão, o shell assume o controle da situação, enviando ao terminal o sinal de prompt, um caractere semelhante ao símbolo do dólar, que informa ao usuário que o shell está esperando um comando. Se o usuário teclar, por exemplo, date o shell cria um processo e roda o programa date. Enquanto este processo estiver rodando, o shell permanece à espera de seu término. Quando isto ocorre, o shell envia outra vez o sinal de prompt, esperando para ler a próxima linha de entrada. Se o usuário colocar o símbolo & após um comando, o shell não aguarda que ele se complete, enviando o prompt imediatamente, o comando abaixo

9 sort < file1 > file2 & inicia o sort como um job em background, permitindo que o usuário continue a trabalhar normalmente, enquanto a ordenação se processa. Isso caracteriza o Unix como um sistema operacional multitarefa.