Sistemas operacionais

Devido aos anéis de privilégio, acesso aos recursos de hardware e gerenciamento de processos podem ser feitas apenas no nível 0 de execução (modo Kernel), porém as aplicações do usuário funcionam no nível 3, assim não podem diretamente acessar esses recursos. Para isso, eles devem utilizar de chamadas de sistema, que funcionam como uma interface entre o programa do usuário e o SO. Essas chamadas possuem funções com o mesmo nome em C e portanto podem ser chamadas nos programas para serem executadas. No GNU/Linus a biblioteca C que é utilizada para implementar essas chamadas de sistema é a GLIBC. Assim, quando um processo faz a chamada de sistema, o SO entra em ação desviando a execução do processador através de uma interrupção, mudando a execução para o local apropiado no vetor de interrupções (normalmente 0x80), que irá ajustar o endereço de busca para a rotina apropiada dependendo da chamada feita. É imporrante ressaltar que quando uma interrupção é feita, o processador salva os valores de flag atual é o PC (EIP + CS), copiando os valores para a pilha de processos, para que possa ser restaurado depois após a interrupção ser tratada. Após executada a chamada de sistema, o contexto do programa que fez a chamada é restaurado usando os valores de flags e PC salvos na pilha, com o retorno da chamada de sistema. O vetor de interrupção e as rotinas de tratamento das mesmas são salvas na memória durante o processo de boot do próprio SO.

2) O redirecionamento de entrada e saída de dados podem ser feitas no shell utilizando o sinal de ">" (para saída) ou "<" (para entrada) ou o pipe "|" para o caso de comunicação entre processos. Sabendo que o vetor de arquivos abertos possue as 3 primeiras entradas relacionadas a leitura, escrita e mensagem de erro, é possivel redireciona-las. Uma possível solução é usando a chamada dup2, para que o SO copie as informações de um vetor de arquivos aberto para outro, assim, ele pode redirecionar o STDIN, STDOUT OU STDERR de um processo para um arquivo ou até para um pipe. No caso de $p1 > arq1, o shell cria o processo, abre o arquivo, usa o dup2 para redirecionar o STDOUT para o arquivo como "dup2(fd,STDOUT_FILENO)", fecha o arquivos e executa o comando exec no processo filho p1.

Processos zumbis são processos que já terminaram sua execução (usando a chamada exit()) mas ainda estão na tabela de processos pois seu processo pai precisa ler o estado de saída do filho. Por ja ter sido encerrado, o processo zombie não pode ser morto com sinais do tipo SIGKILL, por exemplo. Uma solução seria enviar ao o SIGCHLD para o pai, para que ele veja que o filho terminou e encerre com ele. Outra solução é enviar um sinal matando o processo pai (SIGKILL), então o processo zumbi se tornaria orfão e seria adotado pelo processo init (PID 1), que executaria um wait() que terminaria com o zumbi.

A combinação de teclas ctrl+c envia um sinal SIGINT ao processo, pedidndo para que ele seja interrompido. Esse sinal, caso não seja tratado pelo programa, causará a ação padrão que é justamente de interromper o processo em foreground. Caso seja tratado, ele executará a rotina de tratamento criado. Para enviar esse sinal, o shell possivelmente executa a chamada "kill", passando como parâmetros o número do sinal a ser enviando (neste caso o SIGINT) e o PID do processo que