Curso sistemas operacionais 2011 prof. Jorge Kinoshita. Aulas segunda, terça: 16:00-17:40H Maio 9/5 - aula 1 10/5 - aula 2 16/5 - aula 3 17/5 - aula 4 23/5 - aula 5 T1 24/5 - aula 6 T1 30/5 - aula 7 31/5 - aula 8 Junho 6/6 - aula 9 7/6 - aula 10 13/6 - aula 11 T2 14/6 - aula 12 T2 20/6 - Prova1 21/6 - aula 13 27/6 - aula 14 28/6 - aula 15 Julho 4/7 - aula 16 T3 5/7 - aula 17 T3 11/7 - aula 18 12/7 - aula 19 18/7 - aula 20 19/7 - aula 21 25/7 - aula 22 T4 26/7 - aula 23 T4 Agosto 1/8 - aula 24 2/8 - aula 25 8/8 - aula 26 T5 9/8 - aula 27 T5 15/8 - Prova 2 Programação aula a aula. 1 - 1.1 O que é um sistema operacional, 1.2 História dos sistemas operacionais 2 - Visao do hardware 1.3 conceitos de sistema operacional 3 - 1.3 conceitos de sistema operacional; 1.4 chamadas de sistema 4 - 1.4 chamadas de sistema 1.5 estrutra do sistema operacional. 5 => apresentação dos projetos (fase 1) 6 - apresentação dos projetos (fase 1) 7 - 2.1 introdução aos processos 8 - 2.2 comunicação interprocesso até semaforos 9 - de semaforos a 2.3 problemas clássicos de CIP 10 - 2.4 agendamento de processo + problema reader/writer. 11 => Projetos 2.5 visão geral de processos em minix (fase 2) 12 => Projetos 2.5 visão geral de processos em minix (fase 2) prova 1 13 - 3.1 Hardware Entrada e Saida 3.2 Software Entrada e Saida 14 - 3.2 Software Entrada e Saida 15 - 3.3 impasses 16 => Projetos 3.4 visão geral de E/S no minix (fase 3) 17 => Projetos 3.4 visão geral de E/S no minix (fase 3) 18 - 4.1 gerenciamento básico de memória 4.2 troca (swap) 19 - 4.3 memória virtual, 4.4 algoritmos de substituição de página. 20 - 4.4, 4.5 questões para sistemas de paginação. 21 - 4.6 segmentação 22 => Projetos 4.7 visão geral do gerenciamento de memória do minix (fase 4) 23 => Projetos 4.7 visão geral do gerenciamento de memória do minix (fase 4) 24 - 5.1 arquivos 5.2 diretórios 25 - 5.3 implementação do sistema de arquivos 26 => Projetos 5.6 visão geral do sistema de arquivos minix (fase 5) 27 => Projetos 5.6 visão geral do sistema de arquivos minix (fase 5) prova 2 Livro texto: Sistemas Operacionais - Projeto e Implementação ; Tanenbaum A.S. Woodhull A.S.; Bookman terceira edição Obs: Este livro contém o Minix que serviu de base para a criação do Linux, mas a versão atual é a 3.0. Bons Livros de apoio: - Sistemas Operacionais Modernos 3a. edição; Tanenbaum A.S.; Prentice Hall Obs: Este livro é muito parecido com "Projeto e Implementação" mas não contém o Minix. Por outro lado é mais didático e contém mais informação que o outro. - Sistemas Operacionais com Java; Silberschatz, Galvin, Gane; Editora Campus Obs: Este livro apresenta os conceitos de forma mais clara que os livros do Tanenbaum, porém não usa um sistema operacional próximo da realidade, usa apenas pequenos exemplos em java; e provavelmente o aluno perde a noção do sistema operacional como um todo. avaliação: 3 P1 + 4 P2 + 0.5 E + 2.5 P E = exercícios feitos em aula / vale mais para contar presença. Projetos Fase 1: - Use o seu computador por uma hora, vendo um filme no youtube ou ouvindo uma musica no grooveshark. Veja: - quais foram os processos que rodaram nessa uma hora? - quais foram os arquivos que foram alterados nesse tempo? Quais arquivos foram abertos nesse tempo? Quais arquivos foram fechados nesse tempo? - quais foram as system calls chamadas nesse tempo? Quanto tempo durou cada chamada? Dividindo em 9 equipes; temos que observar: (Youtube.com, Grooveshark.com, Videolectures.net ): esses sites em um browser; ex: firefox. (Processos, Arquivos, System calls) : quais processos rodaram ao assistirem um filme no YouTube - vejam a diferenca dos processos com e sem o youtube (ou outro como especificado) e analisem a diferenca. (Opensolaris, Linux, Windows/mac) : o grupo deve rodar no sistema operacional correspondente. 1. YPO - veja quais processos sao ativados ao ver o youtube no opensolaris. 4. YPL 7. YPW 8. GAO 5. GAL 2. GAW 6. VSO - veja quais system calls foram chamadas enquanto assistia o VideoLectures no opensolaris. 9. VSL 3. VSW 10. Quanto tempo a CPU ficou rodando no kernel e quando tempo ficou rodando no modo usuário? em modo kernel? Faca para o caso Youtube no Opensolaris. Fase 2. 1- Implementar semáforos no minix. Será necessário estudar o kernel do minix, observando como manter o processo em estado bloqueado ao fazer uma operação de down. Implemente as seguintes system calls: int inicia(int valor); exemplo: S = inicia(3); # inica um semáforo com 3 e retorna o número do semáforo em S. O número zero é reservado; se S == 0 então deu erro em inicia. int down(int S); faz a operação de down no semáforo S; se der problema retorna -1. int up(int S); faz a operação de up no semáforo S int status(int S, int *valor, int *procbloqueados); coloca em valor, o valor do semáforo S e em procbloqueados, o número de processos bloqueados no semáforo. Essas system calls devem ser implementadas pelo processo PM (antigo MM). Dica: dado que existe apenas um processo PM, é fácil pensar que up e down serão mutualmente exclusivos pois o PM estará tratando a mensagem up ou a mensagem down não podendo tratar as duas ao mesmo tempo. Isto é: não será necessário desabilitar as interrupções para se implementar o up e o down. Como o processo usuário vai enviar uma mensagem ao PM então o estado de bloqueado pode ser conseguido, simplesmente se o PM não responder ao processo enquanto o semáforo não subir. Use os semáforos no programa produtor-reprodutor. 2 - Como o minix trata a divisão por zero? Explique o código. É de se esperar que o minix envie um signal para o processo que fez a divisão por zero. Se o minix não fizer isso, implemente. Faça um programa executável que faz a divisão por zero no minix rodando no bochs (http://pdos.csail.mit.edu/6.828/2006/tools.html). Rode o programa e capture o signal imprimindo na tela uma mensagem toda vez que for feita a divisão por zero. Faça um print screen do bochs logo ao entrar na rotina que faz o tratamento da divisão por zero (observando qual é o endereco da rotina a ser executada dada pelo vetor de interrupcao). Realmente eh possivel que um processo A envie um signal a um outro processo B (através do kill), fazendo com que B ache que houve uma divisão por zero dentro do minix? E no linux? O que acontece desde a interrupcao gerada pela divisao por zero ateh a chamada da rotina? Como o SO fica sabendo qual é o signal handler que deve ser chamado? 3 - Use o bochs em modo debug (deve ser compilado para isso de acordo com o lab1 do MIT http://pdos.csail.mit.edu/6.828/2006/tools.html) para estudar o minix. Veja: - Manuais da intel (na internet) como por exemplo: Pentium® Processor Family, Developer's Manual Volume 3: Architecture and Programming Manual. Após a inicialização do minix para o minix dentro do bochs e coloque um breakpoint na interrupção de teclado. Faça um print screen do bochs mostrando a primeira instrução logo ao entrar no tratamento de interrupção do teclado. Relacione o valor do endereço que você vê, com o declarado na IDT, GDT e LDT. O minix guardará os registradores. Como o hardware e o código do minix fazem isso? Em particular, como é armazendo o Program Counter (ou Instruction Pointer, EIP)? Onde o estado do processo é armazenado? Relacione isso com o código do minix e explique. Ao sair da rotina de interrupção, um outro processo foi escalonado para rodar? Qual processo? Apresente um print screen dos registradores antes de sair da interrupção. Como ao sair da interrupção, o novo processo passa a rodar? Com que Program Counter (EIP)? Explique. Explique a funcao save chamada logo na entrada da rotina de interrupcao (rastreie usando o bochs). Como é guardado o endereco de retorno de save? Como a funcao "save" retorna? Rastreie usando o bochs. 4 - livro 2.44. Adicione código no núcleo do minix3 para monitorar o número de mensagens enviadas do processo (ou tarefa) i para o processo (ou tarefa) j. Imprima essa matriz quando a tacla F4 for pressionada. (Sugestao: observe que o minix já tem tratamentos para visualizar dados do kernel teclando F...). 5 - livro 2.50 pg 215 - Modifique o minix3 para reunir estatísticas sobre as mensagens enviadas por quem e para quem, e escreva um programa para reunir e imprimir estatísticas de uma maneira útil. 6 - Veja o tutorial em http://en.skelix.org/skelixos/tutorial04.php Siga o tutorial; para facilitar experimente no vmware como o site sugere. Depois rode no bochs passo a passo (http://pdos.csail.mit.edu/6.828/2006/tools.html). Estude manuais da intel (Pentium® Processor Family, Developer's Manual Volume 3: Architecture and Programming Manual).Coloque um breakpoint na entrada da rotina de interrupcao (divisao por zero) e veja como o codigo é executado. Relacione com as estruturas do processador intel (ldt, gdt). Relacione o codigo desse tutorial com o codigo do minix. Retire print-scree ao rodar o tutorial passo a passo no bochs. 7 - livro 2.45 - Modifique o escalonador do Minix3 para monitorar quanto tempo da CPU cada processo de usuário recebeu recentemente. Quando nenhuma tarefa ou servidor quiser executar, escolha o processo de usuário que recebeu a menor fatia de CPU. 8 - Rode de forma emulada uma placa arm atraves do qemu-system-arm (provavelmente vai ser necessario vc. compilar o qemu dentro do linux). O objetivo é estudar o booloader: o software encarregado de fazer a carga do sistema operacional. Explique o u-boot. Experimente fazer a placa (qemu-system-arm) rodar o u-boot. Faca pequenas alteracoes no codigo do u-boot (exemplo: alterando mensagens). 9 - Estude como funciona uma interrupcao de software no arm, em particular, o que faz SWI. Apenas para testes, crie uma SWI que soma dois numeros no gnuarm. Repasse a SWI e codigo de teste para uma placa ARM emulada através do qemu-system-arm. 10 - Estude o UML - User Mode Linux. Estude http://web2.clarkson.edu/class/cs644/kernel/setup/uml/gdb_uml.html e repita os passos. Gere um relatório sobre os problemas encontrados. Procure entender como funciona a tabela de processos do linux usando o debugger; como os registradores sao salvos e recuperados dessa tabela. Fase 3 Para a fase 3, temos que a maioria dos grupos (1-8) pode achar o seguinte trabalho interessante: A experiência 8 do lab. de microprocessadores: http://www.pcs.usp.br/~jkinoshi/2005/Exp8_revisada_13_08_04.doc tem como objetivo apresentar o que é um driver em linux. Em linux, um driver é um conjunto de rotinas que implentam funções padronizadas como "read" e "write". No caso do minix, um driver é um processo que responde a mensagens padronizadas. Crie um driver muito simples em minix que apenas imprime mensagens quando recebe mensagens padronizadas de outro processo. O driver pode ser associado a /dev/teste. Declare /dev/teste associando um major e minor number e o código do processo associado ao driver. Use "service" para rodar o driver. Gere um relatório sobre isso. As mensagens que o driver deve responder são as mesmas que o driver da impressora respondem, ou seja: * m_type TTY_LINE PROC_NR COUNT ADDRESS * |-------------+---------+---------+---------+---------| * | DEV_OPEN | | | | | * |-------------+---------+---------+---------+---------| * | DEV_CLOSE | | proc nr | | | * ------------------------------------------------------- * | HARD_INT | | | | | * |-------------+---------+---------+---------+---------| * | SYS_EVENT | | | | | * |-------------+---------+---------+---------+---------| * | DEV_WRITE |minor dev| proc nr | count | buf ptr | * |-------------+---------+---------+---------+---------| * | CANCEL |minor dev| proc nr | | | * ------------------------------------------------------- Envie mensagens a /dev/teste como em: echo "lixo" > /dev/teste e veja a mensagem que é impressa pelo seu driver. Faça o driver imprimir a string que recebeu ("lixo"). Em 2008, tivemos a seguinte resposta para o problema acima: http://www.pcs.usp.br/~jkinoshi/2008/projs/r3-pedrodaquino-Relatorio3.pdf. Vamos chamar esse driver de driver-padrão. Aqui vão as tarefas: 1 - gerar uma onda quadrada pela porta paralela. Criar /dev/pp e associar um driver, baseado em driver padrão, que: echo "AB" > /dev/pp faz o caracter hexa "AB" ser colocado nos pinos da paralela. Já fizemos trabalhos com essa idéia. Use relatório antigos apenas como base apenas, rode no bochs (os trabalhos antigos rodavam no vmware). 2 - Cada driver no minix deveria ser responsável apenas por uma área de I/O e se ele tentasse usar outra área, deveria ser barrado. Fizemos algumas experiências no passado, usando minix3 e constatamos que isso não funciona. Faça novos testes e proponha uma forma de corrigir o problema. 3 - Usando o qemu-system-arm podemos simular um debian rodando em um processador ARM (http://www.aurel32.net/info/debian_arm_qemu.php). Estude como a placa emulada faz a interrupcao de tempo. Usando gdb + qemu-system-arm coloque um breakpoint na rotina de interrupcao de tempo e veja o código em ARM. Veja: http://files.meetup.com/1590495/debugging-with-qemu.pdf. Altere o código de qemu-system-arm de forma a gerar a interrupcao de tempo na metade da frequencia que se gera normalmente. Você observa diferenca no comportamento do debian emulado? 4 - Levante as mensagens trocadas entre o FS e o driver do disco, desde a inicializacao, durante a leitura de um determiado arquivo. (Escolha um arquivo pequeno e bem simples). Você pode se basear no último trabalho do grupo do Pedro, Wilson, Hélio ( http://www.pcs.usp.br/~jkinoshi/2008/projs/r5-pedrodaquino.zip) para levantar as mensagens trocadas entre FS e driver. Como o FS mapeia um arquivo no disco? 5 - simule o minix dentro do bochs. Coloque um breakpoint quando ocorrer uma interrupcao sinalizando que houve o término de uma leitura de disco. Imprima a tela do bochs mostrando que voce conseguiu interceptar essa interrupcao. Após isso, como essa interrupcao é sinalizada para o driver de disco? É possível que essa interrupção desbloqueie o driver? 6 - O minix3 roda os drivers em modo usuário. Assim, para que um driver execute um I/O, ele faz essa requisicao à tarefa de sistema. Altere o minix de forma a que ao se teclar F5 (por exemplo), apareća na tela uma informaćao contendo os ultimos acessos ao I/O, onde em cada linha temos: (numero da porta de I/O, escrita/leitura, valor). Já existem diversos trabalhos antigos que fazem com que uma tecla F5 imprima algo na tela. 7 - O minix3 apresenta o reincarnation server. Um processo no microkernel que constantemente verifica como estão os drivers e os reinicializa se considerar que eles possuem algum erro. Altere o driver padrão em http://www.pcs.usp.br/~jkinoshi/2008/projs/r3-pedrodaquino-Relatorio3.pdf de forma a que ele responda ao RS. Coloque o RS de forma a monitorar o driver padrão. Introduza um erro no driver padrao de forma que ele deixe de responder depois de um certo tempo. Verifique se o RS reinicializa o driver. 8 - Criar o /dev/pp semelhante ao exercio da equipe 1 de forma que ele imprime uma mensagem toda vez que houver um sinal de "fim de papel" no pino correspondente da porta paralela. Crie um mecanismo de gerar essa interrupção pela máquina virtual onde roda o minix. 9 - instale o linux na placa Versatile emulada através de qemu-system-arm. Veja o código fonte do linux que roda na placa e onde se encontra a rotina de interrupcao que é ativada pelo teclado. Usando o gdb + qemu-system-arm, coloque um breakpoint na entrada dessa rotina e apresente o printscreen da tela. Estude o código do qemu e como o qemu-system-arm é gerado. Estude quais são os dispositivos de entrada que estão sendo emulados no qemu; em particular, se existe algum botão na placa. Altere o código do qemu-sytem-arm de forma que ao se teclar Control-x seja simulado o aperto de um botão da placa; ou seja, o qemu-system-arm deve interpretar o control-x como o aperto de um botão. 10 - Vamos imaginar que as interrupcoes do minix estivessem desabilitadas enquanto chega um tique do relógio. Poderia acontecer do minix perder algum tique de relógio? Será que seria possível se ter um mecanismo que detecte perdas em tiques de relógio olhando o relógio externo (pois mesmo com o computador desligado, seu relógio da bios continua funcionando)? Fase 4 1. Quando o minix faz exec ele deve desalocar a memoria da imagem do processo pai e alocar memoria (dados, código, pilha) referente ao codigo executavel, como ele faz isso? Localize isso no código do minix; mas basicamente ele deve ler o arquivo executável e retirar essa informacao. Localize no código do minix onde isso ocorre. Com base nesse código crie um programa no minix que tem como entrada um arquivo executável do minix (vc. pode criar um arquivo executável qualquer) e mostre o quanto o programa precisa de área de memória (dados, codigo/texto, pilha). 2. como o minix protege a área do kernel? Se algum processo tentar invadir a área do kernel ele é realmente barrado? Crie um processo que tenta invadir uma área a que nao tem acesso. Uma forma de fazer isso é criar um ponteiro que varre a memória, lendo e escrevendo dados. Ao fazer isso no minix que erro você observa? Localize o tratamento desse erro no código fonte do minix. Apresente uma mensagem diferente quando ocorrer esse erro. Qual a participacao do pentium nessa excessão? Como o pentium é informado da área de memória do processo? Localize isso no código do minix. 3. O minix nao trabalha com memoria virtual. Quando um programa é gerado e colocado a executar, ele não sabe em que posicao de memoria ele vai entrar. Descubra no código fonte do minix, como ele determina o entrypoint (o endereco da primeira instrucao) do código executável. Crie um programa executável baseado no kernel do minix que apresenta o entrypoint de um arquivo executável qualquer ao usuário. Como o minix trata da realocacao do codigo? Que coisas do pentium ele usa para fazer essa realocacao? 4. No linux crie um processo que escreva numeros em posicoes consecutivas na memoria. Uma forma de fazer isso é usar um ponteiro para a memória e incrementá-lo (verifique se tem diversas formas de compilar - verificando o acesso dentro e fora de uma array - se existir, teste de várias formas). Qual o maximo numero que ele consegue escrever antes que retorne um erro? Como esse erro é gerado? Se vc. rodar o linux numa maquina virtual, esse numero varia dependendo do tamanho da tamanho da sua maquina virtual? Recompile o kernel do linux, alterando essa mensagem de erro. Rode o kernel em User Mode Linux (com uma máquina Debian, como explicado em http://web2.clarkson.edu/class/cs644/kernel/setup/uml/gdb_uml.html e coloque um breakpoint quando a mensagem for impressa. Retire printscreens do que ocorre e coloque no relatório. 5. Crie uma funcao que apenas soma dois numeros quando chamada e coloque essa funcao numa Dynamically Linked "Shared Object" Libraries: (.so). Crie dois processos que utilizam essa mesma funcao. Descubra uma ferramenta no linux que permite visualizar quais sao as DLLs carregadas no linux. Ative os dois processos e observe se a DLL está carregada. Voce pode rodar cada programa em uma shell diferente. Descubra em que parte da memória foi carregada a DLL. Esses enderecos de memoria onde a DLL foi carregada sao os mesmos para os dois processos que compartilham a DLL? Agora altere a funcao para que ela tenha um estado interno; ou seja, ao inves de somar dois numeros; faca com que a funcao apenas incremente alguma variavel interna a ela. Rode os dois processos fazendo com que um numero seja incrementado a cada "enter" do usuário. Isso funciona? Ë possivel que a DLL guarde valores proprios? 6. No linux é possivel mapear um arquivo na memoria de forma a acessar os bytes do arquivo como se acessa bytes na memoria (ver mmap). Copie um arquivo em outro usando o arquivo mapeado em memoria. Teste com dois casos: 1. o arquivo destino já existe e é mapeado em memória. Nesse caso, se o arquivo origem for maior que o arquivo destino, dá erro? 2. o arquivo destino nao existe, nesse caso, qual é o tamanho do arquivo destino? Compare com o tamanho do arquivo origem. Faca uma experiencia para verificar o tamanho maximo desse arquivo destino (nesse caso nao precisa se importar com o arquivo origem). Experimente criar dados persistentes na memoria mapeando estruturas de dados em arquivos. Ou ainda, experimente compartilhar certos dados criando um arquivo mapeado em memoria compartilhado entre dois processos. 7. usando o dtrace, observar o tamanho maximo de memoria que um processo no opensolaris pode usar; isto é, escreva um programa que continuamente vai pedindo memória pelo malloc. Isso varia dependendo do tamanho da memoria RAM da maquina virtual? Eh razoavel que esse tamanho varie dependendo do tamanho da memoria RAM da maquina virtual? 8. crie uma area de memoria compartilhada por dois processos diferentes no linux e transfira dados usando essa área de memória. O endereco virtual onde estah essa area compartilhada eh o mesmo para os dois processos? Estude como voce pode verificar isso no linux. Usando ferramentas do linux, visualize essa área de memória compartilhada. Faca testes para verificar qual o maximo de área de memória possível compartilhada entre ambos os processos. 9) Mostrar através de um log como a memória foi alocada e desalocada a processos. Toda vez que um processo executar um fork, exec, exit afeta a alocação de memória e isso é registrado no log (em um deterinado arquivo). No log contém informações como: fork - processo /usr/bin/init + segmento 0x30 - 5 clicks. exec - processo /usr/bin/firefox + segmento 0x40 - 7 clicks. exit - processo /usr/bin/firefox - segmento 0x40 - 7 clicks. onde: + : significa que memória está sendo alocada ao processo da posição 0x00230 até 0x00340 - : significa que memória está sendo desalocada e devolvida para a área livre. dica: http://www.pcs.usp.br/~jkinoshi/2007/r4-1.pdf Adicione ao log a informação de qual tipo de segmento (código ou dados) está sendo alocado ou desalocado. A resposta dada pela turma (com uma versao antiga do minix; e portanto atualize para o minix novo) está em: resp: http://www.pcs.usp.br/~jkinoshi/2008/projs/r4_brunogrisi.zip Faça com que a informação sobre o tipo de segmento (código/dado) esteja na mesma linha onde está "fork", "exec", etc. Faça um programa que fique em loop executando o fork e veja o que ocorre no log. O processo deverá fazer algo como: while (1) { fork(); } Esse tipo de processo vai travar o sistema porque vai consumir toda a memória; ou vai acabar com todas as entradas na tabela de processos. O que acontece no minix? Crie uma forma de monitorar o número de processos que rodam na máquina. Tire printscreens da tela enquanto o processo que gera processos roda. 10. Estouro de pilha (stack overflow): monitorar quando ocorre estouro de pilha. Você pode criar uma rotina recursiva que chama ela mesma indefinidamente no minix - sendo que ela deve passar como parametro i+1 e imprimir esse valor; de forma que podemos identificar o numero maximo de chamadas recursivas que foi possivel antes de se ter o estouro de pilha. Rode o minix no bochs e intercepte a excessao de estouro de pilha. Coloque o printscreen no relatório. Altere a área de memória RAM da máquina virtual onde roda o minix; verifique se o número máximo de chamadas recursivas varia. Localize no código do minix, qual o tamanho máximo que uma pilha de processo pode ter. Fase 5 1. usando o comando dd no minix + a informacao sobre o superbloco do minix3, apresente o mapa de bits de i-nodes. Quais sao os i-nodes livres? Crie um arquivo. Verifique o numero do i-node do arquivo que acabou de ser criado. Verifique se isso de fato ocorre; para isso crie um programa que crie repetitivamente arquivos até retornar uma mensagem de erro. Localize no código do minix onde se encontra essa mensagem de erro. Verifique novamente usando o dd como estão os i-nodes livres. 2. No minix, localize o i-node do arquivo /etc/passwd usando o comando dd. Para isso, primeiro voce precisa de localizar o i-node do diretório /etc e depois dentro desse diretório, você deve localizar a entrada passwd relacionada com o seu inode. Usando o comando dd no minix, apresente o setor que contem o i-node e todos os outros setores (zonas) apontados pelo i-node. Ou seja, apresente todos os setores que compoem o /etc/passwd, desde o i-node, blocos diretos e indiretos. 3 - Como funciona a system call read? (item 5.6.10 do livro do minix3). Crie a system call leia (uma cópia de read) que ao fazer a leitura, imprime os blocos do disco que foram lidos. Faça um programa em C que use "leia" e imprima quais blocos foram lidos. Informe se o bloco está sendo lido do cache ou do disco. Resposta: http://www.pcs.usp.br/~jkinoshi/2007/r5-1.pdf http://www.pcs.usp.br/~jkinoshi/2007/r5-1.ppt Altere a resposta fornecida em 2007, para que além de especificar os blocos lidos (do disco ou do cache), também forneça as mensagens enviadas ou recebidas do disk driver. Para isso, altere o disk driver de forma a imprimir as mensagens que recebe quando a função leia estiver sendo usada ou varra todo o código de FS para que ele imprima as mensagens que estão sendo trocadas (o que você achar mais fácil). Combine com a equipe anterior (2) para usarem a mesma imagem do minix (apenas usem a imagem provida pelo vmware, por exemplo, no site do minix3) de forma a se comparar os resultados obtidos na leitura de /etc/passwd. 4. Crie um arquivo (com somente letras "a") pequeno de forma a não precisar a zona de indirecao simples. Veja o seu i-node com o comando dd. Crie um arquivo (com somente letras "a") medio de forma a precisar da zona de indirecao simples. Veja o seu i-node com o comando dd. Para onde aponta a zona de indirecao simples? Veja os bytes dessa zona e para onde eles apontam. Faz sentido? Localize no código do minix onde ele passa a utilizar o ponteiro de indireção simples. Faca com que o minix gere uma mensagem toda vez que for usar um ponteiro de indirecao simples. Teste novamente o seu programa criando um arquivo com varias letras e veja se a mensagem aparece. Retire um print screen da tela e anexe no relatorio. 5. No minix, altere um parametro do i-node de um arquivo usando o comando dd (exemplo: altere os bits rwx). Para que a alteracao desses bits seja realmente reconhecida pelo mninix serah necessario rebootah-lo. Estude o codigo fonte da system call chmod e localize no codigo como ela altera os bits de permissao rwx com o que voce fez. 6. Estude o codigo fonte do comando passwd do minix. Quais system calls ele chama? Em particular veja como suid bit do arquivo é usado: o comando passwd é executado com o poder do owner e não com o poder do user. Veja como é a permissao do executavel passwd (usando ls -al). Apresente o i-node do arquivo passwd e as suas permissoes usando o comando dd. 7 - Como funciona a system call read? (item 5.6.10 do livro do minix3). Crie a system call leia (uma cópia de read) que ao fazer a leitura, imprime os blocos do disco que foram lidos. Faça um programa em C que use "leia" e imprima quais blocos foram lidos. Informe se o bloco está sendo lido do cache ou do disco. Resposta: http://www.pcs.usp.br/~jkinoshi/2007/r5-1.pdf http://www.pcs.usp.br/~jkinoshi/2007/r5-1.ppt Altere a resposta fornecida em 2007, para que além de especificar os blocos lidos (do disco ou do cache), também forneça as mensagens enviadas ou recebidas do disk driver. Escreva um programa que crie dois arquivos simultaneamente. Para isso, primeiro ele faz um fork: o processo pai escreve uma longa sequencia de 'a's e o processo filho uma longa sequencia de 'b's de forma que os setores de ambos os arquivos fiquem entrelacados. Agora faça a leitura de dois arquivos simultaneamente por dois processos diferentes usando a system call leia que voce fez para esse exerciceo e observe se o minix intercala a leitura de blocos de um arquivo com blocos do outro arquivo. Se isso não estiver acontecendo, estude o motivo pelo qual não está ocorrendo essa intercalacao. Em outras palavras, é possível que o FS trate a system call read para dois processos simultaneamente? 8 - De fato não é necessário ter o poder de root para se executar alguns comandos. O comando passwd que altera a senha roda com o poder de root que é o owner do arquivo. Troque a permissão do passwd (retire o suid bit) e veja que você nào consegue mais alterar a sua senha de usuário normal. Experimente levantar o suid bit do comando "mount" e veja se agora é possível montar um filesystem mesmo sendo um usuário normal. Faça essa experiência e gere um relatório sobre isso. Observe onde o minix onde o suid bit é tratado e faca com que ele imprima uma mensagem contendo o nome do arquivo executável que fez uso do suid. Rode o minix e veja principalmente a inicializacao. Rode o passwd e mount e veja se a mensagem é impressa. Retire um print screen da sua experiencia para colocar no relatorio. 9 - Em 2007 propomos o seguinte problema: Implemente o comando i-nodes que apresenta para cada i-node informações se ele está livre ou a qual arquivo pertence. Exemplo: i-nodes ... 5: i-node livre 6: i-node diretório /usr 7: i-node arquivo /usr/bin/chdir ... Dica: Veja onde o i-node é utilizado e tente aproveitar as rotinas que lidam com o i-node. Na resposta em http://www.pcs.usp.br/~jkinoshi/2007/r5-2.doc, os alunos apenas indicaram se um determinado i-node estava em uso ou não. Um exercicio bem mais simples é apenas entrar no diretório raiz e imprimir para cada entrada nesse diretório, qual é o número do i-node que está sendo utilizado. Exemplo: /usr i-node = 4; /etc inode = 5; etc. Implemente essa versao simplificada do comando i-nodes. Para acessar o disco, existem duas formas: 1. através do comando dd como está sendo pedido para muitos grupos ou 2. através de alguma system call que voce tenha criado para ler essa informacao. Implemente essa ultima solucao. 10 - usando o comando dd no minix + a informacao sobre o superbloco do minix3, apresente o mapa de bits de zonas. Quais sao as zonas livres? Verifique se isso de fato ocorre. Crie um arquivo com um certo tamanho. Verifique o numero de zonas livres. Crie um arquivo bem maior. Verifique o numero de zonas livres. Faça um programa que abre um arquivo para escrita e fica num loop infinito escrevendo bytes até que seja gerada uma mensagem de erro. Localize essa mensagem de erro no minix. Estude de novo o mapa de bits de zonas. Ele está cheio?