Curso sistemas operacionais 2018 PCS3746 prof. Jorge Kinoshita.

Aulas segunda: 14:00-15:40H, sala B2-4 sexta: 10:20-12:00H, sala B2-4

1 Programação aula a aula.

1.1 <2018-05-07 Seg> ) 1.1 O que é um sistema operacional, 1.2 História dos sistemas operacionais

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.

1.2 <2018-05-11 Sex> ) Visao do hardware

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.

1.3 <2018-05-14 Seg> ) conceitos de sistema operacional; 1.4 chamadas de sistema

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.

1.4 <2018-05-18 Sex> ) 1.4 chamadas de sistema 1.5 estrutra do sistema operacional.

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.

1.5 <2018-05-21 Seg> ) => apresentação dos projetos (fase 1) : grupos ímpares

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

1.6 <2018-05-25 Sex> ) - apresentação dos projetos (fase 1) : grupos pares

1.7 <2018-05-28 Seg> ) sem aula problma greve caminhoneiro

1.8 <2018-06-01 Sex> -> feriado

1.9 <2018-06-04 Seg> ) 2.2 comunicação interprocesso até solucao de peterson

2.1 introdução aos processos

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.

1.10 <2018-06-08 Sex> ) 2.2 comunicacao inter processos - comeco de 2.3

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_(synchronization)

1.11 <2018-06-11 Seg> ) 2.3 problemas clássicos de CIP 2.4 agendamento de processo + problema reader/writer.

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.

filosofos jantando.

1.12 <2018-06-15 Sex> ) => Projetos 2.5 visão geral de processos em minix (fase 2)

equipes pares

1.13 <2018-06-18 Seg> ) => Projetos 2.5 visão geral de processos em minix (fase 2)

equipes ímpares

1.14 <2018-06-22 Sex> ) jogo brasil x costa rica

1.15 <2018-06-25 Seg> ) prova 1

1.16 <2018-06-29 Sex> ) 3.1 Hardware Entrada e Saida 3.2 Software Entrada e Saida 3.2 Software Entrada e Saida

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.

1.17 <2018-07-02 Seg> ) 3.3 impasses

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

1.18 <2018-07-06 Sex> ) 4.1 gerenciamento básico de memória 4.2 troca (swap)

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

-> transp 6 fig c- em 10 minutos a cpu eh usada 20% do tempo, portanto apenas 2 minutos para um processo. em 5 minutos, a cpu eh usada 36% do tempo por 2 processos, portanto apenas 5 * 0.36 = 1.8 minutos ou seja, 0.9 minutos para cada um dos 2 processos.

-> transp 7 relocacao, protecao -> como o minix trata? Relacionar com fork, exec e exit.

-> swapping comentar swapping x virtual memory - dizer que minix 1 e 2 nao usavam nenhum dos dois.

-> transp 10 first fit next fit best fit worst fit qual o minix usa?

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

para deixar a aula mais interessante deveria comentar como funciona 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.

1.19 <2018-07-09 Seg> -> feriado

1.20 <2018-07-13 Sex> ) => Projetos 3.4 visão geral de E/S no minix (fase 3)

equipes ímpares

1.21 <2018-07-16 Seg> ) => Projetos 3.4 visão geral de E/S no minix (fase 3)

equipes pares

1.22 <2018-07-20 Sex> ) 4.3 memória virtual, 4.4 algoritmos de substituição de página.

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. https://en.wikipedia.org/wiki/Page_table#Inverted_page_table discute o problema de alocar memoria continua usando tabelas de pagina invertidas.

No maximo ateh algoritmo de troca otimo.

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

1.23 <2018-07-27 Sex> ) 4.4, 4.5 questões para sistemas de paginação.

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.

1.24 <2018-07-30 Seg> ) 4.6 segmentação

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.

1.25 <2018-08-03 Sex> ) => Projetos 4.7 visão geral do gerenciamento de memória do minix (fase 4)

equipes pares

1.26 <2018-08-06 Seg> ) => Projetos 4.7 visão geral do gerenciamento de memória do minix (fase 4)

equipes impares.

1.27 <2018-08-10 Sex> ) 5.1 arquivos 5.2 diretórios 5.3 implementação do sistema de arquivos

frisar inodes. transparencias Chapter06 - 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).

1.28 <2018-08-13 Seg> ) prova 2

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 com Java; Silberschatz, Galvin, Gane; Editora Campus

