Sistemas Operativos 2ª parte

Sistemas Operativos 2ª parte Prof. José Rogado jrogado@ulusofona.pt Prof. Pedro Gama pedrogama@gmail.com Universidade Lusófona Adaptação e Notas para LIG Dr. Adriano Couto 1

Serviços e Arquitectura do Sistema Operativo Serviços do Sistema Operativo Interfaces Utilizador System Calls Tipos de System Calls Programas Sistema Design Genérico do Sistema Operativo Arquitectura de Sistemas Operativos Máquinas Virtuais Objectivos Descrever os serviços que o SO fornece aos utilizadores, aplicações e outros sistemas Evidenciar que a interface oferecida ao Utilizador não define o sistema operativo Perceber a importância do hardware na implementação do SO Apresentar as várias arquitecturas de um sistema operativo 2.2 Silberschatz, Galvin and Gagne 2005 2

Serviços do Sistema Operativo Os serviços mais evidentes do SO são as funções directamente relacionadas com o utilizador: Interface Utilizador quase todos os SOs fornecem um tipo de UI) Command-Line Interpreter (CLI) Graphics User Interface (GUI) Batch Execução de programas o sistema carrega um programa em memória, executa-o e termina-o, reportando eventuais erros. Operações de I/O - Um programa em execução requer operações de I/O relativamente a ficheiros ou periféricos. Operações relativas ao Sistema de Ficheiros a grande maioria de operações das aplicações têm a ver com ficheiros: ler, escrever, apagar, mover directórios listar, procurar, gestão de acessos 2.3 Silberschatz, Galvin and Gagne 2005 Note-se que a interface exposta ao utlizador, não é geralmente o sistema operativo. Por exemplo a interface de linha de comando é assegurado por uma aplicação, como qq outra que está a ser executada pelo SO. Na versão de fábrica do Windows, essa interface é o cmd.exe (erroneamente chmaada, por vezes, DOS por ter um aspecto semelhante ao antigo SO da Microsoft. No UNIX esse tipo de programas de Interface chama-se shell. Várias shells populares em UNIX existem tb em Windows com as mesmas funcionalidades, para substituição da cmd.exe. Num sustema operativo o IO é sempre efectuado por intermédio dos Sistema Operativo. As aplicação não tem capacidade de efectuar IO por si. O acesso ao Sistema de ficheiros tb é sempre mediado pelo SO. A interface gráfica pode ou não ser parte do SO. No Windows é, nos UNIX não é. 3

Serviços do Sistema Operativo (Cont.) Comunicações troca e/ou partilha de dados entre aplicações residentes no mesmo computador ou em computadores ligados por rede Podem ser feitas por memória partilhada ou através de mensagens (pacotes movimentados pelo SO através de protocolos) Detecção de Erros o SO tem de estar constantemente a par de todos os erros, a tentar reportá-los ou mesmo corrigi-los. Podem ocorrer no CPU ou na memória, periféricos ou na maioria dos casos, em programas utilizador Para cada tipo de erro, o SO toma a acção apropriada para garantir a continuidade da execução do sistema como um todo Facilidades de debug podem aumentar as capacidades dos utilizadores o programadores utilizarem o sistema correctamente 2.4 Silberschatz, Galvin and Gagne 2005 A comunicação com aplicações noutro computador implica IO, logo é mediada pelo SO A comunicação entre aplicações na mesma máquina também é mediada pelo SO 4

Serviços do Sistema Operativo (Cont.) Outras funcionalidades do SO providenciam a operacionalidade, eficiência e robustez do sistema e dos recursos geridos. Alocação de recursos quando múltiplos utilizadores ou processos estão a utilizar o mesmo sistema simultaneamente Tipos de Recursos CPU, Memória e Armazenamento: algoritmos específicos Periféricos: controle dos pedidos e o seu encadeamento Accounting/Logging Guardar historial das acções dos utilizadores e da utilização que fizeram dos recursos dos sistema Protecção e Segurança Garantir que a informação que existe ou transita num sistema multiutilizador e ligado em rede não é acedida ou modificada por quem não deve. A Protecção implica que todos os acesso a recursos geridos pelo sistema são controlados Segurança implica que a utilização do sistema por quaisquer entidades envolve uma autenticação prévia e pode implicar armazenar ou transferir dados de forma cifrada Para que um sistema seja protegido e seguro, deve haver uma coerência entre as precauções tomadas. Noção do elo mais fraco de uma cadeia 2.5 Silberschatz, Galvin and Gagne 2005 5

Interface Utilizador - CLI Command Line Interpreter permite a execução directa de comandos A implementação pode ser realizada no kernel ou num programa sistema Podem ter inúmeras variantes Os mais conhecidos são os shells Princípio: lêem um comando da consola do utilizador e executam a acção correspondente Os comandos podem fazer parte do próprio interpretador Ou podem ser realizados em programas separados Neste último caso adicionar novos comandos não requer a modificação do interpretador É o caso do shell Unix e a cmd.exe do Windows 2.6 Silberschatz, Galvin and Gagne 2005 6

Windows CLI cmd.exe 2.7 Silberschatz, Galvin and Gagne 2005 Podem ser instaladas no Windows algumas das shells populares em UNIX, como a bash. A Microsoft oferece a Powershell como alternativa, mais poderosa, ao cmd.exe 7

Unix CLI bash 2.8 Silberschatz, Galvin and Gagne 2005 8

Graphical User Interface Interface Utilizador - GUI Mais intuitiva e com maior grau de usabilidade Tornou o computador utilizável pelo público em geral É uma interface mais adaptada aos computadores de uso pessoal Utiliza um rato, um teclado e um monitor com sistema de janelas Icons representam ficheiros, programas e acções A movimentação do rato e acção dos botões podem ser programadas de acordo com o look and feel das aplicações Obter informação, escolher opções, executar comandos, abrir directórios ou pastas Criada na Xerox PARC cerca em 1973 Generalizada com os Apple McIntosh A maioria dos sistemas actuais inclui interfaces CLI e GUI Microsoft Windows é um GUI com CLI command shell Apple Mac OS X usa o Aqua GUI interface por cima de um kernel UNIX, com vários shells disponíveis Linux e Solaris têm um CLI com interfaces GUI opcionais (Java Desktop, KDE) 2.9 Silberschatz, Galvin and Gagne 2005 9

Linux KDE 2.10 Silberschatz, Galvin and Gagne 2005 10

System Calls Interface de programação fornecida pelo SO Normalmente escrita em linguagem de alto nível (C, C++ ou Java) Normalmente as aplicações utilizam uma Application Program Interface (API) que encapsula o acesso directo aos system calls As APIs mais utilizadas são a Win32 API para Windows, a POSIX API para praticamente todas as versões de UNIX, e a Java API para a Java Virtual Machine (JVM). Motivos para utilizar APIs em vez dos system calls directamente Portabilidade independência da plataforma Esconder complexidade inerente aos system calls Acréscimo de funcionalidades que optimizam o desempenho O acesso aos system calls está implementada em bibliotecas que são carregadas com as aplicações 2.11 Silberschatz, Galvin and Gagne 2005 As chamada de sistema são as primitivas oferecidas para a programação de interfaces (CLI ou GUI) e aplicações. Elas definem a indentidade e personalidade do Sistema Operativo: aquilo que ele é capaz de fazer e como o faz. A unitilização das API para encapsular as System Calls permitre um grau adicional de indireção que permite a implementação da mesma API sobre outros Sistema Operativos. Por exemplo as bibliotecas MingW e CygWin implementam a maior parte das chamada de sistema do UNIX em Windows e assim permitee compilar aplicações, escritas para UNIX nos SO da Microsoft. Por outro lado, a API Windows pode ser implementada sobre outrro systema operativo: por exemplo o projecto WINE Implementa-a sobre Linux, o que permite correr aplicações Windows. No Windows a systems call não estão definidas e publicadas pela Microsoft. Está apenas disponível a API, designada por Win32 API. 11

Exemplo de Utilização Sequencia de System Calls para copiar o conteúdo de um ficheiro para outro 2.12 Silberschatz, Galvin and Gagne 2005 Pretende evidenciar como uma funcionalidade mais complexa como copiar um Ficheiro é efectuada à custa das primitivas efectivamente implementadas pelo SO 12

Exemplo da API - Windows Standard A função ReadFile() da Win32 API Uma função para ler o conteúdo de um ficheiro Descrição dos parâmetros de ReadFile() HANDLE file - the file to be read LPVOID buffer - a buffer where the data will be read into and written from DWORD bytestoread - the number of bytes to be read into the buffer LPDWORD bytesread - the number of bytes read during the last read LPOVERLAPPED ovl - indicates if overlapped I/O is being used 2.13 Silberschatz, Galvin and Gagne 2005 O objectivo é evidenciar que as primitivas/chamadas básicas, existem em todos os sistemas operativos, podendo todavia ter nomes e funcionalidades ligeiramente diferentes. 13

Exemplo da API UNIX Standard 2.14 Silberschatz, Galvin and Gagne 2005 14

Implementação dos System Calls A cada system call está associado um número A interface mantém uma tabela com o endereço de cada system call handler que é indexada pelo número do system call Através desta tabela, o respectivo handler é invocado no kernel Os parâmetros do system call são transferidos para o kernel Uma vez executado, o resultado e os parâmetros de retorno são transferidos para o programa utilizador, como se tivesse havido uma invocação de uma função normal A aplicação que invoca o system call não precisa de saber como este é implementado Só precisa de obedecer à sintaxe da API (assinatura do método) e estar à espera dos resultados da invocação Precisa de conhecer o comportamento associado ao system call Os detalhes da interface sistema são escondidos pela API São geridos pela biblioteca de run-time camada de funções de biblioteca que são incluídas na aplicação quando da compilação e carregamento do ficheiro executável 2.15 Silberschatz, Galvin and Gagne 2005 A implementação da system call como um offset numa tabela é específica dos UNIX. Em qualquer sistema a especificação das primitivas dos sistema e a sintaxe da API, Permitem que a implementação destas no interior do SO seja abstraída. Os programadores não preecisam de saber a implementação (que no caso Windows, não é de todo publicada) e assim ficam também imunes a alterações na implementação, que acontecem naturalmente com a evolução do SO. 15

API System Call OS Relationship 2.16 Silberschatz, Galvin and Gagne 2005 A implementação das cahamadas do sistema é feita num modo especial de execução Do CPU. Este é um modo priviligiado que permite todas as instruções do CPU. O código das aplicações é não priviligiado e produz um erro sempre que certas instruções (or exemplo de IO) são efectuadas. Este erro é tradado pelo SO que pode providenciar uma emulação ou simplesmente parar a aplicação. As system calls efectuam instruções especiais dos CPU para efectuar a transição. 16

Transição para os Syscalls em Linux 2.17 Silberschatz, Galvin and Gagne 2005 17

Linux System Calls Numbers /usr/src/linux/include/asm-i386/unistd.h 2.18 Silberschatz, Galvin and Gagne 2005 Nos UNIX as chamadas de sistema estão perfeitamente enumeradas. No Windows não é o caso e existem chamadas de sistema não documentadas o que é objecto de lítiio legal entra a Microsoft e diversas autoridades anti-monopólio. 18

Linux Syscall Table /usr/src/linux/arch/i386/kernel/entry.s 2.19 Silberschatz, Galvin and Gagne 2005 Pormenor de implemantação só para ilustração. 19

Invocação Directa de Syscalls Programa em Assembler que invoca os system calls write() e exit() através da instrução int 0x80 2.20 Silberschatz, Galvin and Gagne 2005 Pormenor de implemantação só para ilustração. O objectivo é mostrar que a chamada pode ser efectuada sem recursos à biblioteca que contém a API. Isto só é válido nos UNIX. Repare-se na instrução int que permite a comutação entre os dois modos de execução. 20

Utilização de sysentry/sysexit sysexit Na arquitectura Intel a partir do Pentium II, duas novas instruções permitem a realização de system calls mais rapidamente sysentry permite a entrada no sistema sem passar por uma interrupção software sysexit permite a saída do kernel pelo mesmo mecanismo O kernel linux utiliza estas instruções preferencialmente a partir da versão 2.6 A invocação destas instruções faz-se pela invocação directa de código assembler colocado pelo kernel numa página específica de todos os processos (virtual dynamic shared object - vdso) O ponto de entrada é designado por kernel_vsyscall Endereço pode variar por distribuição e formato executável Ver referência http://manugarg.googlepages.com/systemcallinlinux2_6.html 2.21 Silberschatz, Galvin and Gagne 2005 Outra instrução para a comutação de modo. Meramenmte ilustrativo. A infoirmação a reter é esta: o acesso ao sistema operativo requer sempre a comutação de modo efectuada com recursos a instruções especiais do hardware. O objectivo é permitir a validação de todos os parâmetros recebidos por forma a evitar que o SO possa garantir que a aplicação não compromete o proprio sistema ou outras aplicações a correr. 21

Invocação através s da Libc Programa em C que invoca a função de biblioteca printf(), que por sua vez chama o system call write() 2.22 Silberschatz, Galvin and Gagne 2005 A libc é portanto apenas um encapsulamento das chamadas de sistema. Poderá ser usado para portar uma aplicação para outro SO sem alteração. Na libc são efectuadas as chamadas adequadas de cada SO. Apesar do nome estar relacionada com a linguagem C, esta biblioteca é de utilização universal em UNIX, e muito utilizada também em Windows. 22

Passagem de Parâmetros nos System Call É necessário trocar mais informação do que a identificação do system call Parâmetros de entrada e saída O tipo exacto e quantidade de parâmetros a passar e receber varia com o SC e o OS Três métodos genéricos são utilizados para passar os parâmetros para o SO Mais simples: passar os parâmetros nos registos do processador Em alguns casos pode haver mais parâmetros do que regs. Os parâmetros são guardados num bloco ou tabela em memória e o endereço do bloco é passado como parâmetro num registo Método seguido no Linux e Solaris Os parâmetros podem ser empurrados (pushed) para a pilha pela aplicação, e puxados (popped) pelo SO Estes dois últimos métodos não limitam o número e comprimento dos parâmetros passados Sempre que há passagem de dados por referência estes têm de ser copiados para o kernel (in) ou para o processo utilizador (out) Caso das operações de I/O que realizam transferências de dados importantes (leitura ou escritura de ficheiros ou rede) 2.23 Silberschatz, Galvin and Gagne 2005 O objectivo é ilustrar que a passagem de parâmetros é uma procupação de segurança do SO. Tem que se garantir que o SO inspeciona todos os parâmetros recebidos antes de proceder à exeução. As referidas instruções de hadrware (int s ou traps) são genéricas, independentes do número de parâmetros inerentes a cada chamada. 23

Passagem de Parâmetros por Referência 2.24 Silberschatz, Galvin and Gagne 2005 24

Passagem de Parâmetros em Linux Na arquitectura Intel, os parâmetros são passados nos registos Registo eax contém o número do syscall Registos ebx, ecx, edx, esi e edi contêm os primeiros 5 argumentos No caso de haver mais, são passados por referência, sendo o endereço da sua localização passado por registo. O valor de retorno do syscall é enviado através do registo eax. Todos os argumentos passados para o kernel têm de ser validados por este Evitar utilização de recursos não autorizados ou não existentes Evitar acessos a zonas de memória não pertencentes ao espaço de endereçamento do processo Evitar acessos indevidos a seu próprio espaço P.ex.: escrever em zonas read only Os argumentos são copiados por funções em C e Assembly http://lxr.linux.no/source/arch/i386/lib/usercopy.c 2.25 Silberschatz, Galvin and Gagne 2005 Ilustrativo. Mostra o problema da passagem de parametros no interrupt (int) ou trap 25

Tipos de System Calls Controle de Processos fork(), exec(), wait(), exit(), kill(), Gestão de Ficheiros open(), creat(), read(), write(), seek(), Gestão de Periféricos mount(), umount(), ioctl(), read(), write(), Informação e manutenção stat(), time(), getattr(), setattr(), Comunicações socket(), bind(), connect(), send(), receive(), Debug ptrace() 2.26 Silberschatz, Galvin and Gagne 2005 O objectivo é mostrar as operação que têm sempre que ser mediadas pelo SO. 26

Referências de Código C do Kernel Para aprofundar estes conceitos aconselha-se o estudo de algumas partes do código do kernel: Definição dos números de System Calls http://lxr.linux.no/linux+v2.6.27/include/asm-x86/unistd_32.h Tabela de System Calls http://lxr.linux.no/linux+v2.6.27/arch/x86/kernel/syscall_table_32.s Pontos de entrada no Kernel int $80 -> system_call http://lxr.linux.no/linux+v2.6.27/arch/x86/ia32/ia32entry.s#l400 sysentry http://lxr.linux.no/linux+v2.6.27/arch/x86/ia32/ia32entry.s#l110 vsyscall-int80 http://lxr.linux.no/linux-bk+v2.6.11.5/arch/i386/kernel/vsyscall-int80.s vsyscall-sysenter http://lxr.linux.no/linux-bk+v2.6.11.5/arch/i386/kernel/vsyscall-sysenter.s Teste e cópia de argumentos dos System Calls (in/out) http://lxr.linux.no/linux+v2.6.27/arch/x86/lib/usercopy_32.c 2.27 Silberschatz, Galvin and Gagne 2005 27

Programas Sistema Os programas ou utilitários sistema fornecem um ambiente para A gestão do sistema O desenvolvimento e execução de programas Podem ser divididos em Gestão de Ficheiros Informação de Estado Modificação de Ficheiros Suporte de Linguagens de Programação Carregamento e Execução de Programas Comunicações Aplicações Genéricas A maioria dos utilizadores tem uma visão do Sistema Operativo definida pelos programas sistema e não pelos System Calls 2.28 Silberschatz, Galvin and Gagne 2005 Mostrar que a visão do utilizadores não define o SO que está por baixo. 28

Arquitectura e Implementação de SOs A arquitectura interna dos Sistemas Operativos pode variar bastante de uma versão para outra Para a definir deve-se começar por estabelecer os objectivos e as especificações Estes dependem fortemente dos objectivos e do tipo de hardware Diferentes pontos de vista: Utilizadores: deve ser de fácil compreensão e utilização, fiável, seguro e rápido Conceptores: deve ser fácil de desenhar, implementar e manter, deve ser flexível, fiável, eficiente e não ter erros (bugs) Muitas vezes estes pontos de vista não são fáceis de conciliar A funcionalidade, simplicidade e usabilidade são difíceis de conseguir simultaneamente É importante separar conceitos: Política: o que fazer? Mecanismo: como fazer? A separação garante flexibilidade em futuras mudanças 2.29 Silberschatz, Galvin and Gagne 2005 Referir alguns dos problemas no desenho e a razão porque há tantas variedades de SO 29

Arquitectura Simples: MS-DOS Concebido para fornecer o máximo de funcionalidades num mínimo de espaço Não é um sistema modular Não tem interfaces e níveis de funcionalidade bem definidos 2.30 Silberschatz, Galvin and Gagne 2005 Curiosidade 30

Arquitectura em Camadas O SO é dividido em várias camadas ou níveis, cada um construído em cima do anterior (ex: sistemas de Mainframes VMS, Multics) O nível mais baixo é o hardware O mais elevado é a interface utilizador O princípio da modularidade implica que os níveis sejam escolhidos de forma a que cada um só utilize serviços dos níveis inferiores 2.31 Silberschatz, Galvin and Gagne 2005 31

Arquitectura de tipo Unix O sistema Unix original era limitado pelas funcionalidades do hardware Minicomputador Digital PDP-11 de 16 bits e memória segmentada O sistema Unix é consistido por dois níveis distintos: Os programas sistema O núcleo (kernel) É consistido por toda a funcionalidade que está abaixo da interface dos system calls Fornece a gestão de processos, de memória e de ficheiros, os protocolos de rede, assim como as funções de mais baixo nível Muitas funcionalidades para um só nível Sistema pouco modular 2.32 Silberschatz, Galvin and Gagne 2005 32

Arquitectura do Sistema UNIX 2.33 Silberschatz, Galvin and Gagne 2005 Para ter uma noção da estrutura. A separação entre Kerner e programas aplicacionais é um conceito essencial! 33

Evolução da Arquitectura Unix Uma das evoluções mais radicais na arquitectura do sistema Unix foi realizada a partir de 1985 na Carneghie-Mellon University com o projecto Mach. O núcleo foi modificado a partir do sistema BSD, tendo as funções de mais baixo nível sido separadas num módulo designado por micro-núcleo Mach 2.5. Os serviços do sistema estão separados do núcleo através de uma interface de mensagens internas ao sistema Sistema de Ficheiros, Processos, Protocolos, etc.. Este projecto deu origem a uma nova geração de sistemas OSF/1 MK com núcleo Mach 3.0 => Digital Unix Mach OS/X 2.34 Silberschatz, Galvin and Gagne 2005 34

Arquitecturas de tipo Micro-Núcleo cleo O Sistema baseado em Mach 3.0 torna-se ainda mais modular Funcionalidades agrupadas em servidores Alguns serviços podem executar-se no espaço utilizador A comunicação entre módulos faz-se por mensagens 2.35 Silberschatz, Galvin and Gagne 2005 Perceber o conceito de micro-núcleo 35

Crítica da Arquitectura Micro-Núcleo cleo Benefícios: Mais fácil modificar e manter o micro-núcleo Mais fácil suportar novas arquitecturas hardware Todas as dependências estão concentradas no micro-núcleo Mais fiável e seguro Desvantagens: Menos código em modo supervisor Pior desempenho na comunicação entre serviços e entre estes e o núcleo Versões posteriores voltam a repor os servidores em modo supervisor Referências Mach 3.0 http://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html Chorus OS http://www.experimentalstuff.com/technologies/chorusos/index.html Micro-núcleo Minix 3 http://www.minix3.org/doc/herder.html 2.36 Silberschatz, Galvin and Gagne 2005 Perceber as vantagens e desvantagens. 36

Arquitectura Modular A maioria dos sistemas operativos modernos utilizam o conceito de módulo para implementar o núcleo Utilizam uma aproximação orientada aos objectos Cada componente fundamental é isolado Os módulos comunicam por interfaces bem definidas Os módulos podem ser carregados dinamicamente no núcleo Aproximação semelhante à das camadas mas mais flexível e dinâmica Ex: Sun Solaris 2.37 Silberschatz, Galvin and Gagne 2005 Referir mdulos no LINUX, carregados pelo Kernel à medida que são necessários. Discutir o interesse desta estratégia. 37

Noção de Máquina M Virtual A noção de máquina virtual leva o conceito das camadas até às últimas consequências Considera a camada do Sistema Operativo como um tipo de hardware com características específicas Uma máquina virtual fornece uma interface idêntica à do hardware que simula Os recursos do computador real são partilhados de forma a criar a noção de máquina virtual Ex: O sistema operativo cria a ilusão de que múltiplos sistemas operativos se estão a executar simultaneamente Cada um com o seu próprio processador e a sua memória virtual Um sistema baseado em máquina virtual é uma excelente plataforma para investigação e desenvolvimento de sistemas operativos O desenvolvimento é feito na máquina virtual, de forma a não interromper o funcionamento do sistema O primeiro OS com implementação de máquina virtual foi o IBM VM 2.38 Silberschatz, Galvin and Gagne 2005 A interface do SO é uma abstração que implementa um conjunto de operações de alto nível. A máquina virtual desce o grão desta abstração. 38

Máquina Virtual Non-virtual Machine Virtual Machine Virtual Machine Monitor (a) Sistema Normal (b) Máquina Virtual 2.39 Silberschatz, Galvin and Gagne 2005 39

Exemplo: Arquitectura VMware Hypervisor 2.40 Silberschatz, Galvin and Gagne 2005 Meramente Ilustrativo 40

Extensões de Suporte às s VM O conceito é difícil de implementar devido à dificuldade de simular o comportamento exacto da máquina real O que acontece quando o sistema operativo hóspede acede a instruções privilegiadas só executáveis em modo supervisor? Noção de VMM: Virtual Machine Monitor Hoje em dia os principais processadores (Intel, AMD) fornecem suporte à virtualização através de extensões hardware Intel Virtual Technology Extensions (VT-x ou VT-i) Novos níveis de privilégio Root para execução do VMM Non-root para execução das VMs A passagem de um contexto para outro (VM enter e VM exit) e são provocadas por certas instruções específicas Ver : www.intel.com/technology/itj/2006/v10i3/1-hardware/1-abstract.htm AMD: AMD-V ou SVM 2.41 Silberschatz, Galvin and Gagne 2005 Só ilustratrivo 41

A Máquina M Virtual Java Criação de uma abstracção de processador e Sistema Operativo As aplicações são compiladas para uma linguagem máquina virtual byte-code Uma máquina virtual Java interpreta o código máquina como se fosse um processador virtual A máquina Java é implementada em cima de um OS tradicional 2.42 Silberschatz, Galvin and Gagne 2005 Referir a máquina virtual DVD e as vantagens que apresenta para os programadores de conteúdos. 42

Referências Como complemento deste slides os alunos poderão consultar e estudar os elementos seguintes: Livro sobre programação em C e System Calls http://www.cs.cf.ac.uk/dave/c Informação sobre System Calls http://www.answers.com/topic/system-call-1 Instruções para recompilar o Kernel Linux http://www.linuxheadquarters.com/howto/tuning/kernelreasons.shtml É natural que surjam dúvidas, que podem ser esclarecidas nas aulas práticas ou contactando o professor da cadeira. 2.43 Silberschatz, Galvin and Gagne 2005 43

Fim da 2ª 2 Parte 44