so-16

Apresentacao do curso: programacao aula a aula. Apresentacao do material didatico: livros do Tanenbaum e Silberzchatz. Criterio de avaliacao.

O site http://www.cs.vu.nl/~ast/ é do prof. Tanenbaum. Em seu site, ele deixou o conjunto de transparênicas: http://www.cs.vu.nl/~ast/books/mos2/mos2-ppt.zip que vamos utilizar no curso.

transparencia a ser usada: Chapter-01.ppt slides 1-8.

Pedir para os alunos se dividirem em grupos. Da proxima vez pedir grupos com o minimo de alunos e depois acrescenta. Extra: história do Minix, Linux e comentários sobre os projetos da fase 1.

Chapter-01.ppt 9-14 - Computer Hardware Review - interrupcao. comentários sobre os projetos da fase 1. Alocacao das turmas. Extra: comentario sobre o minix - o microkernel, processos do SO e processos de usuario; o linux como sistema monolitico. Incentivar que as turmas comecem os trabalhos.

transparencias Chapter-01.ppt 15-21 hardware da aula passada: memoria.

Codigo relativo: os labels ainda nao foram definidos pelo linker. Codigo absoluto: os lables foram definidos pelo linker. O programa em codigo absoluto ao ser colocado na memoria deve entrar de forma "relativa" a algum endereco (um endereco definido em um registrador base).

Quando se faz uma system call, no final a pilha deve ser limpa incrementando o SP. Explicar que tem 4 formas de se implementar push e pop em pilha.

Termina a aula procurando explicar o melhor possivel como funciona interrupcao no computador. Explicar interrupcao de software e de hardware. Relacionar com o projeto de SO. Bater a foto da losa.

Finalizar Chapter-01,ppt 21-35 system calls comentar sobre máquinas virtuais. sistemas monolíticos (linux) x microkernel (minix). falar sobre o projeto: os alunos devem mostrar em que código (arquivo fonte) está a interrupcao de software quando ocorre a system call. No linux, processo usuario nao eh debugado, mesmo se compilado com opcao -g; somente o kernel eh debugado.

TRAZER: apresentacao em powerpoint relatorio; enviar para mim via email no dia da apresentacao. relacionar a apresentacao com o codigo do linux e minix quando apropriado.

Se sobrar tempo: Filme: https://www.youtube.com/watch?v=iBVgcjhYV2A Revolution OS https://www.youtube.com/watch?v=xHu7qI1gDPA

transparencias "Processes and Threads". 1-24. Se sobrar tempo falar sobre os exercicios que passei. resumir explicacao sobre a diferenca entre treads e processos: basta colocar as transparencias principais sobre thread de kernel e de usuário. Ao explicar sobre threads seja mais rápido em afirmar que existe uma parte que cuida da execucao (PC, registradores, ponteiro de pilha) e outra que cuida dos recursos (memoria, arquivos). process group - lidar com signals de processos em foreground e background. Serah que eh usado muito hoje em dia com o X-windows? group id. Coloquei tudo em um desenho: vetor de interrupcao e tabela de processos.

transparencias "interprocess communication", 1-10,11 Solucao de Peterson: 3 casos: 1- a regiao critica eh acessada em momentos diferentes - sem problema 2- a regiao critica serah acessada quase ao mesmo tempo, mas nao hah conflito em enter_region (o processo 0 ou 1 nao chaveia em enter_region) - sem problema. 3- a regiao critica serah acessada quase ao mesmo tempo e hah conflito em enter_region: o último a fazer turn=process eh o que fica em loop e nao entra na regiao critica.

Sleep and Wakeup Para pensar:

• explique a perda de wakeup com o buffer cheio.
• como corrigir o código adicionando uma flag informando que o sinal foi perdido?

Semáforos: Explicar como exclusao mutua pode ser feita usando semáforos. Mostrar o caso em rede de Petri.

A aula retoma o que seja o up e o down em semaforos. transparencias "interprocess communication", 11-25 explicar exclusao mutua com semaforos modelado em redes de Petri. explicar semaforos para resolver o problema do consumidor produtor.

static class: a declaracao permite que uma classe declarada dentro de outra seja visivel fora da classe-pai. http://www.programcreek.com/2009/02/notify-and-wait-example/ wait( ) tells the calling thread to give up the monitor and go to sleep until some other thread enters the same monitor and calls notify( ). notify( ) wakes up the first thread that called wait( ) on the same object. notifyAll( ) wakes up all the threads that called wait( ) on the same object. The highest priority thread will run first. Monitores, condition variables: http://en.wikipedia.org/wiki/Monitor_%28synchronization%29

