As chamadas ao sistema (system cfllls) fornecem a interface entre um processo e o sistema operacional. Essas chamadas estão geralmente disponíveis como instruções em linguagem assembly c, cm geral, são listadas nos
manuais usados por programadores cm linguagem assembly/
Certos sistemas permitem que as chamadas ao sistema sejam feitas diretamente de um programa de lin- guagem de nível mais alto e, nesse caso, as chamadas normalmente lembram chamadas de sub-rotinas ou de
I Estruturas de Sistemas Operacionais • 39
funções predefinidas. Podem gerar uma chamada a uma rotina de execução especial que realiza a chamada ao sistema, ou a chamada ao sistema pode ser gerada dirctamente in-lhie.
Várias linguagens - como C, C + + e P e r l - f o r a m definidas para substituir a linguagem assembly na pro- gramação de sistemas. Essas linguagens permitem q u e as chamadas ao sistema sejam feitas dirctamente. Por exemplo, as chamadas ao sistema do UNIX podem ser feitas diretamente a partir de um programa cm C ou C + + . As chamadas ao sistema para as plataformas Microsoft Windows modernas fazem parte da API Win32, que está disponível para uso por todos os compiladores escritos para o Microsoft Windows.
Java não permite que as chamadas ao sistema sejam feitas diretamente, porque uma chamada ao sistema é específica a um sistema operacional e resulta em código específico daquela plataforma. No entanto, se deter- minada aplicação exigir recursos específicos do sistema, um programa em Java pode chamar um método es- crito em outra linguagem - geralmente C ou C + + - que, por sua vez> pode fazer a chamada ao sistema. Tais métodos são conhecidos como métodos "nativos".
/ Como um exemplo da forma em que as chamadas ao sistema são usadas, considere escrever um programa simples para ler dados de um arquivo e copiá-los para outro arquivo. A primeira entrada que o programa pre- cisará são os nomes dos dois arquivos: o arquivo de entrada e o arquivo de saída. Esses nomes podem ser es- pecificados de muitas maneiras, dependendo do projeto do sistema operacional. Uma abordagem é fazer o programa pedir ao usuário os nomes dos dois arquivos. Em um sistema interativo, essa abordagem exigirá uma sequência de chamadas ao sistema, primeiro para escrever uma mensagem solicitando os nomes na tela e depois para ler os caracteres que definem os dois arquivos. Em sistemas baseados em mouse e ícones, um menu de nomes de arquivos geralmente é exibido em uma janela. O usuário pode usar o mouse para sclecio- nar o nome de origem e uma janela pode ser aberta para que um nome de destino seja especificado./
Depois que os dois nomes de arquivos tiverem sido obtidos, o programa deve abrir o arquivo de entrada e criar o arquivo de saída. Cada uma dessas operações requer outra chamada ao sistema. Existem condições de erro possíveis para cada operação. Quando o programa tentar abrir o arquivo de entrada, poderá verificar que não existe um arquivo com aquele nome ou que o arquivo está protegido contra acesso. Nesses casos, o programa deverá imprimir uma mensagem na console (outra sequencia de chamadas ao sistema) e, em segui- da, fazer o término anormal (outra chamada ao sistema). Se o arquivo de entrada existir, devemos criar um novo arquivo de saída. Talvez já exista outro arquivo de saída com este nome. Essa situação pode fazer o pro- grama abortar (uma chamada ao sistema) ou podemos apagar o arquivo existente (outra chamada ao sistema) e criar um novo (outra chamada ao sistema). Outra opção, em um sistema interativo, é perguntar ao usuário (uma sequência de chamadas ao sistema para obter como saída a mensagem e ler a resposta do terminal) se o arquivo existente deve ser substituído ou se o programa deve ser abortado.
Agora que os dois arquivos estão prontos, entramos em um laço que lê dados do arquivo de entrada (uma chamada ao sistema) c os grava no arquivo de saída (outra chamada ao sistema). Cada operação de lei- tura e escrita deve retornar informações de status com relação às várias condições de erro possíveis. Na en- trada, o programa poderá verificar que o final do arquivo foi alcançado, ou que aconteceu uma falha de hardware no processo de leitura (como um erro de paridade). A operação de escrita poderá encontrar vá- rios erros, dependendo do dispositivo de saída (falta de espaço em disco, fim físico da fita, falta de papel na impressora e t c ) .
Finalmente, depois que o arquivo todo tiver sido copiado, o programa poderá fechar os dois arquivos (outra chamada ao sistema), gravar uma mensagem na console (mais chamadas ao sistema) e finalmente ter- minar normalmente (a chamada final ao sistema). Como podemos ver, os programas fazem uso pesado do sistema operacional.
Entretanto, muitos usuários nunca chegam a ver esse nível de detalhe. O sistema de suporte à execução (o conjunto de funções incorporado em bibliotecas incluídas com um compilador) para a maioria das lin- guagens de programação fornece uma interface muito mais simples. Por exemplo, a instrução cout em C+ + provavelmente é compilada em uma chamada para uma rotina de suporte de execução que emite as chamadas ao sistema necessárias, verifica se há erros e, finalmente, volta ao programa de usuário. Assim, a maior parte dos detalhes da interface do sistema operacional é oculta do programador pelo compilador e pelo pacote de suporte à execução.
40 Sistemas O p e r a c i o n a i s
As chamadas ao sistema ocorrem de diferentes maneiras, dependendo do computador que está sendo usado. Geralmente, mais informações são necessárias além de simplesmente identificar a chamada ao sistema desejada. O tipo e a quantidade exata de informações variam de acordo com o sistema operacional e a chama- da em questão. Por exemplo, para obter entrada, precisamos especificar o arquivo ou dispositivo a ser usado como origem, e o endereço e o tamanho do buffer de memória no qual a entrada deve ser lida. E claro, o dis- positivo ou arquivo c o tamanho podem estar implícitos na chamada.
Três métodos gerais são usados para passar parâmetros para o sistema operacional. A abordagem mais simples é passar os parâmetros em registradores. Em alguns casos, no entanto, pode haver mais parâmetros do que registradores. Nesses casos, os parâmetros em geral são armazenados em um bloco ou tabela na me-
mória, e 0 endereço do bloco é passado como um parâmetro em um registrador (Figura 3.1). Os parâmetros também podem ser colocados, ou inseridos, na pilha pelo programa e lidos e retirados da pilha pelo sistema operacional. Alguns sistemas operacionais preferem os métodos de bloco ou pilha, porque essas abordagens não limitam o número ou tamanho dos parâmetros sendo passados.
As chamadas ao sistema podem ser agrupadas basicamente em cinco categorias principais: controle de processos, manipulação de arquivos, manipulação de dispositivos, manutenção de informações e comunica- ções. Nas Seções 3.3.1 a 3.3.5, discutimos rapidamente os tipos de chamadas ao sistema que podem ser for- necidas por um sistema operacional. A maioria dessas chamadas ao sistema suportam, ou são suportadas por, conceitos e funções discutidos em outros capítulos deste livro. A Figura 3.2 resume os tipos de chamadas ao sistema normalmente fornecidas por um sistema operacional.
X: parâmetros paia chamada carregar endereço X chamada ao sistema 1: registrador programa de usuâno w U M i x código para chamada ao sislema 13 sisterna oporaoonal
Figura 3.1 Passagem de parâmetros como uma tabela.
/3.3.1 Controle de processo
Um programa em execução precisa ser capaz de parar sua execução de forma normal (end) ou anormal (abort). Se uma chamada ao sistema for feita para terminar de forma anormal o programa cm execução no momento, ou se o programa tiver um problema e causar um erro {hap)t às vezes ocorre um d u m p de memória
c uma mensagem de erro é gerada. O dump é gravado em disco e pode ser examinado por um depurador para determinar a causa do problema. Em circunstâncias normais ou anormais, o sistema operacional deve trans- ferir o controle para o interpretador de comandos. O interpretador de comandos então lê o p r ó x i m o coman- do. Em um sistema interativo, o interpretador de comandos simplesmente continua com o comando seguin- te; parte-se do pressuposto de que o usuário emitirá um comando apropriado para reagir a qualquer e r r o / E m um sistema em batch, o interpretador de comandos geralmente encerra todo o job e continua com o job se- guinte. Alguns sistemas permitem que cartões de controle indiquem ações especiais de recuperação em casos de erro. Sc um programa descobrir um erro na sua entrada e desejar fazer um término anormal, também po- derá definir um nível de erro. Erros mais graves podem ser indicados por um parâmetro de erro de nível mais alto. E possível então combinar o término normal c anormal definindo um término normal c o m o erro de ní- vel 0 . 0 interpretador de comandos ou um programa posterior pode usar esse nível de erro para determinar a próxima ação automaticamente.
fcstruturas de Sistemas Operacionais • 41 • Controle de processos
o end, abort ° load, execute
o creatc process, terminate process
° get process attributes, set process attributcs ° wait for time
o wait event {esperar evento), signal event (sinalizar evento) o allocate and free memory
• Gerência de arquivos ° create file, delete file ° open, dose
o rcad (ler), write (escrever), reposition (reposicionar) o get file attributcs, set file attributes
• Gerência de dispositivos ° request device, release device
o read, write, reposition
° get device attributcs, set device attributcs ° logically attach or detach devices
• Manutenção de informações
0 get time or date, set time or date
° get system data, set system data
o get process, file, or device attributes
° set process, file, or device attributes • Comunicações
° create, delete communication connection
o send, receive messages
° transfer status information ° attach or detach remote devices
Figura 3.2 Tipos de chamadas ao sistema.
Um processo ou job que está executando um programa pode querer carregar o u t r o programa, por meio de chamadas 1 oad e execute. Esse recurso permite ao interpretador de comandos executar um programa con- forme orientação, por exemplo, de um comando de usuário, de um clique no mouse ou de um comando batch. Uma questão interessante é a quem devolver o controle quando o programa carregado terminar sua execução. Essa questão está relacionada com o problema de o programa existente ser perdido, salvo ou ter permissão para continuar a execução de forma concorrente com o novo programa,
Se o controle voltar ao programa existente quando o novo programa terminar, devemos salvar a imagem na memória do programa existente; assim, criamos de fato um mecanismo para um programa chamar o u t r o programa. Se ambos continuarem concorrentemente, teremos criado um novo job ou processo para ser nuil- tiprogramado. Muitas vezes, existe uma chamada ao sistema especificamente para este objetivo (create pro- cess ou submit job).
Se criarmos um novo job ou processo, ou mesmo uma série de jobs ou processos, devemos ser capazes de controlar sua execução. Esse controle exige a capacidade de determinar e redefinir os atributos de um job ou processo, incluindo a prioridade do job, seu tempo de execução máximo permitido e assim por diante (get
42 • Sistemas Operacionais