Obs: Este livro apresenta os conceitos de forma mais clara que os livros do Tanenbaum. O titulo "com java" se refere a exemplos em java e nao a um sistema operacional em java (que faz uso de threads do SO, e do gerenciamento de memoria para a criacao de objetos e portanto nao eh adequada para se criar SO). A Editora Campus / Esevier publicou a oitava edicao desse livro.

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.

Sobre Linux: Robert Love, Linux Kernel Development Understanding the Linux Kernel – Publisher: O'REILLY http://www.google.com/books?q=isbn:978-0-596-00565-8 Linux Kernel in a Nutshell – Publisher: O'REILLY: http://www.kroah.com/lkn/ UNIX Internals: The New Frontiers – Author: Uresh Vahalia http://www.google.com/books?q=isbn:9780131019089 Design of The Unix Operating system – Author: Maurice J.Bach http://www.google.com/books?q=isbn:9780132017992 Professional Linux Kernel Architecture [Paperback] Wolfgang Mauerer (Author)

Cursos http://www.cs.berkeley.edu/~kubitron/courses/cs162-F10/

3 Criterio de Avaliação:

O aluno deve ter mais que media 5 nas provas e nos trabalhos.

Nota final = (3 P1 + 4 P2 + 3 P)/10

Caso nao tenha, a nota a ser lançada eh a menor delas. Exemplo: se o aluno tirar como notas de prova, 3 e 5 entao terah como media de nota de prova (3*3 +4*5)/7 = 4,1 que serah a media a ser lancada como nota final independentemente de ter tirado 10 nos trabalhos.

Nota final = (3 P1 + 4 P2)/7

4 Grupos para os projetos.

5 Criterios de avaliacao.

tempo: 20 minutos por equipe, com 5 minutos para perguntas.
usar powerpoint para explicar o que foi feito.
apresentar o sistema rodando ao vivo (muito importante!!!) (caso contrário 1 ponto a menos no mínimo na nota).
entregar um relatorio em pdf no dia da apresentacao. Serah descontado um ponto por dia de atraso na entrega do relatorio.

O relatório e apresentacao em powerpoint devem conter: a. todos os passos para desempenhar a tarefa com referencias caso houver (a sites, livros, etc.). b. print screens da tela - geralmente da maquina virtual. A nota costuma ser dividida entre os alunos que apresentarem o trabalho em pesos iguais; porém os pesos podem ser alterados a critério dos alunos. 8 - bom; o aluno fez o esperado. 10 - melhor que o esperado. cada equipe deve entregar o relatorio no dia da apresentacao via email; cada dia de atraso corresponde a um ponto a menos.

6 Fase 1:

Objetivos gerais: . criar processos de usuários que facam chamadas de sistema e observar como elas se comportam. . system call faz com que o processador passe do modo usuário para o modo kernel. Como isso ocorre? É possível visualizar isso? . dados do kernel sao mais difíceis de serem visualizados por processos comuns. Como o "ps" e "top" visualizam dados do kernel? Através de /proc. . fazer pequenas alteracoes no kernel. Exemplo: fazer o kernel imprimir uma mensagem em um dado momento.

A classe serah dividida em 10 equipes e cada uma terah o trabalho de acordo com: http://linux-kernel-lab.blogspot.com.br/2018/04/assignments-1.html

Team 1 Create an init process that opens a file (text.txt), reads and displays all lines and then, close the file. You must insert the text file, "text.txt", into rootfs. Append screenshots of gdb to your report. The system call "read" passes parameters to the kernel. Using gdb, show the ARM assembly code responsible to it and how the parameters passed to the kernel. What happens when the "init" ends? Team 2 Create an init process that forks it. The parent process continually prints "father" and the child, prints "child". Append screenshots of gdb to your report. The fork() returns zero to the child and the pid of the child to its parent. Using gdb, show how this number is passed to the user process. Append screenshots of gdb to your report. Team 3 Create two processes: 1. init that will fork. The parent will continually print "1". The child will execve "child". 2. child, an executable file to be inserted into rootfs that will continually print "2". Append screenshots of gdb to your report. Using gdb, show how the parameters of execve are passed to the kernel: how the parameters are put in registers or on the stack, and how the kernel receives them. Append screenshots of gdb to your report.