1. Transparencias "scheduling - introduction to scheduling"

Explicar melhor o conflito no batch system entre turnround time e throuput. Ao colocar jobs mais curtos na frente diminuo o tempo de retorno medio (mean turnround time) pg 109 - minix3. Ao colocar jobs mais curto na frente aumento a vazao, pg 107; porem posso ter tempos de retorno terriveis para processos longos.

1. filosofos jantando.

equipes pares

equipes ímpares

Transparencias do silberschatz capitulo 13. http://codex.cs.yale.edu/avi/os-book/OS9/slide-dir/PPT-dir/ch13.ppt

até Block and Character Devices - 13.20.

Transparencias do silberschatz capitulo 13. http://codex.cs.yale.edu/avi/os-book/OS7/os7c/slide-dir/ch13.ppt do slide 13.17 até o final. pula a parte de streams.

• discutir como implementei um driver para a porta paralela.
• discutir como poderia ser implementado a syscall getchar e como funciona o mecanismo de interrupcao do teclado.

transparencias: Chapter-03.ppt (mos2-ppt.zip)

equipes ímpares

equipes pares

transparecias - chapter 4; 1-11 (mos2-ppt.zip)

-> Como gerenciar memória no evaluator 7t que nao possui MMU?

• para deixar a aula mais interessante deveria comentar como funcionamento o gerenciamento de memoria no minix sem usar a memoria virtual.

-> dar a aula rapidamente e depois comentar o que eh cada exercicio da fase 4 no final da aula; enfatizando principalmente os exercicios que envolvem o minix.

transparencias - chapter 04 (mos2-ppt.zip); 12-20 (troca otimo), 32 (comparar FIFO com otimo). Inverted page tables http://www.cs.nmsu.edu/~pfeiffer/classes/573/notes/ipt.html geralmente a tabela de páginas é uma por processo, mas no caso da inverted page table, não. Nesse caso, a memória RAM está dividida em páginas sendo algumas para um processo, outras para outro processo, etc. A inverted page table mapea essa RAM atribuida a vários processos. Funciona graças aa TLB que armazena as entradas da tabela de paginas. No maximo ateh algoritmo de troca otimo.

Eh possivel dar a anomalia de Belady usando o algoritmo otimo? Fazer uma simulacao.

termina algoritmos de troca tanenbaum transparencias vitural memory (2) 21-31 exercicio 4.12 pg 442

Comentar sobre o algorimto worst e como ele pode ser usado para avaliar outros algoritmos pois dah uma piso minimo.

• De final de working set ateh segmentacao.
• memória Linux.

http://www.youtube.com/watch?v=NtKAG46_3Vg - memoria linux http://kerneltrap.org/node/2450/ memoria linux http://www.youtube.com/watch?v=L2SED6sewRw - desenvolvimento do kernel Item 21.6.2 do Silberschatz

Fazer um grande desenho procurando resumir tudo o que foi ensinado ateh agora em SO.

• colocar um mapa geral de um SO - hw e sw.

– hw - MMU, TBL, e page fault . – sw. - interrupcoes em geral, mas acrescentando com as page faults, colocar a transparencia da interrupcao de page fault e relacionar na figura com os algoritmos de troca de paginas..

equipes pares

equipes impares.

ateh inodes. transparencias Chapter06 - 1-21 Finalizar com: Qual o tamanho maximo do arquivo? transparencia de i-node no unix.

terminar sistemas de arquivos

• discutir o gerenciador de arquivos no minix. (cap 5 do projeto e implementacao).

equipes impares

equipes pares

Altere o boot do linux apresentado em http://www.pcs.usp.br/~jkinoshi/2012/linux-qemu-gdb.org de forma a se ter um processo (correspondente ao init) executando a system call read. Para isso altere o rootfs e crie um arquivo lá. O boot lerá a primeira linha do arquivo e ficará em loop imprindo-a. Quando a system call read é chamada no linux, a funcao do_read é executada dentro do kernel. Explique como isso ocorre, observando o código fonte do linux e o tutorial em http://www.pcs.usp.br/~jkinoshi/2012/linux-qemu-gdb.org . Localize no código do linux onde ocorre o tratamento das system calls. Relacione o endereco dessa primeira instrucao com o vetor de interrupcao. Coloque um breakpoint e observe o valor de R7 que contém o numero da system call. Gere um relatório anexando apenas as partes de código mais relevantes e relacionadas com o SWI, bem como print screens da tela do qemu.

9>