Team 4 We presented the hello_world system call, but unfortunately, it is somehow undocumented. Create another hello_world system call, named hw2, that prints "hello world 2" to make sure you understood how hello_world was written. Google for more information and write a report about it. Change the init, to call hw2. Using gdb, run the hw2 step by step. Explain how hw2 leaves the kernel. Take screenshots of this happening.

Team 5 Let us implement a mechanism to pass data from one process to another, creating two system calls. Create the system call save(number) which just saves a number inside the kernel. Create the system call recover() that returns the number saved. Create an init process that will fork into 2 processes: the parent will continually generate randomly a number and "save(number"). The child will continually number = recover() and print it. Check if it works. Append screenshots to the report.

Team 6 Google how the ARM processor had discovered the instruction address soon after executed the instruction svc. The processor began to execute code in the file "entry-common.S" but how did the processor know about it? Search about it in the linux source code. You will have to study how the interrupt vector is created in the memory. Using gdb, print the instructions in interrupt vector.

Team 7 Many data structures are based on linked lists. The kernel makes use of them. See: http://www.roman10.net/2011/07/28/linux-kernel-programminglinked-list/ You may see that Shibata's team created system calls to push and pop data in a stack kernel using linked lists. Study the code and run it. Change their work. Add two system calls to their work: queue_insert, queue_remove to create and deal with a queue instead of a stack using linked lists in the kernel. Make a init to play with your new system calls. Make two cases: 1. queue_insert and queue_remove works on the same linked list as stack_push and stack_pop; 2. on different linked lists. Append screenshots to the report.

Team 8 Many data structures are based on linked lists. The kernel makes use of them. See: http://www.roman10.net/2011/07/28/linux-kernel-programminglinked-list/ You may see that Shibata's team created system calls to push and pop data in the kernel using linked lists. Study the code and run it. Answer in your report: The variable "count" contains the number of items in the stack, that is, a linked list in the kernel. How does a user process may know about count? Google sysfs (https://en.wikipedia.org/wiki/Sysfs) and explain how Shibata's work dealt with sysfs and "count". Put also in sysfs, the first and last element of the stack. Create the process monitor, besides init, stack_pop (source: stack_pop.c) and stack_push, that continually displays the first, last elements of the stack and count. You may use "sleep".

Team 9 How does really the kernel get the system call number? It is from the svc instruction, but to really understand it, you must know about the bits that make svc. Google it and make your best to explain how the linux kernel gets the system call number. Using gdb, explain step by step how scno is gotten. Tip: Use C-x 2 to switch from source code to machine code. Change the linux source code to externalize the last system call number in sys directory. Create an init file that calls some system calls and displays their numbers. Append gdb screenshots to your report.

Team 10 Create an init process that will:

open the file text.txt (nonexistent) (w)
stay in loop writing one byte each time until you get an error.

What happened to qemu as init could not process a system call? Create an init child to make it so that init survives this kind of error. Google how to create a rootfs with more space to enable text.txt. Append gdb screenshots to your report

7 Fase 2

Veja no blog

adicionar https://www.linuxjournal.com/article/8144 para leitura

8 Fase 3

8.1 4 Linux - teclado

No centos (melhor que ubuntu para isso) 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.

> 7.5 deu problema para apresentar/verificar os processos bloqueados - filtrar melhor os processos bloqueados. rel ok.

8.2 6 Rode o seguinte programa como init:

#include <stdio.h>

void main() { int c; printf("Hello World!\n"); while(1) { c = getchar(); printf ("teclou %d ", c); }; }

A função getchar chamará o sys_read no kernel que esperará o usuário teclar algo seguido de ENTER. sys_read chamará indiretamente a função de leitura do driver da tty (drivers/tty/tty_io.c). Onde isso ocorre? Para se ler da tty, o driver chamará schedule pedindo para se escalonar algum outro processo enquanto o usuário não teclar nada. Onde isso ocorre? Antes da chamada de schedule() imprima quais processos estão prontos para ganhar a CPU? Qual ganhará a CPU? Provavelmente serah a task idle que é escalonada quando não se tem nada a fazer. Discuta o que faz essa task.

> 8.5 ao inves da idle task observaram a kworker - porem deveriam ter observado a idle task se tivessem feito varias observacoes.

8.3 9 Rode o seguinte programa como init:

#include <stdio.h>

void main() { int c; printf("Hello World!\n"); while(1) { c = getchar(); printf ("teclou %d ", c); }; }

A função getchar chamará o sys_read no kernel que esperará o usuário teclar algo seguido de ENTER. sys_read chamará indiretamente a função de leitura do driver da tty. Onde isso ocorre? Se o usuário não tiver teclado nada, o driver chamará schedule pedindo para se escalonar algum outro processo. Onde isso ocorre? Quando o usuário teclar algo, a função __wake_up() em kernel/sched.c serah chamada, pois o kernel avisará o processo de usuário (no caso init) de que algo foi teclado. Coloque um breakpoint em __wake_up e veja o caminho (usando bt no gdb) entre a interrupção e o wake_up. Fazendo isso, talvez voce obtenha:

(gdb) bt #0 __wake_up (q=0xc02128fc, mode=1, nr_exclusive=1, key=0x0) at kernel/sched.c:4338 #1 0xc01302e8 in credit_entropy_bits (r=<value optimized out>, nbits=<value optimized out>) at drivers/char/random.c:556 #2 0xc0130b80 in add_timer_randomness (state=0xc0231e08, num=<value optimized out>) at drivers/char/random.c:676 #3 0xc014c1a8 in input_event (dev=0xc71c3c00, type=4, code=3, value=28) at drivers/input/input.c:355 #4 0xc0151278 in atkbd_interrupt (serio=0xc71abe00, data=<value optimized out>, flags=0) at drivers/input/keyboard/atkbd.c:401 #5 0xc0149c88 in serio_interrupt (serio=<value optimized out>, data=<value optimized out>, dfl=<value optimized out>) at drivers/input/serio/serio.c:996 #6 0xc0149de8 in amba_kmi_int (irq=<value optimized out>, dev_id=0xc71a13e0) at drivers/input/serio/ambakmi.c:47 #7 0xc0061e30 in handle_irq_event_percpu (desc=0xc02097c8, action=0xc7169c60) at kernel/irq/handle.c:126 #8 0xc0061fb8 in handle_irq_event (desc=0xc02097c8) at kernel/irq/handle.c:182 #9 0xc00639b4 in handle_level_irq (irq=<value optimized out>, desc=0xc02097c8) at kernel/irq/chip.c:344 #10 0xc003582c in generic_handle_irq_desc (irq=<value optimized out>, desc=<value optimized out>) at include/linux/irqdesc.h:109 #11 generic_handle_irq (irq=<value optimized out>, desc=<value optimized out>) at include/linux/irqdesc.h:114 #12 fpga_irq_handle (irq=<value optimized out>, desc=<value optimized out>) at arch/arm/plat-versatile/fpga-irq.c:45 #13 0xc0022070 in generic_handle_irq_desc (irq=31, regs=<value optimized out>) at include/linux/irqdesc.h:109 #14 generic_handle_irq (irq=31, regs=<value optimized out>) at include/linux/irqdesc.h:114 #15 asm_do_IRQ (irq=31, regs=<value optimized out>) at arch/arm/kernel/irq.c:90 #16 0xc002bb34 in __irq_svc () at arch/arm/kernel/entry-armv.S:42

Caso nao tenha obtido o trace acima, basta colocar breakpoints nas rotinas intermediárias. Toda rotina de interrupcao associada a um driver deve ser registrada. Temos uma sequencia de drivers usando outros drivers, mas a primeira interrupcao do primeiro driver foi amba_kmi_int (subindo da interrupcao de baixo para cima). Fazendo uma busca em sua declaracao, ~/Downloads/linux-2.6.39/drivers$ grep -r amba_kmi_int * input/serio/ambakmi.c:static irqreturn_t amba_kmi_int(int irq, void *dev_id) input/serio/ambakmi.c: ret = request_irq(kmi->irq, amba_kmi_int, 0, "kmi-pl050", kmi);

O registro dessa interrupcao, eh feito por amba_kmi_open. Para ver sobre amba kmi: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0447j/Cfhhieif.html

Quando ocorre a interrupcao de hardware, eh necessário saber quem gerou a interrupcao: teclado, timer, mouse, etc. Localize isso no código. Uma vez localizado o hardware, eh necessário passar o tratamento da interrupçao para o driver adequado. Ver amba_kmi_int. Localize isso no código. O caracter (ou caracteres) teclado é lido de algum port. Na verdade, se lê a posição da tecla. Localize isso no código. O que faz readb(KMIDATA)? O código lido deve ser guardado em um buffer enquanto o usuario nao tecla ENTER. Localize isso no código. A função __wake_up acorda o processo que lia da tty (dentro do kernel). Localize isso no código. Explique melhor o que faz __wake_up. Localize isso no código.