Altere o boot do linux apresentado em http://www.pcs.usp.br/~jkinoshi/2012/linux-qemu-gdb.org de forma que: O processo pai (correspondente ao init) fica imprindo "sou processo 1" e o processo filho imprime "filho imprimindo". Quando a system call fork (veja o código que implementa fork) é chamada no linux, a funcao do_fork é executada dentro do kernel. Explique como isso ocorre, observando o código fonte do linux e o tutorial em http://www.pcs.usp.br/~jkinoshi/2012/linux-qemu-gdb.org . Localize no código do linux onde ocorre o tratamento das system calls. Relacione o endereco dessa primeira instrucao com o vetor de interrupcao. Coloque um breakpoint e observe o valor de R7 que contém o numero da system call. Gere um relatório anexando apenas as partes de código mais relevantes e relacionadas com o SWI, bem como print screens da tela do qemu.

Localize no código do linux onde ocorre o tratamento das system calls. Relacione o endereco dessa primeira instrucao com o vetor de interrupcao. Coloque um breakpoint e observe o valor de R7 que contém o numero da system call. Gere um relatório anexando apenas as partes de código mais relevantes e relacionadas com o SWI, bem como print screens da tela do qemu.

8> boa apresentacao, mas poderia ter estudado melhor a passagem para o kernel.

Altere o boot do linux apresentado em http://www.pcs.usp.br/~jkinoshi/2012/linux-qemu-gdb.org de forma que: O processo pai correspondente ao init faz fork e fica imprindo "sou processo 1". O processo filho faz execve e executa o código do filho. O filho imprime "filho imprimindo". O programa fonte correpondente ao processo pai deve estar em pai.c e o correspondente ao filho em filho.c. Eles devem ser compilados para o ARM. Os programas pai e filho devem ser previamente armazenados em rootfs. Quando a system call exec é chamada no linux, a funcao do_exec é executada dentro do kernel. Explique como isso ocorre, observando o código fonte do linux e o tutorial em http://www.pcs.usp.br/~jkinoshi/2012/linux-qemu-gdb.org. Localize no código do linux onde ocorre o tratamento das system calls. Relacione o endereco dessa primeira instrucao com o vetor de interrupcao. Coloque um breakpoint e observe o valor de R7 que contém o numero da system call. Gere um relatório anexando apenas as partes de código mais relevantes e relacionadas com o SWI, bem como print screens da tela do qemu.

10> observaram que logo apos o svc vai para 0xffff0008 - entrada no vetor de interrupcao, alem de terem observado a transicao de modo usuario para supervisor. 5> Stefano - sem participacao no grupo.

Faça um programa em C num linux normal (ex: ubuntu) que le as linhas de um certo arquivo usando as system calls open e read. Debugue esse programa usando o gdb; mostre o codigo assembly quando a system call eh chamada. Quando ocorre a troca de contexto? Veja man syscall. Altere a system call read de tal forma que ela seja implementada pela funcao syscall.

8> 0> Gabriel faltou 4> Alexander (nao participou).

Adaptando os passos de http://www.tldp.org/HOWTO/html_single/Implement-Sys-Call-Linux-2.6-i386/ para o ARM, implemente uma system call que imprima Hello World quando chamada. Altere o boot do linux apresentado em http://www.pcs.usp.br/~jkinoshi/2012/linux-qemu-gdb.org de forma a se ter um processo (correspondente ao init) executando essa system call. Veja "man syscall" e explique o que faz a funcao syscall.

9> observaram bem o call.s

Adaptando os passos de http://www.tldp.org/HOWTO/html_single/Implement-Sys-Call-Linux-2.6-i386/ para o ARM, implemente uma system call que recebe um numero como parametro, e retorna o numero somado de 10. Altere o boot do linux apresentado em http://www.pcs.usp.br/~jkinoshi/2012/linux-qemu-gdb.org de forma a se ter um processo (correspondente ao init) executando essa system call.

9>

Altere o boot do linux apresentado em http://www.pcs.usp.br/~jkinoshi/2012/linux-qemu-gdb.org de forma a se ter um processo (correspondente ao init) executando a system call read. Para isso altere o rootfs e crie um arquivo lá. O boot lerá a primeira linha do arquivo e ficará em loop imprindo-a. Quando a system call read é chamada no linux, a funcao do_read é executada dentro do kernel. Explique como isso ocorre, observando o código fonte do linux e o tutorial em http://www.pcs.usp.br/~jkinoshi/2012/linux-qemu-gdb.org . Apresente o codigo assembly correspondente ao processo init (que roda em modo usuário). Localize no código do linux onde é feito o SWI ou SVC.