Quando o usuário tecla ENTER, o processamento é diferente: os dados devem ser transferidos para o buffer de usuário. Localize isso no código.

> 7.5 ; Rafael Ribeiro, Guilherme Ryu 6.5 . Nao vasculharam (atraves de breakpoints, leitura do codigo, pesquisa google, etc.) onde o escalonador eh chamado quando nao se tecla nada (eh no line discipline driver ao fazer exclusao mutua). rel ok

8.4 10 Linux - escalonador de I/O

Rode o seguinte programa: #include <stdio.h>

void main() { int c; int pid;

printf("Hello World!\n"); fork(); fork(); fork();

pid = getpid(); printf("rodando com pid %d \n", pid);

while(1) { pid = getpid(); printf("pid %d \n", pid); c = getchar(); printf ("teclou %d \n", c); };

}

No versatile emulado, crie um init que rode o código acima. Os processos ficam bloqueados esperando com que o usuario tecle algo. Eles sao colocados numa fila. Localize isso no código. O que acontece quando o usuário tecla algo seguido de ENTER? Um processo passa a rodar ou todos passam a rodar? Localize isso no código. Experimente em um linux normal e também na placa versatile emulada. No meu caso, no linux normal, apenas um processo aleatoriamente recebe os caracteres. Coloque um breakpoint quando o processo sai da fila de espera do teclado e é acordado (__wake_up). Modifique o kernel para que imprima essa fila de espera pelo teclado toda vez que o processo é adicionado na wait queue (add_wait_queue) que espera caracteres teclados. É possível se prever qual processo será acordado?

> 7.5 faltou vasculhar os drivers - teclado -> line discipline -> tty - o add_wait_queue do teclado apenas coloca um processo bloqueado, mas no line discipline temos os outros processos bloqueados no mutex. rel ok.

Ideias:

driver usando udev. (dah para fazer? talvez sim, mas nao sei como).

fazer o que o shibata fez para outra placa suportada pelo qemu - temos um monte delas.

8.5 - fazer alguma conexao do qemu com a usb em pendrive. Seria possivel colocar um pendrive real em uma placa versatile emulada?

Study the differences among devtmpfs, udev and dev. Remake the Shibata's work creating the device driver using udev instead of devtmpfs.

Seria legal poder criar um botao e um led que sao ligados com o qemu.

8.6 systemtap - uso de um driver.

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. O systemtap roda melhor no centos.

> 8 centos 7 rel ok

8.7 systemtap - tempo em modo usuario e em modo kernel.

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. Faca testes atribuindo uma ou duas cpus aa maquina virtual. Rode no centos.

> 8.5 interessante rodando 2 processos i/o bound e 2 processos cpu bound em 2 cores - o linux estah equilibrando os processos em ambas as cpus. rel ok.

8.8 Linux - construir o driver padrao no arm linux.

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.

> 8.5, rel ok.

8.9 - varios processos ficam bloqueados no dispositvo "blocking device" aguardando que o dispositivo recebe dados. Externar em /sys os processos bloqueados em "blocking device".

8.10 - enquanto alguem segura alguma tecla, uma variavel em /sys informa que existe uma tecla sendo apertada.

8.11 clock - alterar a programacao do clock. Aumentando ou diminuindo o clock faz diferenca no tempo de resposta? Alterar de 2 formas - nos registradores e usar uma variavel para simular a interrupcao ocorrendo soh de 100 em 100 vezes, por exemplo

8.12 interrupcao - como o kernel faz o tratamento de IRQ e descobre quem interrompeu? Externa em /sys o ultimo periferico que fez IRQ.

8.13 - system call que mostra processos bloqueados aguardando que algo seja teclado.

http://www.linusakesson.net/programming/tty/

8.14 - alterar alguma coisa no driver do teclado. A tecla eh enviada quando se solta a tecla e nao quando aperta. Faca com que o driver nao fique repetindo a tecla presisonada enquanto nao soltah-la.

Table of Contents

1 Programação aula a aula.

1.1 <2018-05-07 Seg> ) 1.1 O que é um sistema operacional, 1.2 História dos sistemas operacionais

1.2 <2018-05-11 Sex> ) Visao do hardware

1.3 <2018-05-14 Seg> ) conceitos de sistema operacional; 1.4 chamadas de sistema