8>

Adaptando os passos de http://www.tldp.org/HOWTO/html_single/Implement-Sys-Call-Linux-2.6-i386/ para o ARM, implemente uma system call que imprima Hello World quando chamada. Altere o boot do linux apresentado em http://www.pcs.usp.br/~jkinoshi/2012/linux-qemu-gdb.org de forma a se ter um processo (correspondente ao init) executando essa system call. O numero da system call foi definido em:

#define __NRmycall 317

e foi usado em long mycall(int i)

{

return syscall(__NRmycall, i);

}

Responda:

1. mycall roda em modo kernel ou modo usuário?
2. o código syscall em

return syscall(__NRmycall, i); roda em modo kernel ou modo usuário?

1. apresente e explique o código syscall.

8> Rafael Augusto, R. Novak 6> Marina, Joao Bosco, Rafel Brandao.

Adaptando os passos de http://www.tldp.org/HOWTO/html_single/Implement-Sys-Call-Linux-2.6-i386/ para o ARM, implemente uma system call que imprima um numero relacionado com a data e hora atual. como o numero de segundos a partir de 1 de Janeiro de 1970 (o objetivo eh apenas externar algo que o kernel conhece). Altere o boot do linux apresentado em http://www.pcs.usp.br/~jkinoshi/2012/linux-qemu-gdb.org de forma a se ter um processo (correspondente ao init) executando essa system call. O numero da system call foi definido em:

#define __NRmycall 317

e foi usado em long mycall(int i)

{

return syscall(__NRmycall, i);

}

Responda:

1. mycall roda em modo kernel ou modo usuário?
2. o código syscall em

return syscall(__NRmycall, i); roda em modo kernel ou modo usuário?

1. apresente e explique o código syscall.

> 9 -1:atraso = 8 > 0 Cesar Augusto Faustino faltou.

Em http://www.linuxdevcenter.com/lpt/a/7029 temos a apresentacao de threads em modo usuario usando semaforos; porem versoes de semaforos para threads sem fazer chamadas de sistema. Em http://www.cis.upenn.edu/~lee/07cis505/Lec/SemaphoreOperations.pdf temos o uso de semaforos fazendo chamadas de sistema - semop.

Altere o init para fazer algo como:

if (fork() ) {
   while (1) {
      print "1"
      down(S) 
      print 2
      up(S)
      print 3
   }


} else {
  while (1) {
      print "A"
      down(S)
      print X 
      print B
      up(S)
      print C
   }
}

trocando up e down pelo semop. O valor do semáforo é gerenciado pelo kernel porque duas ou mais threads podem estar alterando o seu valor e o kernel deve evitar condicoes de corrida nessas alteracoes. Coloque um breakpoint para observar como o kernel altera o valor do semáforo e retire print screens. Vamos supor que uma thread A fique bloqueada aguardando o incremento do semáforo por outra thread B. No momento em que a outra thread B pedir ao kernel para incrementar o semáforo, o kernel deve desbloquear a thread A. Analise o código do kernel do linux e descubra onde isso ocorre. Coloque um breakpoint nessa posicao, rode o gdb até essa posicao, retire um printscreen. Analise a fila de execucao dos processos. Para isso será necessário estudar http://isis.poly.edu/kulesh/stuff/src/klist/ para entender como o kernel do linux gerencia listas. Motre o processo bloqueado no down e sendo desbloqueado pelo up. Verifique que no "up", o processo bloqueado é retirado da fila do semáforo e vai para a fila dos processos prontos. Ver o codigo do spin lock no kernel no up e no down. Encontre o código onde o processo desbloqueado é colocado na fila do escalonador.

Encontre no código fonte a fila de processos associado ao semáforo. Crie e teste a sistema call esperasem(semaforo) que retorna o pid do processo que estah na fila associado ao semaforo. Teste essa system call em seu codigo.

> 10 Erick, Isabela; 7 Pedro; Lucas 4.

Entenda o seguinte código:

#include<stdio.h>
#include<signal.h>
void bypass_sigint(int sig_no)
{
  printf("dividi por zero\n");
}
int main()
{
  int a,b,c;
    struct sigaction sa;
    memset(&sa, 0, sizeof(sa));
    sa.sa_handler = &bypass_sigint;
    sigaction(SIGFPE, &sa,NULL);
    while (1) {
      sleep(1);
        printf("do nothing \n ");
    }
    return 0;
}

Esse código ativa a funcao sigint toda vez que houver uma divisão por zero. Mas um outro processo pode enviar um signal, dizendo que houve uma divisão por zero. Experimente em uma outra shell fazer: kill -8 #pid_processo

onde -8 se refere a SIGPFE, divisão por zero. Para você realmente observar que houve uma divisão por zero, experimente colocar dentro do código, após sigaction:

a = 1; b= 0; c = a/b;

e veja que a rotina imprime "dividi por zero".

Experimente em uma outra shell fazer: kill -8 #pid_processo

Como o linux trata a divisão por zero? Explique o código. É de se esperar que o linux envie um signal para o processo que fez a divisão por zero. Faça um programa executável que faz a divisão por zero no linux rodando no qemu. Rode o programa e capture o signal imprimindo na tela uma mensagem toda vez que for feita a divisão por zero. O kernel contém uma estrutura de dados guarda o signal handler do processo. Observem a estrutura de dados dentro do kernel que mostra a que sinais estao associados quais handlers.

Estude o código que trata sigaction(SIGFPE, &sa,NULL); e observe qual é essa estrutura de dados. Quando ocorrer a divisão por zero, essa estrutura de dados será usada para ativar o signal handler ( bypass_sigint) adequado. Faça um print screen do qemu 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 do ARM - pesqui sobre isso). 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 linux? O que acontece desde a interrupcao gerada pela divisao por zero ateh a chamada da rotina bypass_sigint (signal handler)? Como o SO fica sabendo qual é o signal handler que deve ser chamado?

Observe o seguinte: quando existe a divisao por zero no programa, ou seja, quando o codigo a = 1; b= 0; c = a/b; eh executado, o signal handler eh executado mas retorna para antes da divisao ser feita. Isso faz com que c = a/b seja executado infinitamente pois a instrucao a/b eh sempre colocada novamente para rodar após o signal handler ser executado. Uma forma de resolver isso eh criar um signal handler que retorna para a instrucao posterior no caso de SIGFPE acessando a pilha em assembly (Ver 'man 2 signal').

> 8 - bem colocado, mostrou o chaveamento do kernel para o signal handler. Seria interessante ter mostrado o kill.

Estude e explique tanto na apresentacao quanto no relatorio: http://www.ibm.com/developerworks/library/l-completely-fair-scheduler/ Crie a system call cfs() que retorna uma string contendo pares de pid:virtualRuntime de forma ordenada. Do processo com o menor virtual runtime ateh o processo com o maior virtual runtime. Para testar, crie um init que faz chamada de alguns processos, alguns que usam muito a cpu fazendo calculos e outros que usam pouco a cpu lendo dados do teclado.

> 10