1.4 <2018-05-18 Sex> ) 1.4 chamadas de sistema 1.5 estrutra do sistema operacional.

1.5 <2018-05-21 Seg> ) => apresentação dos projetos (fase 1) : grupos ímpares

1.6 <2018-05-25 Sex> ) - apresentação dos projetos (fase 1) : grupos pares

1.7 <2018-05-28 Seg> ) sem aula problma greve caminhoneiro

1.8 <2018-06-01 Sex> -> feriado

1.9 <2018-06-04 Seg> ) 2.2 comunicação interprocesso até solucao de peterson

1.10 <2018-06-08 Sex> ) 2.2 comunicacao inter processos - comeco de 2.3

1.11 <2018-06-11 Seg> ) 2.3 problemas clássicos de CIP 2.4 agendamento de processo + problema reader/writer.

1.12 <2018-06-15 Sex> ) => Projetos 2.5 visão geral de processos em minix (fase 2)

1.13 <2018-06-18 Seg> ) => Projetos 2.5 visão geral de processos em minix (fase 2)

1.14 <2018-06-22 Sex> ) jogo brasil x costa rica

1.15 <2018-06-25 Seg> ) prova 1

1.16 <2018-06-29 Sex> ) 3.1 Hardware Entrada e Saida 3.2 Software Entrada e Saida 3.2 Software Entrada e Saida

1.17 <2018-07-02 Seg> ) 3.3 impasses

1.18 <2018-07-06 Sex> ) 4.1 gerenciamento básico de memória 4.2 troca (swap)

1.19 <2018-07-09 Seg> -> feriado

1.20 <2018-07-13 Sex> ) => Projetos 3.4 visão geral de E/S no minix (fase 3)

1.21 <2018-07-16 Seg> ) => Projetos 3.4 visão geral de E/S no minix (fase 3)

1.22 <2018-07-20 Sex> ) 4.3 memória virtual, 4.4 algoritmos de substituição de página.

1.23 <2018-07-27 Sex> ) 4.4, 4.5 questões para sistemas de paginação.

1.24 <2018-07-30 Seg> ) 4.6 segmentação

1.25 <2018-08-03 Sex> ) => Projetos 4.7 visão geral do gerenciamento de memória do minix (fase 4)

1.26 <2018-08-06 Seg> ) => Projetos 4.7 visão geral do gerenciamento de memória do minix (fase 4)

1.27 <2018-08-10 Sex> ) 5.1 arquivos 5.2 diretórios 5.3 implementação do sistema de arquivos

1.28 <2018-08-13 Seg> ) prova 2

2 Livro texto:

3 Criterio de Avaliação:

4 Grupos para os projetos.

5 Criterios de avaliacao.

6 Fase 1:

7 Fase 2

8 Fase 3

8.1 4 Linux - teclado

8.2 6 Rode o seguinte programa como init:

8.3 9 Rode o seguinte programa como init:

8.4 10 Linux - escalonador de I/O

8.5 - fazer alguma conexao do qemu com a usb em pendrive. Seria possivel colocar um pendrive real em uma placa versatile emulada?

8.6 systemtap - uso de um driver.

8.7 systemtap - tempo em modo usuario e em modo kernel.

8.8 Linux - construir o driver padrao no arm linux.

8.9 - varios processos ficam bloqueados no dispositvo "blocking device" aguardando que o dispositivo recebe dados. Externar em /sys os processos bloqueados em "blocking device".

8.10 - enquanto alguem segura alguma tecla, uma variavel em /sys informa que existe uma tecla sendo apertada.

8.11 clock - alterar a programacao do clock. Aumentando ou diminuindo o clock faz diferenca no tempo de resposta? Alterar de 2 formas - nos registradores e usar uma variavel para simular a interrupcao ocorrendo soh de 100 em 100 vezes, por exemplo

8.12 interrupcao - como o kernel faz o tratamento de IRQ e descobre quem interrompeu? Externa em /sys o ultimo periferico que fez IRQ.

8.13 - system call que mostra processos bloqueados aguardando que algo seja teclado.

8.14 - alterar alguma coisa no driver do teclado. A tecla eh enviada quando se solta a tecla e nao quando aperta. Faca com que o driver nao fique repetindo a tecla presisonada enquanto nao soltah-la.

8.15 - fazer com que a repeticao da tecla seja o dobro mais lenta.