Usando qemu no linux compilado para o Versatile, faca com que o linux rode apenas um processo: o processo que continuamente le caracteres do teclado (usando getchar() e os imprime na tela. Coloque um breakpoint na interrupção de teclado. Faça um print screen do qemu 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 manual do ARM7 (consulte na internet como o ARM trata interrupcoes de hardware; veja tambem a apostila usada no laboratorio de microprocessadores). Onde (em qual arquivo fonte do linux) o estado do processo é armazenado? Relacione isso com o código do linux 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? Explique. Após a syscall getchar, o processo é bloqueado enquanto nada é teclado. Mostre como o processo é bloqueado (retirado da fila de execucao e colocado em uma outra fila para esperar o caracter). Após o caracter ser teclado, ocorre a SWI, e o processo é então desbloqueado. Mostre como isso ocorre. Retire os printscreens mostrando isso ocorrendo e anexe no relatório.

> 8 ao sair da interrupcao cai no idle. Seria interessante mostrar como imprime o caracter teclado depois da interrupcao.

Veja a figura 3-3 do livro: Linux kernel Development do Robert Love que contém os estados em que um processo pode estar (Veja a task_struct). Crie a system call mostraEstado(pid) que quando chamada mostra o estado em que se encontra o processo com certo pid. Faça com que o init dispare um processo filho que:

• imprime 10 vezes alguma mensagem
• executa getchar() esperando um dado do teclado (e ficando bloqueado).

O processo init deve: ficar em um loop infinito imprindo o estado do filho através de mostraEstado(pidFilho) O objetivo eh observar o processo filho entrando no estado de bloqueado quando chama getchar().

> 10

Em init crie um processo filho FILHO e faça com que o filho crie outro processo NETO. O processo INIT e NETO ficam em loops continuos imprimindo alguma mensagem, mas o processo FILHo apenas impreme uma mensagem e termina. O que acontece com NETO? Crie a sistema call pid_pai() que quando chamada retorna o pid do pai (veja a task_struct). Faça com que NETO fique continuamente chamando pid_pai e imprimindo o pid do pai.

> 10 criaram a system call e observaram que todo orfao eh adotado pelo init.

Processos interativos tendem a ter a prioridade maior. Crie a system_call prioridade(pid) que retorna a prioridade do processo de acordo como seu pid (veja o valor nice). Crie um processo que apenas fica executando contas e outro que fica continuamente imprimindo a prioridade de ambos os processos com base na prioridade(pid). Existe uma divergencia nas prioridades?

> 8

Crie processos no qemu/versatile que usam as seguintes system calls: nice() Sets a process’s nice value sched_setscheduler() Sets a process’s scheduling policy sched_getscheduler() Gets a process’s scheduling policy sched_setparam() Sets a process’s real-time priority sched_getparam() Gets a process’s real-time priority sched_{getprioritymax}() Gets the maximum real-time priority sched_{getprioritymin}() Gets the minimum real-time priority sched_{rrgetinterval}() Gets a process’s timeslice value sched_setaffinity() Sets a process’s processor affinity sched_getaffinity() Gets a process’s processor affinity Crie um processo que apenas fica executando contas e outro que fica continuamente imprimindo a prioridade de ambos os processos com base na prioridade(pid). Existe uma divergencia nas prioridades?

> 7; Rafel C. ->0, nao deu para observar que processos que usam mais a cpu tem sua prioridade reduzida, talvez devido a estar em maquina virtual. Melhor se apresentar as system calls e o que fazem.

Estude a system call: sched_yield() Temporarily yields the processor crie pelo menos dois processos, um mais ativo e outro que temporiamente libera o processador. Use rr_getinterval() para monitorar o valor de time slice. entenda como funciona essa system call, explique e coloque no relatorio.

>9-1 = 8; Cesar Augusto Faustino ->0

O systemtap é uma linguagem onde se escreve scripts que rodam em modo kernel, permitindo extrair diversos dados do sistema operacional. Veja: https://sourceware.org/systemtap/SystemTap_Beginners_Guide/

Exemplos de uso: https://sourceware.org/systemtap/examples/#process/cycle_thief.stp Um exemplo é: process/sleepingBeauties.stp - Generate Backtraces of Threads Waiting for IO Operations keywords: IO SCHEDULER BACKTRACE

The script monitors the time that threads spend in waiting for IO operations (in "D" state) in the wait_{forcompletion} function. If a thread spends over 10ms, its name and backtrace is printed, and later so is the total delay.

Rode esse script em um ubuntu 14.4. Crie um processo que dispara duas threads, sendo que essas duas threads fazem getchar(). Observe se essas threads aparecem esperando pela operacao de I/O.

Entenda e explique o script.

O systemtap é uma linguagem onde se escreve scripts que rodam em modo kernel, permitindo extrair diversos dados do sistema operacional. Veja: https://sourceware.org/systemtap/SystemTap_Beginners_Guide/

Exemplos de uso: https://sourceware.org/systemtap/examples/#process/cycle_thief.stp

profiling/latencytap.stp - Show Reasons and Durations for Processes Sleeping

keywords: _BEST PROFILING

The latencytap.stp script collects data on the intervals processes are deactivated (sleeping). The script categorizes the reasons for the sleeps by analyzing the backtraces and displays a sorted list of the top 20 causes from largest total sum time sleeping to smallest. The output is updated every 30 seconds. The script needs to be compiled with the '–all-modules' option to produce reasons for sleeps caused by modules. Optionally, this script can be used with the '-c' or '-x' options to focus on a specific PID.

Rode o script latencytap.stp em seu ubuntu 14.4. Estude o código e apresente para a classe.

O systemtap é uma linguagem onde se escreve scripts que rodam em modo kernel, permitindo extrair diversos dados do sistema operacional. Veja: https://sourceware.org/systemtap/SystemTap_Beginners_Guide/

Veja como o systemtap pode ser usado para monitorar como um dispositivo de entrada/saida está sendo usado:

https://sourceware.org/systemtap/SystemTap_Beginners_Guide/traceio2sect.html

Rode esse exemplo com diversos dispositivos. Entenda e explique o script.

No ubuntu 14.4 recompilem o kernel do linux. Crie em /proc o arquivo /proc/esperateclado que imprime os processos que ficam aguardando uma tecla a ser digitada. Isso pode ser implementado tanto no ubuntu quanto no versatile, o que julgarem mais facil. No ubuntu 14.4, ao se fazer more /moreæsperateclado devemos ver, os processos aguardando uma tecla a ser teclada.

O systemtap é uma linguagem onde se escreve scripts que rodam em modo kernel, permitindo extrair diversos dados do sistema operacional. Veja: https://sourceware.org/systemtap/SystemTap_Beginners_Guide/

Rode o exemplo https://sourceware.org/systemtap/SystemTap_Beginners_Guide/threadtimessect.html

Explique como funciona o script. Faça testes criando dois processos, um que faça muitas contas - e portanto fica muito tempo rodando em modo usuário e outro que faça mais I/O e portanto fica mais tempo rodando em modo kernel.

Na experiencia passada, a equpe 1 implementou uma system call que apresenta os processos na fila de um semáforo. O filesystem /proc externaliza informação do kernel. É possível construir um file em /proc de tal forma a apresentar o número do semáforo e os processos bloqueados nele. O tutorial http://www.tldp.org/LDP/lkmpg/2.6/html/lkmpg.html#AEN128 apresenta como construir um file em /proc. O objetivo é construir o file /proc/waitsem que apresenta para cada semáforo os processos que estao bloqueados nele ao se fazer, por exemplo: more /proc/waitsem

A partir de: http://www.pcs.usp.br/~jkinoshi/2008/Exp8_revisada_13_08_07.doc: 1 - crie um driver simples no linux normal (ex: ubuntu). 2 - crie o driver padrao e teste a leitura e escrita no driver usando "echo" na maquina virtual. O passo 1 é muito simples, porém existem diversas dificuldades para fazer o mesmo na maquina virtual/ARM:

• como criar uma entrada no rootfs para o driver padrao? Deve ser através de system calls para se fazer o mknod. Assim, crie um init que somente irá criar uma entrada em /dev em rootfs para o driver da entrada padrao.
• a compilacao do driver padrao para o ARM pode apresentar dificuldades. Existem duas formas de se fazer o driver padrao para o ARM - como um modulo a ser carregado ou já compilado no kernel. Experimentem recompilar o kernel com o driver padrao jah inserido no kernel. Observem algumas system calls a serem chamadas pelo init como makedev e mknod. Alterarem o Makefile em /driver para criar o driver no kernel.

No ubuntu usando systemtap, crie um script que imprima os processos que ficam bloqueados aguardando que o usuário tecle algo. Crie um init que crie 3 processos e cada processo faz um getchar. Os 3 processos ficam bloqueados esperando com que o usuario tecle algo. Rode o seus script e observe os processos bloqueados aguardando o usuário teclar algo.

Para treinar, faca um processo que fique num loop lendo e escrevendo os caracteres que se digita no versatile emulado. Crie um init que crie 3 processos e cada processo faz um getchar. Os 3 processos ficam bloqueados esperando com que o usuario tecle algo. Quando o usuario teclar, um dos processos eh desbloqueado pois recebe o caracter digitado. Observem quando se colocar e retira os processos da fila do I/O para teclado serial através de add.wait.queue e remove. wait.queue. Um dos parametros dessas rotinas eh a propria queue. Crie uma system call que quando chamada imprima os processos aguardando que um caracter seja digitado. Crie um processo que continuamente chama e imprime essa system call.

Existem formas de se ver processos gerando page faults no linux/ubuntu. Exemplo: http://www.ewhathow.com/2013/09/how-to-identify-page-faults-on-linux/ Crie um programa em C que gere muitas page faults em um linux normal (idéia: que esteja continuamente alocando muito memória para si). Monitore esse programa para observar se de fato tem gerado muitas page faults. (http://www.linuxjournal.com/article/8178)

Rode o linux/ubuntu e observe a invasao de memoria.

Veja em: https://sourceware.org/systemtap/examples/keyword-index.html memory/pfaults.stp - Generate Log of Major and Minor Page Faults keywords: MEMORY The pfaults.stp script generates a simple log for each major and minor page fault that occurs on the system. Each line contains a timestamp (in microseconds) when the page fault servicing was completed, the pid of the process, the address of the page fault, the type of access (read or write), the type of fault (major or minor), and the elapsed time for page fault. This log can be examined to determine where the page faults are occurring.

Estude e explique como o kernel lida com o page fault.

Em um linux normal (ex: ubuntu), crie uma area de memoria compartilhada por dois processos diferentes no linux (veja mmap) 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 (veja /proc). Faca testes para verificar qual o maximo de área de memória possível compartilhada entre ambos os processos.

No Linux/Versatile faca com que o init crie dois processos com área de memória compartilhada. Coloque um breakpoint na entrada dessa system call, bem como em outras posicoes. Retire uns printscreens do bt (backtrace); isto é, para descobrir que funçoes do kernel sao chamadas para executar essa system call. Busque referencias na internet e livros para explicar como o kernel do linux faz a memória compartilhada.

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 (dica: veja /proc). Esses enderecos virtuais 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? Talvez não seja possível, procure comprovar isso. Observe que existem dois tipos de bibliotecas : dinamicas e carregáveis (as dinamicas precisam do comando ldd para carregar primeiro a biblioteca e depois executar o codigo). As loadble verificam se estah na memoria, se não estiver jah sai carregando. Experimente usar os dois tipos de biblioteca. Nao eh necessario colocar no arm+qemu pois eh muito mais facil fazer testes direto no ubuntu.

Procure na internet e livros sobre o alocador slab/slub; uma referência é: http://www.secretmango.com/jimb/Whitepapers/slabs/slab.html Entenda e explique no relatório para que serve esse alocador, como a memória é alocada e desalocada para uso do kernel. Quando um arquivo é aberto, o kernel aloca memória para o seu inode (uma estrutura de dados contendo ponteiros para blocos, data da criação, permissões, etc.). Crie um programa bem simples (o correspondente ao init) para rodar no Linux/Versatile para observarmos como isso funciona. O programa deve abrir um arquivo, escrever algo nesse arquivo e fechar o arquivo. Quando o arquivo é aberto, o kernel aloca memória para o inode. Quando o arquivo é fechado, a área para o inode deve ser desalocada. Usando o gdb rode até que a system call execve ative este programa (para garantir que as estruturas do kernel já estão prontas). Coloque breakpoints quando a área de memória para o inode é criada e liberada. Coloque os printscreens da tela no relatório. Apresente ao vivo para a classe. Rode no linux/arm no qemu. Verifique que memória eh alocada para o inode quando o open eh feito pela primeira vez. Jah na segunda vez, a memoria eh reutilizada.

Estouro de pilha (stack overflow): monitorar quando ocorre estouro de pilha. Você pode criar a rotina recursiva imprime que chama ela mesma indefinidamente no linux. 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 linux e observe o estouro de pilha.

Veja em: https://sourceware.org/systemtap/examples/keyword-index.html Rode algum scritp systemtap para logar esse tipo de falha. Talvez o script o script overcommit.stp detecte essa falha.

memory/overcommit.stp - Log Failed Process Memory Allocation Due to Overcommit Limits keywords: MEMORY LIMITS The overcommit.stp script prints a line each time the kernel refuses a memory allocation request from a process because of /proc/sys/vm/overcommit* limits.

Coloque o printscreen no relatório.

Mostrar através de um log como a memória foi alocada e desalocada a processos no linux. Toda vez que um processo executar um fork, exec, exit afeta a alocação de memória. Apresente isso num log (imprima usando printk). No log contém informações como: system call (fork) - processo (/usr/bin/init +) quantidade_{debytesalocada} pg_memoriafisca.

onde:

• : significa que memória está sendo alocada ao processo
• : significa que memória está sendo desalocada e devolvida para a área livre.

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 linux? 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.

Como o linux 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 a partir da posicao zero ateh o maximo. Ao fazer isso no linux que erro você observa? Localize o tratamento desse erro no código fonte do linux. 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 linux.

Rode o linux/ubuntu e observe a invasao de memoria.

Veja em: https://sourceware.org/systemtap/examples/keyword-index.html Rode algum scritp systemtap para logar esse tipo de falha. Talvez o script o script overcommit.stp detecte essa falha.

memory/overcommit.stp - Log Failed Process Memory Allocation Due to Overcommit Limits keywords: MEMORY LIMITS The overcommit.stp script prints a line each time the kernel refuses a memory allocation request from a process because of /proc/sys/vm/overcommit* limits.

Estude e explique como o kernel o acesso indevido.

Quando o Linux 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 linux; mas basicamente ele deve ler o arquivo executável e retirar essa informacao quando executa a system call exec. Localize no código do linux onde isso ocorre. Com base nesse código crie um aplicatio que tem como entrada um arquivo executável do linux (vc. pode criar um arquivo executável qualquer) e mostre o quanto o programa precisa de área de memória (dados, codigo/texto, pilha). Exemplo: precisamemoria arquivoexecutavel retorna o entrypoint e o quanto precisa de área de dados, código e pilha.

No ubuntu, imprima a tabela de paginas de um processo especifico como o firefox. Identifique as areas de codigo, dados, pilha, bem como, codigo compartilhado de bibliotecas e a area que fica no kernel. Procure na internet como fazer isso, ou crie uma system call que faça isso.