ndice Hist rico do Linux... Ger ncia de Processos... 3.1- Considera es Iniciais...

1-2- 3-4- 5-4.1-4.2-4.3-4.4-4.5-4.6-4.7- Introdu o... Hist rico do Linux... Ger ncia de Processos... 3.1- Considera es Iniciais... 3.1.1- Inicializa o ( boot do sistema)... 3.2- Ger ncia do Processo pelo kernel... 3.3- Criando e Destruindo um Processo... 3.4- Executando Processos... Ger ncia de Mem ria... Gerenciamento de Mem ria do Linux... Mem ria F sica... Distribui o da Mem ria do Processo Usu rio... Inicializa o da Mem ria... Adquirindo e Liberando Mem ria... Pagina o (Paging)... Gerenciamento de Mem ria Cache... 4.7.1- Arquitetura de Mem ria Cache do Linux (Linux Flush Architecture)... 4.7.2- Implementa o de Mem ria Cache... 4.7.3- Arquitetura Baseada no SMP... 4.7.3.1- Arquitetura Baseada no contexto MMU/CACHE... 4.7.4- Conte do de uma Arquitetura Virtual... ndice ndice 4.7.5- Implica es Referentes a Arquitetura... 4.7.5.1- Arquitetura baseado no contexto SMP... 4.7.5.2- Arquitetura baseado no contexto MMU/CACHE... 4.7.6- Como tratar o que a Arquitetura flush n o executa com exemplos... 4.7.7- Quest es Abertas na Arquitetura Cache... Sistema de Arquivos do Linux (File System)... 5.1- Conceitos Fundamentais... 5.1.1- Arquivos... 5.1.2- Diret rios... 5.1.3- Conta... 5.1.4- Tipo de Arquivos... 5.1.5- Acesso a Arquivos... 5.1.6- Atributos dos Arquivos... 5.2- Opera es sobre Arquivos... 5.3- Arquivos Compartilhados... 5.4- Estrutura do Sistema de Arquivos Linux Realease 1.2... 5.4.1- Apresenta o... 5.4.2- Caracter sticas Sistema de Arquivos... 5.4.3- Composi o dos Diret rios... 5.4.3.1- Subdiret rio /bin... 6 8 10 10 10 12 13 13 15 15 16 17 18 19 22 23 3 24 2 27 27 28 28 29 9 30 31 31 31 31 32 32 33 33 34 35 36 36 36 38 39 1 2

5.4.3.2-5.4.3.3-5.4.3.4-5.4.3.5-5.4.3.6-5.4.3.7-5.4.3.8-5.4.3.9-5.4.3.10-5.4.3.11-5.4.3.12-5.4.3.13-5.4.3.1.1- Arquivos e/ou Comandos dispon veis em /bin... ndice Subdiret rio /boot... Subdiret rio /dev... Subdiret rio /etc... 5.4.3.4.1- Arquivos e/ou Comandos dispon veis em /etc... Subdiret rio /home... Subdiret rio /lib... Subdiret rio /mnt... Subdiret rio /proc... Subdiret rio /root (opcional)... Subdiret rio /sbin... 5.4.3.10.1- Arquivos e/ou Comandos dispon veis em /sbin... 5.4.3.10.2- Arquivos e/ou Comandos opcionais em /sbin... Subdiret rio /tmp... A hier rquia /usr... 5.4.3.12.1- Subdiret rio /usr (permanente)... 5.4.3.12.2- Subdiret rio /usr/x386... 5.4.3.12.3- Subdiret rio /usr/bin... 5.4.3.12.4- Subdiret rio /usr/dict... 5.4.3.12.5- Subdiret rio /usr/etc... 5.4.3.12.6- Subdiret rio /usr/include... 5.4.3.12.7- Subdiret rio /usr/lib... ndice 5.4.3.12.8- Subdiret rio /usr/local... 5.4.3.12.9- Subdiret rio /usr/man... 5.4.3.12.10- Subdiret rio /usr/bin... 5.4.3.12.11- Subdiret rio /usr/share... 5.4.3.12.12- Subdiret rio /usr/src... A hier rquia /var... 5.4.3.13.1- Subdiret rio /var/adm... 5.4.3.13.2- Subdiret rio /var/catman... 5.4.3.13.3- Subdiret rio /var/lib... 5.4.3.13.4- Subdiret rio /var/local... 5.4.3.13.5- Subdiret rio /var/ock... 5.4.3.13.6- Subdiret rio /var/og... 5.4.3.13.7- Subdiret rio /var/name... 5.4.3.13.8- Subdiret rio /var/nis... 5.4.3.13.9- Subdiret rio /var/preview... 5.4.3.13.10- Subdiret rio /var/run... 5.4.3.13.11- Subdiret rio /var/spool... 39 40 40 41 41 42 42 43 43 43 44 44 45 45 45 46 47 47 47 47 48 49 50 50 52 53 54 54 54 55 56 56 57 57 58 58 58 58 58 2 2

6-7- 9-8- 5.4.3.13.12- Subdiret rio /var/tmp... 5.4.4- Alguns Dilemas sobre o Sistema de Arquivos... 5.4.5- Descri o sucinta do conte do dos manuais... Pontos Positivos e Negativos... Conclus o... ndice Ap ndices... A- Comandos B sicos do Sistema Unix... B- Perguntas mais Frequentes (FAQs) colocadas na Linux-BR... C- Copyrights Linux e Esquema de numera o vers o Linux... D- Contrato de Licen a... Bibliografia e Refer ncias... 59 59 61 63 64 65 65 77 127 128 134 3 2

1 - Introdu o O Linux um clone UNIX de distribui o livre para PCs baseados em processadores 386/486/Pentium. O Linux uma implementa o independente da especifica o POSIX, com a qual todas as vers es do UNIX padr o (true UNIX) est o convencionadas. O Linux foi primeiramente desenvolvido para PCs baseados em 386/486/Pentium, mas atualmente tamb m roda em computadores Alpha da DEC, Sparcs da SUN, m quinas M68000 (semelhantes a Atari e Amiga), MIPS e PowerPCs. O Linux foi escrito inteiramente do nada, n o h c digo propriet rio em seu interior. O Linux est dispon vel na forma de c digo objeto, bem como em c digo fonte. O Linux pode ser livremente distribu do nos termos da GNU General Public License (veja ap ndice). O Linux possui todos as caracter sticas que voc pode esperar de um UNIX moderno, incluindo: Multitarefa real Mem ria virtual Biblioteca compartilhada "Demand loading" Gerenciamento de mem ria pr prio Execut veis "copy-on-write" compartilhados Rede TCP/IP (incluindo SLIP/PPP/ISDN) X Windows A maioria dos programas rodando em Linux s o freeware gen ricos para UNIX, muitos provenientes do projeto GNU. Muitas pessoas tem executado benchmarks em sistemas Linux rodando em 80486, e tem achado o Linux compar vel com workstations m dias da Sun e da Digital. O Linux est dispon vel atrav s da Internet por meio de centenas de sites FTP. O Linux est sendo usado hoje em dia por centenas e centenas de pessoas pelo mundo. Est sendo usado para desenvolvimento de softwares, networking (intra-office e Internet), e como plataforma de usu rio final. O Linux tem se tornado uma alternativa efetiva de custo em rela o aos caros sistemas UNIX existentes. Um exemplo de pacote de distrribui o do Linux mais populares distribuido pela InfoMagic (http://www.infomagic.com, e-mail info@infomagic.com), a vers o LINUX Developer 's Resource CD-ROM, de dezembro de 1996, cont m 6 CD-ROMs, seu conte do sucinto : Vers o Red Hat 4.0 (instalando kernel 2.0.18) Vers o Slackware 3.1 (Slackware 96 - instalando kernel 2.0) Vers o Debian GNU/Linux 1.2 X-Windows - Xfree86 version 3.2 Arquivos Linux de tsx-11.mit.edu e sunsite.unc.edu Arquivos GNU de prep.ai.mit.edu Documneta o completa on-line & HOWTO 's (Guia de Instala o e Guia do Administrador da Rede, em ingl s) Softwares demostra o comerciais como : BRU, dbman, StarOffice, Cockpit, Flagship, Smartware, GP Modula-2, Pathfinder, Scriptum, etc. 4 2

2. Historia do Linux O Kernel do Linux foi, originalmente, escrito por Linus Torvalds do Departamento de Ci ncia da Computa o da Universidades de Helsinki, Finl ndia, com a ajuda de v rios programadores volunt rios atrav s da Internet. Linus Torvalds iniciou cortando (hacking) o kernel como um projeto particular, inspirado em seu interesse no Minix, um pequeno sistema UNIX desenvolvido por Andy Tannenbaum. Ele se limitou a criar, em suas pr prias palavras, "um Minix melhor que o Minix" ("a better Minix than Minix"). E depois de algum tempo de trabalho em seu projeto, sozinho, ele enviou a seguinte mensagem para comp.os.minix: Voc suspira por melhores dias do Minix-1.1, quando homens ser o homens e escrever o seus pr prios "device drivers"? Voc est sem um bom projeto e esta morrendo por colocar as m os em um S.O. no qual voc possa modificar de acordo com suas necessidades? Voc est achando frustrante quando tudo trabalha em Minix? Chega de atravessar noites para obter programas que trabalhem correto? Ent o esta mensagem pode ser exatamente para voc. Como eu mencionei a um m s atr s, estou trabalhando em uma vers o independente de um S.O. similar ao Minix para computadores AT-386. Ele est, finalmente, pr ximo do est gio em que poder ser utilizado (embora possa n o ser o que voc esteja esperando), e eu estou disposto a colocar os fontes para ampla distribui o. Ele est na vers o 0.02... contudo eu tive sucesso rodando bash, gcc, gnu-make, gnu-sed, compress o, etc. nele. No dia 5 de outubro de 1991 Linus Torvalds anunciou a primeira vers o "oficial" do Linux, vers o 0.02. Desde ent o muitos programadores t m respondido ao seu chamado, e t m ajudado a fazer do Linux o Sistema Operacional que hoje. Ultimas vers es do kernel do Linux Release v1.0 1.0.9 Data: Sat Apr 16 21:18:02 UTC 1994 Release v1.1 1.1.95 Data: Thu Mar 2 07:47:10 UTC 1995 Release v1.2 1.2.13 Data: Wed Aug 2 12:54:12 UTC 1995 Release v1.3 pre2.0.14 Data: Thu Jun 6 19:30:56 UTC 1996 5 2

Release v2.0 2.0.28 Data: Tue Jan 14 12:33:26 UTC 1997 ftp://ftp.cs.helsinki.fi/pub/software/linux/kernel/v2.0/linux-2.0.28.tar.gz Release v2.1 2.1.23 Data: Sun Jan 26 14:12:18 UTC 1997 ftp://ftp.cs.helsinki.fi/pub/software/linux/kernel/v2.1/linux-2.1.23.tar.gz 6 2

3 - Ger ncia de Processos 3.1 - Considera es Iniciais Para explicarmos como o Linux ger ncia processos, faremos considera es iniciais sobre o c digo fonte do kernel do Linux (onde encontramos a implementa o da Ger ncia de Processos) e a inicializa o boot do sistema. Neste t pico tentaremos explicar, de uma maneira ordenada o c digo fonte do Linux, tentando conseguir um bom entendimento sobre como o c digo fonte est situado e como as caracter sticas mais relevantes do UNIX foram implementadas. O objetivo ajuda-lo a se familiarizar com o projeto geral do Linux. Ent o, vamos come ar por onde o Linux come a: seu sistema de boot. Um bom entendimento da linguagem C necess rio para entender este material, assim como familiaridade com conceitos de UNIX e arquitetura dos PCs. Por m, nenhum c digo C aparecer neste material, mas referencias de onde podem ser encontrados. Qualquer referencia "pathname" arquivos tem como ponto de partida a arvore principal de fontes, usualmente /usr/src/linux. A maioria das informa es reportadas aqui tem como referencia o c digo fonte do Linux vers o 1.0. Referencias a vers es posteriores conter o o s mbolo novo. Caso o s mbolo n o estiver presente, significa que n o houveram modifica es ap s as vers es 1.0.9-1.1.76. mais Ocasionalmente um par grafo como este ocorrer no texto. Indicando onde poderam ser obtidas mais informa es sobre o assunto corrente (geralmente o c digo fonte). 3.1.1 - Inicializa o ("boot" do sistema) Quando o PC ligado, o processador 80x86 encontra-se em modo real e executa o c digo contido no endere o 0xFFFF0, que corresponde a um endere o ROM-BIOS. O BIOS do PC realiza alguns testes no sistema e inicializa o vetor de interrup es no endere o f sico 0. Depois disto ele carrega o primeiro setor do device bootavel em 0x7C00, e passa a execu o para este endere o. O device, usualmente, o disquete ou o disco r gido. A descri o anterior um tanto simplificada, mas tudo que se necessita para entender o trabalho inicial do kernel. A primeir ssima parte do kernel Linux est escrito em linguagem assembly 8086 (boot/bootsect.s). Quando executado, ele se move para o endere o absoluto 0x90000, carrega os pr ximos 2 kbytes de c digo do device de boot at o endere o 0x90200, e o resto do kernel para o endere o 0x10000. A mensagem "Loading..." apresentada durante o carregamento do sistema. O controle, ent o passado para o c digo contido em boot/setup.s, outro c digo assembly de modo real. A parte de "setup" identifica algumas caracter sticas do sistema (hardware) e o tipo da placa VGA. Se requerido, pede ao usu rio para escolher o modo do v deo da console. E, ent o, move todo o sistema do endere o 0x10000 para o endere o 0x1000, passa para o modo protegido e passa o controle para o resto do sistema (endere o 0x1000). O pr ximo passo a descompress o do kernel. O c digo em 0x1000 vem de zboot/head.s que inicializa os registradores e invoca decompress_kernel(), o qual composto por zboot/inflate.c, zboot/unzip.c e zboot/misc.c. O dado "descompresso" vai para o endere o 0x100000 (1 Mega), e esta a principal raz o do por que o Linux n o pode rodar com menos de 2 Megas de RAM. 7 2

mais O encapsulamento do kernel em um arquivo gzip realizado por Makefile e utilit rios no diret rio zboot. S o arquivos interessantes para se dar uma olhada. novo A vers o 1.1.75 moveu os diret rios boot e zboot para arch/i386/boot. Esta modifica o pretendeu possibilitar a constru o de "kernel verdadeiro" para diferentes arquiteturas. O c digo "descompresso" executado a partir do endere o 0x1010000, onde todo o setup 32-bit esta lotado: IDT, GDT e LDT s o carregados, o processador e o co-processador s o identificados, a rotina start_kernel invocada. Os arquivos fonte das opera es acima est o em boot/head.s. Este, talvez, seja o c digo mais dif cil em todo o kernel do Linux. Note que se algum erro ocorrer durante alguns dos passos precedentes, o computador ir travar. O sistema operacional n o pode manipular erros enquanto n o estiver totalmente operante. start_kernel() reside em init/main.c. Tode de agora em diante esta codificado em linguagem C, exceto ger ncia de interrup es e chamadas de sistemas (Bem, a maior parte das macros possuem c digos assembly embutidos, tamb m). Depois dos procedimentos com todas as quest es iniciais, start_kernel() inicializa todas as partes do kernel, especificamente: Inicializa a mem ria e chama paging_init(). Inicializa os traps, canais IRQ e scheduling. Se requerido, aloja um profiling buffer. Inicializa todos device drives e buffers de discos, bem como outras partes menores. Regula o delay loop (calcula o numero "BogoMips"). Checa se a interrup o 16 est trabalhando com o co-processador. Finalmente, o kernel est pronto para move_to_user_mode(), em seguida fork (bifurca) o processo de inicializa o, cujos c digos est o no mesmo arquivo fonte. E o processo n mero 0, tamb m chamado idle task (tarefa pregui osa), se mant m rodando em um loop infinito. O processo de inicializa o tenta executar /etc/init, ou /bin/init, ou /sbin/init. Se nenhum deles tem sucesso, o c digo se desvia para "/bin/sh /etc/rc" e cria um root shell no primeiro terminal (console). Este c digo remanescente do Linux 0.01, quando o S.O. era feito para um kernel stand-alone, e n o havia processo de login. Depois de exec() o programa de inicializa o de um dos lugares padr o (deve haver um deles), o kernel n o tem controle direto sobre o fluxo do programa. Sua fun o, de agora em diante, prover processos atrav s de chamadas ao sistema (system calls), assim como prover eventos para servi os ass ncronos (como uma interrup o do hardware). A multitarefa est inicializada, e inicializar o gerenciamento de acesso a multiusu rios, atrav s do fork() e processos de login. Estando o kernel carregado e provendo servi o, vamos prosseguir dando uma olhada nesses servi os ("system calls"). 3.2 - Ger ncia de processo pelo kernel Do ponto de vista do kernel, um processo uma entrada na tabela de processos. Nada mais. A tabela de processos, ent o, uma das mais importantes estruturas de dados no sistema, conjuntamente com a tabela de gerenciamento de mem ria e o buffer cache. O item 8 2

individual na tabela de processos a estrutura task_struct, definida em include/linux/sched.h. Com a task_struct, tanto informa es de baixo quanto de alto n vel, s o mantidas - variando da c pia de alguns registradores de hardware at o inode do diret rio de trabalho para o processo. A tabela de processos tanto um array quanto uma lista duplamente ligada, como uma rvore. A implementa o f sica um array est tico de ponteiros, cujo tamanho NR_TASKS, uma constante definida em include/linux/tasks.h, e cada estrutura reside em uma pagina de mem ria reservada. A estrutura da lista est entre os ponteiros next_task e prev_task, a estrutura em arvore um tanto complexa, e n o ser descrita aqui. Voce pode desejar mudar NR_TASKS do seu valor default (que 128), mas esteja certo de que h depend ncias, e ser necess rio recompilar todos os arquivos fonte envolvidos. Depois do boot, o kernel est sempre trabalhando em um dos processos, e a vari vel global "current", um ponteiro para um item da task_struct, usado para guardar o processo que est rodando. A vari vel "current" s mudada pelo scheduler, em kernel/sched.c. Quando, por m, todos os processos necessitarem estar looked, a macro for_each_task usada. Isto consideravelmente mais r pido que uma procura seq encial no array. Um processo est sempre rodando em ou em "modo usu rio" ou em "modo kernel". O corpo principal de um programa de usu rio executado em modo usu rio e chamadas a sistema s o executados em modo kernel. A pilha usada pelos processos netes dois modos de execu o s o diferentes - um seguimento de pilha convencional usado para o modo usu rio, enquanto uma pilha de tamanho fixo (uma p gina, cujo processo dono) usada no modo kernel. A p gina de pilha para o modo kernel nunca swapped out, porque ela pode estar dispon vel sempre que um system call introduzido. Chamadas a sistema (System calls), no kernel do Linux, s o como fun es da linguagem C, seu nome "oficial" esta prefixado por "sys_". Uma chamada a sistema de nome, por exemplo, burnout invoca a fun o de kernel sys_burnout(). mais O mecanismo de chamadas a sistema (System calls) est descrito no cap tulo 3 do Linux Kernel Hackers' Guide (http://www.redhat.com:8080/hypernews/get/khg.html). Uma olhada em for_each_task e SET_LINKS, em include/linux/sched.h pode ajudar a entender a lista e a estrutura de rvore da tabela de processos. 9 2

3.3 - Criando e destruindo processos Um sistema UNIX cria um processo atrav s da chamada a sistema fork(), e o seu t rmino executado por exit(). A implementa o do Linux para eles reside em kernel/fork.c e kernel/exit.c. Executar o "Forking" f cil, fork.c curto e de f cil leitura. Sua principal tarefa suprir a estrutura de dados para o novo processo. Passos relevantes nesse processo s o: Criar uma p gina livre para dar suporte task_struct Encontrar um process slot livre (find_empty_process()) Criar uma outra p gina livre para o kernel_stack_page Copiar a LTD do processo pai para o processo filho Duplicar o mmap (Memory map - memoria virtual) do processo pai sys_fork() tamb m gerencia descritores de arquivos e inodes. novo A vers o 1.0 do kernel possui algum vest gio de suporte ao "threading" (trabalho ou processo em paralelo), e a chamada a sistema fork() apresenta algumas alus es ele. A morte de um processo dif cil, porque o processo pai necessita ser notificado sobre qualquer filhos que existam (ou deixem de existir). Al m disso, um processo pode ser morto (kill()) por outro processo (isto um aspecto do UNIX). O arquivo exit.c, portanto, a casa do sys_kill() e de variados aspectos de sys_wait(), em acr scimo sys_exit(). O c digo pertencente exit.c n o descrito aqui - ele n o t o interessante. Ele trabalha com uma quantidade de detalhes para manter o sistema em um estado consistente. O POSIX "standard", por conseguinte, dependente de sinais (flags), e tinha que trabalhar com eles. 3.4 - Executando Processos Depois de executar o fork(), duas copias do mesmo programa est o rodando. Uma delas usualmente executa - exec() - outro programa. A chamada a sistema exec() deve localizar a imagem bin ria do arquivo execut vel, carrega-lo e executa-lo. "Carrega-lo" n o significa, necess riamente, copiar na mem ria a imagem bin ria do arquivo, para que, assim, o Linux possa atender a demanda de programas a serem executados. A implementa o Linux do exec() suporta formatos bin rios diferentes. Isto dotado atrav s da estrutura linux_binfmt, a qual embute dois ponteiros para fun es - um para carregar o execut vel e o outro para carregar a "library" associada, cada formato bin rio deve conter, portanto, o execut vel e sua "library". O sistema UNIX prove, ao programador, seis formas para a fun o exec(). Quase todos podem ser implementados como uma "library" de fun es, e o kernel do Linux implementa sys_execve() independentemente das providas pelo UNIX. Ele executa uma nica tarefa: carregar o cabe alho do execut vel, e tenta executa-lo. Se os dois primeiros bytes s o "#!", ent o a primeira linha ignorada e um interpretador invocado, caso contr rio o formato bin rio, registrado, executado seq encialmente. O formato nativo do Linux suportado diretamente por fs/exec.c, e as fun es relevantes 102

s o load_aout_binary e load_aout_library. Assim como para os bin rios a fun o de carregamento "a.out" invocada, e a fun o mmap() (memory map - mem ria virtual ) aloca espa o em disco (no caso da mem ria real estar cheia) para o processo, ou invoca read_exec(), caso haja espa o em mem ria. "The former way uses the Linux demand loading mechanism to fault-in program pages when they're accessed, while the latter way is used when memory mapping is not supported by the host filesystem (for example the "msdos" filesystem)". novo A partir da vers o 1.1 do kernel, o Linux embutiu um sistema de arquivos (filesystem) revisado do msdos, que suporta mmap() (memory map - mem ria virtual). Al m disso a estrutura linux_binfmt uma "lista ligada" e n o um array, para permitir carregar um novo formato bin rio como um m dulo do kernel. Finalmente a estrutura, por si mesma, foi estendida para acessar rotinas com o formato relativo core-dump. 112

4 - Ger ncia de Mem ria 4.1 - Gerenciamento de Mem ria do Linux (LMM) A execu o do LMM (Linux Memory Manager) exige uma estrat gia de pagina o com uma copy-on-write confiando nas 386 p ginas auxiliares. Um processo alcan a suas tabelas de p ginas de seu parent (durante um fork ) com as entradas marcadas como read-only ou trocado. Ent o, se o processo tenta escrever para este espa o de mem ria e a p gina uma copy on write page, isto copiado e a p gina marcada read-write. Um exec ( ) resulta na leitura de uma p gina ou mais do execut vel. O processo ent o erra em qualquer outra p gina que precisar. Cada processo tem uma tabela de p gina que significa que pode acessar 1 Kb de tabela de p gina indicando para 1 Kb de 4 Kb, p ginas que 4 Gb de m moria. Um diret rio de p gina do processo iniciado durante um Fork por copy-page-tables. O processo inativo tem seu diret rio de p gina inicializado durante a sequ ncia de inicializa o. Cada processo usu rio tem uma tabela descrit ria local que cont m um c digo de segmento e um segmento de dados. Estes segmentos usu rios extendem de 0 para 3 Gb (0 X c 0000000). Nos espa os usu rios, endere os lineares e endere os l gicos s o id nticos. No 80386, endere os lineares v o de 0 Gb para 4 Gb. Um endere o linear indica uma posi o particular de mem ria dentro deste espa o. Um endere o linear n o um endere o f sico --- isto um endere o virtual. Um endere o l gico consiste de um seletor e um offset. O seletor indica para um segmento e o offset diz que dist ncia na se o o endere o localizado. O c digo Kernel e o segmento de dados s o se es privilegiados definidos na tabela descritora global e extende de 3Gb para 4Gb. O Swapper - page - dir organizado para que estes endere os l gicos e f sicos sejam id nticos no espa o Kernel. O espa o 3Gb acima aparece no process page directory como indicadores para tabelas de p ginas Kernel. Este espa o invis vel para o processo no user mode, mas o modo privilegiado acionado, por exemplo, para sustentar um sistema de liga o. O modo surpevisor inserido dentro do contexto do processo atual ent o a tradu o do endere o ocorre com respeito ao diret rio de p gina do processo, mas usando segmentos Kernel. Isto id ntico no mapeamento produzido com o uso de swapper - pg - dir e segmentos Kernel como ambos diret rios de p ginas usa a mesma tabela de p gina neste espa o. Apenas task [0] (A tarefa inativa, s vezes chamada de "tarefa trocadora" por raz es hist ricas, mesmo assim isto n o tem rela o com trocas nos implementos Linux) usa o swapper - pg - dir diretamente. O segmento base do processo usu rio = o X 00, page - dir particular, para o processo. O processo usu rio faz um sistema de liga o : segment base = 0 X c 0000000 page - dir = mesmo usu rio page dir. swapper - pg - dir cont m um mapeamento para todas as p ginas f sicas de 0 X 0000000 para 0 X c 0000000 + and_mem, ent o as primeiras 768 entradas em swapper - pg - dir s o 0's, e ent o h 4 ou mais que indicam na tabela de p ginas Kernel. O user page directories t m as mesmas entradas como swapper - pg - dir dos 768 acima. As primeiras 768 entradas mapeam o espa o usu rio. A vantagem que sempre que o endere o linear acima de 0 X c 0000000 tudo usa a mesma tabela de p ginas Kernel (Kernel page Tables). O monte usu rio permanece no topo do segmento de dados do usu rio e desce. O Kernel Stack n o uma bonita estrutura ou segmento de dados que eu possa apontar com um "aqui um Kernel Stack". Um Kernel Stack_frame (uma p gina) associada com cada 122

novo processo criado e usado sempre que o Kernel opera dentro do contexto deste processo. Coisas ruins aconteceriam se Kernel Stack descesse abaixo de seu corrente stack frame. [ Onde o Kernel Stack guardado? Eu sei que h um para cada processo, mas onde isto armazenado quando isto n o est sendo usado? ] P ginas usu rios podem ser roubados ou trocados - Um user page um que mapeado abaixo de 3 Gb em uma tabela de p ginas usu rios. Esta regi o n o cont m page directories ou page tables. Apenas p ginas sujas s o trocadas. Menores altera es s o necess rias em alguns lugares ( testes para limites de mem ria vem para a mente) para prover suporte para definidos segmentos programados. [ H agora uma modifica o - c + O sistema de liga o usado por dosane, Wine, Twin, and Wabi para criar segmentos arbitr rios. ] 4.2 - Mem ria F sica Aqui est um mapa de mem ria f sica antes que qualquer processo de usu rio for executado. A coluna da esquerda mostra o endere o de partida do item e os n meros em negrito s o aproximados. A coluna do meio mostra os nomes dos itens. A grande coluna da direita mostra a rotina relevante ou o nome vari vel ou explica es para ingresso. * Projeto - Inits que adquirem mem ria s o (principais.c) profil - buffer, com, init, psaux, init, rd,, init, scsi.dev - init. Note que toda mem ria n o marcada como livre reservada (mem-init). P ginas reservadas pertencem ao Kernel e nunca est o livres ou trocadas. Uma vis o de mem ria do user process. O c digo de segmento e dados do segmento extendem todo o caminho de 0 X 00 para 3 Gb. Correntemente o page fault handler do wp_page confere para assegurar que um processo n o escreve para seu c digo de espa o. De qualquer modo, pegando o sinal segu, poss vel escrever para o code space, causando ocorr ncia de um copy - on - write. O Handler do_no_page assegura que qualquer p gina nova que o processo adquira perten a ao execut vel, uma biblioteca dividida, ao stack, ou dentro do valor do brk. Um usu rio de processo pode reordenar seu valor brk chamando sbrk ( ). Isto o que malloc ( ) faz quando precisa. O texto e a por o de dados s o distribu dos em p ginas separadas ao menos que algu m escolha o N op o composta. A biblioteca dividida carrega endere os s o correntemente tornadas da imagem dividida por ele mesmo. O endere o entre 1.5 Gb e 3 Gb, exceto em casos especiais. 4.3 - Distribui o da mem ria do processo usu rio O Stack, shlibs e os dados s o muito afastados um do outro para serem spanned por uma tabela de p gina. Todas KPT s o divididas por todos processo e deste modo eles n o est o na lista. Apenas p ginas sujas s o trocadas. P ginas limpas s o roubadas e deste modo o processo pode t -los de volta para o execut vel se for desejado. A maioria das vezes apenas as p ginas limpas s o divididas. Uma p gina suja termina dividida sobre um fork at que parent ou child escolham para escrever isto de novo. Administra o dos dados da mem ria na tabela do processo. Aqui est um sum rio de algum dos dados mantidos na tabela do processo que usado para administra o da mem ria. Limites do processo da mem ria. 132

Ulong - start_code - and_code - and_data - brk, atart - stock Erro de contagem de p gina. Tabela do descritor local. Sturct desc - sturct ldt {32} a mesa descritora local para tarefa. N meros de p ginas residentes. Swappable - troc veis Se ent o as p ginas do processo n o ser o trocados. Kernel Stack page Indicador para a p gina distribu da no fork. Saved - Kernel - Stack V86 modo material (stuff) stract tss pilha de segmentos (stack segments) indicador da pilha Kernel Kernel stack pointer segmento da pilha Kernel Kernel stack segment (0X10) ssi = esp 2 = ss2 = 0 N veis de previl gio n o usados. Segmentos seletores. Ds=es=fs=gs=ss=ok17,cs Todos indicam para segmentos no corrente 1 dt [ ] c r 3 : indicam para o page directory para este processo 1 dt - LDT (n) seletores para tarefas correntes do LDT 142

4.4 - Inicializa o da mem ria No Start Kernel (main.c) h 3 vari veis relatadas para inicializa o da mem ria: memory_start memory_end Low memory_start come a a 1 Mb atualizado pelo projeto de inicializa o. t rmino da mem ria f sica: 8 Mb, 16 Mb, ou qualquer outro. t rmino do c digo Kernel e dados que carregado inicialmente Cada projeto init tipicamente torna memory_start e retorna um valor atualizado, se distribui espa os no memory_start (simplesmente pegando-a). Paging init ( ) inicializa a page-tables no { \ tt swapper - pg - dir} ( come ando a 0 X 0000000) para cobrir toda a mem ria f sica do memory_start para memory_end. Na verdade o primeiro 4 Mb feito no startup_32 (heads).memory_start incrementado se quaisquer nova page-tables s o adicionados. A primeira p gina zerada para bloquear os indicadores das refer ncias do al ap o nulo no Kernel. No sched_init ( ) o 1 dt e tss descritores para tarefa [0] s o postos no GDT, e carregado para dentro do TR e LDTR (a nica vez que isto feito explicitamente). Um trap gate (0X80) ordenado para system-call.( ). A bandeira tarefa aninhada desligada na prepara o para entrada do modo usu rio: O cron metro ligado. O task-struct para task [0] aparece por inteiro em < linux / sched.h > mem_map ent o constru do por mem_init ( ) para refletir o corrente uso das p ginas f sicas. Este o estado refletido no mapa da mem ria f sica da se o anterior. Ent o Dinux move para dentro do modo usu rio com um iret ap s empurrar o corrente ss, esp, etc. Claro que o segmento usu rio para task [0] s o mapeados bem sobre os segmentos Kernel e deste modo a execu o continua exatamente onde isto termina. Task [0]: pg_dir = swapper - pg - dir que sigmifica apenas endere os mapeados est o no alcance 3 Gb para 3 Gb + High memory. LTD [1] = c digo usu rio, base = 0 x 0000000, tamanho = 640 K LDT [2] = dados usu rios, base = 0 x 0000000, tamanho = 640 k O primeiro exec ( ) p e a LTD entrada para task [1] para os valores usu rios da base = 0x0, limite = task_size = 0 x c 0000000. Depois disso, nenhum processo v os segmentos Kernel enquanto no modo usu rio. Processos e a Administra o da Mem ria. Mem ria relacionada trabalho feito por fork ( ): distribui o de mem ria 1 p gina para o Task-struct 1 p gina para o Kernel Stack 1 para o pg_dir e algumas para pg_tables (c pias - p ginas - tabelas) Outras mudan as sso p e para o segmento Kernel stack (0x10) para ter certeza? espo p e para o topo da nova distribui o Kernel - stack - page. c r 3 p e por copy - page - tables ( ) para indicar para nova p gina de diret rio distribu da 1 dt = LDT (task_nr) cria novo 1 dt descritor descritores p e no gdt para novo tss e 1 dt [ ] Os registros restantes s o herdados do parent. 152

Os processos resultam dividindo seus c digos e segmentos de dados (embora eles tenham tabelas descritoras locais separados, as entradas indicam para os mesmos segmentos). O stack e p ginas de dados ser o copiados quando o parent ou child escreve para eles ( copy-on-write). Mem ria relacionada trabalho feito por exec ( ): distribui o de mem ria 1 p gina para exec header para omagic 1 p gina ou mais para stack (max_arg_pages) clear-p gina-tables ( ) usado para remover p ginas velhas. change 1 dt ( ) p e os descritores no novo 1 dt [ ] 1 dt [1] = c digo base = 0 x 00, limite = task - size 1 dt [2] = data base = 0 x 00, limite = task - size Estes segmentos s o dpl = 3, p=1, s=1, g=1. Tipo = a (c digo or 2 dados) Eleva para MAX_ARG_PAGES p ginas sujas de arqu e enup s o distribu dos e guardado ao topo do segmento de dados para o novo usu rio pilha criado. Ponha os indicadores de instru o do caller cip = ex.a_cutry Ponha o stack indicador do caller para o stack criado (esp=stack indicador). Este ser o eliminados do Stack quando o caller resume. Limites de Mem ria Atualizados cud_code = ex.a_text cud_data = cud_code + &x.d_data brk = end_data + ex. _bss Interrup es e traps s o sustentadas dentro do contexto da corrente tarefa. Em particular, o diret rio de p ginas do corrente processo usado na tradu o de endere os. Os segmentos, de qualquer modo, s o segmentos Kernel para que todos os endere os lineares apontem para dentro da mem ria Kernel quer acessar uma vari vel no endere o 0 x 01. O endere o linear 0 x 00000001 (usando segmentos Kernel) e o endere o f sico 0 x 01. O ltimo porque a p gina do processo diret rio mapea esta extens o exatamente como page_pg_dir. O espa o Kernel (0 x c 0000000 + high - memory) e mapeado pela tabela de p ginas Kernel que s o eles mesmos parte da mem ria reservada. Eles s o consequentemente divididas por todos processos. Durante um fork copy-page-tables ( ) trata tabela de p ginas reservadas diferentemente. Isto p e indicadores no diret rio de p ginas de processo para indicar para tabelas de p gina Kernel e na verdade n o distribui novas tabelas de p ginas como isto faz normalmente. Como um exemplo o Kernel - Stack - page ( que ocupa algum lugar no espa o Kernel ) n o precisa de um associado page - table distribu dos no pg-dir do processo para mape -lo. O interruptor de instru es p e o indicador stack e o segmento stack do privil gio valor salvo no Tss do corrente task. Note que o Kernel stack um objeto realmente fragmentado - Isto n o um objeto nico, mas sim um grupo de stack frames. Cada um distribu do quando um processo criado e deixado quando ele sai. O Kernel stack n o deveria crescer t o rapidamente dentro de um contexto de um processo que extende abaixo da corrente frame. 4.5 - Adquirindo e liberando mem rias Quando qualquer rotina Kernel precisa de mem ria isto acaba chamando get-free-page ( ). Este est num n vel mais baixo do que Kmallor ( ) (de fato Kmalloc ( ) get-free-page ( ) quando isto precisa mais mem ria). Get-free-page ( ) toma um par metro, a prioridade. 162

Poss veis valores s o gfp_buffer_gfp, Kernel, gfp,nfs e gfp atomic. Isto tira uma p gina do the free-page-list, atualizados mem_map, zeram a p gina e retorna o endere o f sico da p gina (note que Kmalloc) retorna um endere o f sico. A l gica do mm depende do mapa da identidade entre o endere o l gico e f sico. Isto por ele mesmo bastante simples. O problema claro, que o free-page-list pode estar vazio. Se voc n o requisitar uma opera o at mica, nesta etapa, voc entra dentro do dom nio de uma page stealing e que n s discutiremos em um momento. Como um ltimo recurso ( e para requisitos at micos) uma p gina separada do secundary-page-list (como voc pode ter achado, quando p ginas s o libertadas, o secundary-page-list enche primeiro a manipula o atual da page-list e mem-map ocorre neste misterioso macro chamado remove-from-mem-queve ( ) que voc provavelmente nunca quer investigar. O suficiente para dizer que interrup es s o incapacitados. [Eu penso que isto deveria ser explicado aqui. Isto n o t o dif cil...] Agora de volta ao "Roubando p ginas" get-free-page ( ) chame try-to-fre-page ( ) que chame repetidamente shrink_buffers ( ) e swap-out ( ) nesta ordem at conseguir liberar uma p gina. A prioridade aumentada em cada iteration sucessiva para que estas duas rotinas processem suas page-sterling-loops mais frequentemente. Aqui est um exemplo do processo swap-out: Fa a a tabela do processo e adquira uma swappable task, por exemplo, Q. Ache um user page-table (n o reservado) no espa o de Q. Para cada p gina na tabela try-to-swap-out (page) Termina quando a p gina liberada. Note que swap-out ( ) (chamada try-to-free-page ( )) mant m vari veis estat sticas e deste modo isto pode resumir a procura onde terminar a chamada anterior try-to-swap-out ( ) examine os page-tables de todos usar process e obrigue o sterling policy: 1) N o brincar com as p ginas (reserved) reservadas 2) Envelhe ar a p gina se ela marcada acessada (1 bit) 3) N o mexa com p gina adquirida recentemente (last-free-pages ( )) 4) Deixe p ginas sujas com map-counts > 1 intocadas 5) Diminua o map-count das p ginas limpas 6) Librere p ginas limpas se elas n o s o mapeadas 7) Troque p ginas sujas com um map-count de 1 De todas essas a es, 6 e 7 v o parar o processo poruqe eles resultam na libera o atual de uma p gina f sica. A quinta a o resulta uma dos processos perdendo uma p gina limpa n o dividida que n o foi acessada recentemente (diminuindo Q rss) que n o t o ruim, mas os efeitos cumulativos de algumas iterations pode atrasar o processo muito. No presente, h 6 iterations, deste modo uma p gina dividida por 6 processos pode ser roubada se est limpa. Page table ent o s o atualizados e o TLB invalidado. O trabalho atual de liberar uma p gina feito por free-page ( ), a complementa o de get-free-page ( ). Isto ignora p ginas reservadas, atualiza mem-map, e libera a p gina e atualiza o page-list (s) se n o mapeada. Para troca (em 6 em cima), write-swap-page ( ) chamada e n o faz nada not vel da perspectiva da administra o da mem ria. Os detalhes de shink-buffers ( ) nos levaria muito longe. Essencialmente isto procura free "buffers" (buffers s o uma parte da mem ria que segura informa o temporariamente quando dados transferem de um lugar para outro) em seguida escreve buffers sujos, e depois come a com buffers ocupados e chama free-page ( ) quando pode liberar todos os buffers numa p gina. Note que page directories, page-table, e reserved pages n o s o trocadas, roubadas ou envelhecidas. Eles s o mapeadas no process page directories com reserved page tables. 172

Eles s o liberados somente na sa da do processo. The page Fault Handles Quando um processo criado por fork, ele come a com um page directoru e uma p gina ou mais do execut vel. Deste modo the page fault handles a forte da maioria da mem ria do processo. The page fault handles do page-fault ( ) recupera o endere o faltando no registro c r 2. O c digo do erro ( recobrado no sys-call.s) diferencia o acesso do user / supervisior e a regi o para o fault-write prote o de uma p gina faltando. O anterior sustentado pelo do-wp-page ( ) e o posterior pelo do-no-page ( ). Se o endere o falatando maior do que Task-Size, o processo recebe um SIGKILL [ Por que este controle? Isto pode acontecer somente em Kernel mode por causa da prote o do n vel do segmento. Estas rotinas tem algumas sutilezas como elas podem ser chamadas num interrompimento. Voc n o ode supor que a tarefa corrente que est executando de-no-page ( ) sustenta tr s situa es poss veis: 1) A p gina trocada 2) A p gina pertence a biblioteca execut vel ou dividida. 3) A p gina est faltando - uma p gina de dados n o foi distribu da Em todas as causas get-empty-pgtable ( ) chamada primeiro para assegurar a exist ncia de uma page table que cobre o endere o falatando. No terceiro para providenciar uma p gina no endere o requerido e no caso de uma p gina trocada, swap-in ( ) chamado. No segundo caso, o handles calls share-page ( ) para ver se a p gina pode ser dividida com algum outro processo. Se isto falhar leia a p gina do execut vel ou biblioteca (Isto repete a chamada para Share-page ( ) se um outro processo fez o mesmo enquanto isso). Qualquer por o da p gina fora do valor brk zerada. A p gina lida do disco contada como um erro maior. Isto acontece com um swap-in ( ) ou quando lida da execut vel ou uma biblioteca. Outras casos s o consideradas erros menores (mim-flt). Quando uma p gina divis vel achada ela corite-protected. Um processo que escreve para uma p gina dividida vai precisar passar por um do-wp-page ( ) que faz o copy-on-write. Do-wp-page ( ) fa a o seguinte: Mande SIGSEGV se qualquer usar process o est escrevendo para o corrente code-space. Se a p gina velha n o dividida, ent o simplesmente n o proteja-o. Sen o get-free-page ( ) and copy-page ( ). A p gina adquirire a bandeira suja da p gina velha. Diminua a conta do mapa da p gina velha. 4.6 - Paginando (Paging) Paginando a troca numa base da p gina melhor do que os processos inteiros. N s vamos usar trocando aqui para referir "paginando", uma vez que apenas Linux p gina, e n o trocar, e pessoas s o mais acostumadas palavra "Swap" / "trocar" do que "page" / "paginar". Kernel pages nunca s o trocadas p ginas limpas tamb m n o s o escritas para trocar. Elas s o liberadas e recarregadas quando requerida. O trocador mant m um nico bit de informa o de envelhecimento nas P ginas acessadas bit da page table cutries - [ O que s o os detalhes de manuten o? Como isto usado?] Linux suporta m ltiplos swap files ou projetos que podem ser ligados ou desligados pelas liga es de swapoff system. Cada swap file ou projeto descrito por uma strut-swap-info. O campo das bandeiras (SWP-USED ou SWP-WRITE ok) usado para controlar acesso para o swap files. Quando SWP- WRITE ok desligado, o espa o n o vai ser distribu do neste arquivo. Isto usado por Swapoff quando isto tenta de n o usar um arquivo. Quando swapoff adiciona um arquivo de troca nova isto aplica SWP-USED. Um vari vel 182

im vel no Swap files armazena o n mero dos arquivos ativos correntemente ativos. s campos lowest - bit e hihgest - bit limitam a regi o livre na pasta de troca e s o usadas para adiantar a procura por espa o de troca livre. O programa do usu rio m < swap inicializa um swap device ou file. A primeira p gina cont m uma assinatura (swap-space) nos ltimos 10 bytes, e cont m um mapa de bit. Inicialmente 1's no bitmap significam p ginas ruins A'1' no bitmap significa que a p gina correspondente livre. Esta p gina nunca distribu da deste modo a inicializa o precisa ser feita somente uma vez. The Syscall Swapor ( ) chamado pelo user program swapon tipicamente de / etc / rc. Algumas p ginas da mem ria s o distribu das por swap-map e swap-lockmap, swap-map cont m um byte para cada p gina no swapfile. Isto inicializado do bitmap para conter 0 para p ginas dispon veis e 128 para p ginas que n o pode ser usadas. Isto para manter uma conta das peti es da troca em cada p gina no swap file. Swap-lockmap cont m um bit para cada p gina que usada para assegurar exclus o m tua quando lendo ou escrevendo swap-files. Quando uma p gina da mem ria est para ser trocada, um ndice para posi o da troca obtido com uma chamada para get-swap-page ( ). Este ndice deste modo guardado em bits 1-31 da page table entry para que a p gina trocada possa ser localizada pela page fault handles, do-no-page ( ) quando necess rio. Os 7 bits mais altos do ndice d o o swap file ( ou projeto) e os 24 bits mais baixos d o o n mero da p gina neste projeto. Isto faz at 128 swap files, cada um com espa o para mais ou menos 64 Gb, mas o espa o em cima devido o swap map seria grande. Ao inv s o tamanho do swap file limitado para 16 Mb, porque o swap map ent o toma 1 p gina. A fun o swap-duplicate ( ) usado por copy-page-tables ( ) para deixar o processo da child herdar p ginas trocadas durante um fork. Isto somente incrementa a conta mantendo no Swap-map para aquela p gina. Cada processo vai trocar numa c pia da p gina separa quando acess -la. Swap-free diminui a conta mantendo no swap-map. Quando a conta abaixa para 0 a p gina pode ser redistribu da por get-swap-page ( ). Isto chamado cada vez que uma p gina trocada lida na mem ria ( swap-inc ) ou quando uma p gina est para ser descartada ( free-one-table ( ), etc ). 4.7 - Gerenciamento de Mem ria Cache 4.7.1 - Arquitetura de Mem ria Cache do Linux (Linux Flush Architecture) O TBL mais uma entidade virtual do que um modelo estrito quanto a Linux flush architecture e concernida. As caracter stica nica s o isto mantem em ordem o mapeamento do processo kernel de algum modo, queira softivare ou hardware. C digo espec fico de arquitetura pode precisar ser modificado quando o kernel tiver mudado um processo/mapeamento kernel. O shell (um lugar seguro p/ guardar dinheiro ou coisas) esta entidade essencialmente memory state / estado da memoria como o flush architecture o v. Em geral isto tem as propiedades seguintes: Isto sempre vai segurar c pias de dados que podem ser visto como atualizado pelo processo local. O funcionamento pr prio pode ser relacionado ao TLB e o mapeamento do 192

processo/kernel page de algum jeito, isto para dizer que eles podem depender um do outro. Isto pode, numa configura o cached virtual, causar problemas aliasing se uma p gina fisica mapeada no mesmo tempo da que duas p ginas virtuais e por causa dos bits de um endere o usado para catalogar a linha cache, a mesma por o do dedo pode acabar residindo no cache duas vezes, deixando resultados incompativ is. Projetos e DMA podem ou n o ter capacidade para ver a c pia de um dedo mais atualizado que resida no cache do processo local. Corretamente, suposto que a coer ncia num ambiente multiprocessador mantida pelo subsistema cache/mem ria. Isto que dizer que, quando um processador requerer um dado no memory bus de maneira e um outro processador tem uma c pia mais atualizada, de qualquer jeito o requesitor vai obter uma c pia atualizada que perten a um outro processador. (NOTA: SMP arquiteturas sem hardware cache conferece mechan sms s o realmente poss veis, o arquitetura current flush n o sustenta isto corretamente, se em algum ponto o Zinux apontar em algum sistema onda isto uma quest o debatida, eu vou adicionar os ganchos necess rios mas n o vai ser bonito) Sobre o que o Fluch Architecture se importa: sempre, a vis o da administra o de mem ria hardware de um conjunto de mapeamento do processo Kernel ser o consistentes com aqueles do Kernel page tables. Se o memory managemat kernel code faz uma modifica o para a user process page modificando o dado via kernel space alias da p gina f sica subjacente, o fio controle de usu rio vai ser o dado correto antes que permitido continuar a execu o, indiferente da cache architecture e/ou a sem ntica. Em geral, quando o estado do espa o de endere o mudado somente (em c digo gen rico da administra o da mem ria kernelnome de generic kernel management cade) o fluch architecture hook apropriado vai ser chamado descrevendo que o estado muda totalmente. Sobre o que o flush architecture n o importa: que o mapeamento do DMA DMA/driver coer ncia. Isto inclui DMA mappings (no sentido do MMU mappings) e o cache/dma dado consist ncia. Estes tipos des assuntos n o devem esta no flush architecture, veja embaixo como eles devem ser manuseados. Split Instrution/data cache consist ncia com respeitro as modifica es feito para processo de instru o de espa o realizado pelo c digo de sinal de despacho signal dispatch cade. De novo, veja embaixo como isto devem ser manuseado de um outro jeito. As interfaces para a flushachitesture e como execut -los em geral todas as rotinas descritos embaixo v o ser chamados na sequ ncia seguinte: Fluch-cache-foo(...); modify-address-space (); clush - tlb-foo (...) a l gica aqui : Isto pode ser ilegal num arquitetura dada por um peda o de dado cache para ensitir quando o mapeamento por aquele dado n o existe, portanto o flush deve ocorrer antes que a mudan a feita. possiv l para uma arquitertura de MMU/TLB dada realizar um andamento da tabela hardware hardware table wolk dos kernel page tables, portanto o TLV flush feito depois que os page tables terem sido mudados para que depois o hardware s pode carregar a c pia nova da informa o de page table para o TLB void flush - cache - all (void); 202

void flush - tlb - all (void); Essas rotinas s o para notificar o architecture specific cade que mapeamento do espa o do endere o kernel uma mudan a foi feita ao kernel address space mappings, que significa que os mapeamentos de todos processos foram efetivamente mudados. 4.7.2 - Implementa o da Mem ria Cache Uma implementa o deve: Eliminar todos os entradas do cache que s o v lidas neste momento quando flush-cache-all invocado isto refere-se ao virtual cache architecture, se a cache is write-back, essa rotina vai submeter o dado da cache para memoria antes do que invalidar cada ingresso. Para caches f sicos, n o necess rio realizar uma a o j que mapeamento f sico n o tem ponto de apoio no address space translations. Para flush-tlb-all todos TLB mappings para o kernel address space devem ser feito consitente com os OS page tables de qualquer maneira. Norte que com um arquitetura que possua a na o Para flush-tlb-mm, o tlb/mmu hardware para estar localizado num estado onde isto vai ver (agora corrente) kernal page table entradas para o espa o de endere o pelo mm-strust. flush_cache_range(struct mm_struct *mm, unsigned long start, unsigned long end); flush_tlb_range(struct mm_struct *mm, unsigned long start, unsigned long end); uma chance para uma particular range do user address no adelrass space descrito pelo mm-struct passada esta ocorrendo. As duas notas acima para FLUSH - mm( ) relecianando a mm-struct passada aplicam-se aqui tamb m. Para Flush-cache-range num virtualmente cached system, todas entradess cache que s o nolidas pena a range partem para o fim no address space descrito pelo mm-struect s o para ser invalidadas. Para Flush-tlb-range, qualquer a o necess ria para causar o MMUITLB hardware n o conter tradu es estragados s o para ser realizados. Isso significa que quaiquer tradu es est o no Kernel page tables no range start para acabar no address space descrito pelo mm-struet s o para que a administra o da memoria hardware sera deste ponto avan ado, por qualquer significado. void flush_cache_page(struct vm_area_struct *vma, unsigned long address); void flush_tlb_page(struct vm_area_struct *vma, unsigned long address); Uma chance para uma nica p gina no address dentro do usar space para o address space descrito pelo um area-struet passado esta ocorrendo. Uma efetiva o, se necess ria, pode obter na mm-struet associado para este address space via uma um - Flags. Este caminho em uma efetiva o onde a instru o e dara space n o s o unificados, alguem pode conferir para ver se um-exee esta posto no uma-sum-flags para possivelmente avistar flushing o instruction space, por exemplos: As duas notas acima para flush-*-mm( ) concermindo o mm-struct (passado indiretamente 212

via uma -um-mm) aplica aqui tamb m. A implemeta o deve tamb m : Para flush-cache-range, num virtualmente cache systam, todas entradas cacha que s o validas para a p gina no addrees no address space descrito pelo uma s o para ser invalidados. Para flush-tlb-range, qualquer a o necess ria para causar o MMU/TLB hardware para n o conter tradu es estragadas s o para ser efetuadas. Isto significa que quaisquer tradu es est o nos kernel page tables para a p gina no address space descrito pelo uma passado s o para que a administra o de mem ria hardware, ser o vistas deste ponto avan ado de qualquer maneira. 4.7.3 - Carregando o Flush-PAGE para a RAM (Unsigned Long Page); Este o patinho feio. Mas sera sem ntica necess rio em muitas arquiteturas que precisei para adicionar isto apra a arquitetura flush para linux. Brevemente, quando (como um exemplo) serve um kernel um enode cow, isto usa o suposto mapeamento de todas memorias fisicas no espa o kernal para efetuar a c pia da p gina em quest o para uma nova p gina. Este apresenta um problema para caches virtualmente catalogados que s o write-back escritos de volta na natureza. Neste caso, o Kernel toca duas p ginas fisicas no espa o Kernel. A sequencia do c digo sendo descrito aqui essencialmente parece como: do_wp_page() { [... ] copy_cow_page(old_page,new_page); flush_page_to_ram(old_page); flush_page_to_ram(new_page); flush_cache_page(vma, address); modify_address_space(); free_page(old_page); flush_tlb_page(vma, address); [... ] } Alguns dos c digos atuais tem sido simplificados para propositos espesificos. Considere um cache virtualmente catalogados que escrito de volta write-back. Neste momento que a c pia da p gina acontece para o supisto espa o kernel, possivel para usar space a vis o da p gina original para estar no caches (no endere o do usu rio, por exemplo, onde o erro esta ocorrendo). A c pia da p gina pode trazer este dado (para a p gina velha) dentro do caches. Ser tamb m colocado o dado (no novo suporte kernel mapeado da p gina) sendo copiado para dentro da cache, e para write-back escrever de volta chachas este dado vai ser sujo ou modificado no cache. Em tal caso a memoria principal n o ser a c pia mais recente do dado. Os caches s o est pidos, ent o para a nova p gina que estamos dando ao usu rio, sem for ar o dado cached no suposto kernel para a mem ria principal o processo ser o conte do velho da p gina. (Por exemplo qualquer lixo que estarem l antes da c pia ter sido feita pelo processamento COW acima). 222

4.7.3.1 - Exemplo concreto de flush-page Considere um processo que divide uma p gina, l somente READ-ONLY com maior uma tarefa (ou varias) no endere o virtual Ox2000, no usar space. E para prop sito espes ficos deixe nos dizer que este endere o virtual mapeia para a p gina f sica 0x14000. Se a tarefa 2 tenha escrever para a p gina l apenas no endere o 0x2000 n s alteremos um esso e (eventual fragmento do c digo) mente resultado no code fragment mostrando acima no do-wp-page ( ). O Kernel vai obter uma nova p gina para tarefa 2, deixe-nos dizer que esta e uma p gina f sica 0x2600, e deixe-nos tambem dizer que os mapeamentos do suposto Kernel para p ginas f sicas 0x14000 e 0x26000 podem residir em dias nicos linhas cache ao mesmo tempo buscando no esquema da linha catalogada deste cache. O conte do da p gina e copiado do mapeamento Kernel para p gina f sica 0x14000 para uns para p gina f sica 0x26000. Neste momento, numa arquitetura cache virtualmente catalogada write - back nos temos uma inconsist ncia potencial. O novo dado copiado dentro da p gina f sica 0x26000 n o e necess rio na mem ria principal neste momento, de fato isto poder estar toda no cache apenas no suposto kernel do endere o f sico. Tamb m, o (n o modificando, por exemplo, limpo) dado para a (velha) p gina original esta no cache do suposto kernel para p gina f sica 0x14000, isto pode produzir uma inconsist ncia mais tarde, ent o para proteger isto e melhor eliminar as c pias cached deste dado tamb m. Deixe-nos dizer n o escrevemos os dados de volta para a p gina no 0x256000 e nos apenas deixamos isto l. Nos retornariamos para a tarefa 2 (Quem teve esta nova p gina agora mapeada no endere o virtual 0x2000) ele completaria sua escrita, ent o ele leria algumas outras por es de dados nesta nova p gina (por exemplo, esperando o conte do que existe l antes). Neste momento seo dado e deixado no cache no suposto kernel para nova p gina f sica, o usu rio obter o que que estava na mem ria principal antes da c pia para sua leitura. Isto pode levar a resultados dasastrosos. 4.7.4 - Conte do de uma arquitetura virtual Numa arquitetura cache virtualmente catalogada, fica o que foi necess rio para fazer a mem ria principal consistente com a c pia cached da p gina passada do espa o kernel. Nota: Isto na verdade necess rio para esta rotina invalidar linhos em um cache virtual que n o escrito de volta write - back na natureza. Para ver porque isto e realmente necess rio, refa a o exemplo acima com a tarefa 1 e 2, mas agora fork ( ) ainda outra tarefa 3 antes dos erros do cow ocorreram, considere o conte do do caches no kernel e user space se a sequencia seguinte ocorre na exata sucess o: 1. Tarefa 1 l uma parte da p gina no 0x2000 2. Tarefa 2 COW erra a p gina no 0x2000 3. Tarefa 2 efetiva suas escritas para a nova p gina no 0x2000 4. Tarefa 3 COW erra a p gina 0x2000 Mesmo em um cache n o escrito devolta virtualmente catalogado, a tarefa 3 pode ver o 232

dado incossistente depois do erro COW se FLUSH-PAGE-TO-RAM n o invalida a p gina f sica do suposto kernel do cache. VOID-UP-DATE Embora n o estritamente parte da arquitetura flush, em certas arquiteturas algumas opera es e controles precisam ser eferuados aqui parea as coisas darem certo proporcionalmente e para o sistema manter-se consistente. Em particular, para caches virtualmente catalogados esta rotina deve conferir para ver que o novo mapeamento que vem sendo adicionado pelo conente erro de p gina n o adiciona um bad alias para o user space. Um Bad Alias e definido como dois ou mais mapeamentos (pelo menos um dos quais e escrevivel) para duas ou mais o p ginas que traduzem para a exata p gina f sica, e devido ao algarismo catalogado do cache pode tamb m residir na nica e mutualmente exclusiva linhas cache. Se um BAD ALIAS detectado, uma implementa o precisa resolver esta inconsist ncia de alguma maneira, uma solu o e andar atrav s de todo os mapeamentos e mudar as page-tables para fazer estas p ginas como n o concre veis se o hardaware permite tal coisa. As confer ncias para isto s o muito simples, tudo que uma implementa o precisa fazer : Se ((uma -Um - Flags 6 (Um - Write/Um - Shared)) confere sua pot ncia mau supostas, ent o para o caso comum (mapeamento escrev veis devidos s o extremamente raros) apenas uma compara o necessitada para sistemas COW CAHCES virtualmente catalogados. 4.7.5 - Implica es Referentes a Arquitetura 4.7.5.1 - Arquitetura baseada no Modelo SMP Dependendo da arquitetura certos consertos podem ser necess rios para permitir a arquitetura FLUSH para trabalhar num sistema SMP. O principal assunto e se uma das opera es FLUSH acima fazem que o sistema inteiro veja o FLUSH globalmente, ou o FLUSH e apenas garantido para ser visto pelo processador local. Em um ltimo caso um CROSS CALLING MECHANISM necess rio. Os dois correntes sistemas SMP suportados no LiNUX (intel e space) usam inter-processor interrupts para transmitir a opera o FLUSH e faz isto correr localmente em todo processador se necess rio como um exemplo, no sistema SUNHM Space todos precessadores no sistema precisam executar o pedido FLUSH para garantir a consist ncia atrav s do sistema inteiro. De qualquer modo, nas m quinas SUNHD Space, TLB FLUSHES efetivamente no processador local s o transmitidos sobre o BUS-SYSTEM pelo hardware e desta forma uma liga o cruzada n o e necess ria 4.7.5.2 - Implica es para arquitetura baseados no contexto MMU/CACHE. A id ia inteira por tr s do conceito de MMU e facilidades do contexto cache para permitir muitos ADDRESS SPACES para dividir os recursos CACHE/MMU no CPU. Para levar total vantagem de tal facilidade, e ainda manter a coer ncia descrita acima, requer-se algumas considera es extras do implementador. 242

As quest es envolvidas variam muito de uma implementa o para outro, pelo menos esta tem sido a experi ncia do autor. Mas em particular algumas destas quest es s o provavelmente para ser: A rela o do mapeamento do espa o Kernel para os USER-SPACE, num contexto s o convertidas, alguns mapeamentos do sistema kernel tem um atributo global, naquele o hardware n o concerde ele mesmo com o contexto da informa o quando uma tradu o feita, que tem seu atributo. Desta forma um FLUSH (em qualquer contexto) de um mapeamento de um Kernel CACHE/MMU poderia ser suficiente. De qualquer maneira e poss vel um outros implementa es para o Kernel para dividir o contexto chave associado com um ADDRESS SPACE particular. Pode ser necess rio em tal caso andar por todos contextos que s o contentemente v lidos e efetuam o Flush completo em cada um para um Kernall Address Space Flush. O custo por contexto Flush podem tornar uma quest o chave, especialmente com respeito ao TLB. Por exemplo, se um Tlb Flush e necess rio, em um grande Range de endere os (ou um inteiro Address Space) pode ser mais prudente distribuir e assumir um nova contexto MMU/para este processo por causa da efici ncia 4.7.6 - Como tratar o que a arquitetura flush n o executa com exemplos A arquitetura Flush descrita n o faz emendas para coer ncia de projetos DMA com dados Cached. Isto tamb m n o tem provis es para nenhuma estrat gia de mapeamento necess rios pelo DMA e projetos se forem necess rios em um certa m quina Linux Portad To. Nenhuma destas quest es s o para a arquitetura Flush. Tais quest es s o negociadas mais claramente no n vel do Driver do projeto. O autor est mais convencido disto depois de sua experi ncia com um conjunto comum de sparc device drivers que precisaram de toda fun o corretamente em mais do que uma hand full de cache/mmu e bus architetures no mesmo kernel. De fato esta implementa o mais eficiente porque o motorista sabe exatamente quando o DMA precisa ver o dado consistente ou quando o DMA est indo criar uma inconsist ncia que deve ser resolvida. Nenhuma tentativa para atingir este nivel de eficiencia via cochetes soma ao codigo de administracao generica da memoria kernel seria complexo e muito obscura como um exemplo, considere no sparc como os DMA buffers s o manuscrito. Quando um device driver deve efetuar o DMA para/de um nico buffer, ou uma dispersa lista de muitos buffers, ele usa um conjunto de rotinas abstratas. Char * (*mmu_get_scsi_one)(char de char *, unsigned linux_sbus longo de struct *sbus); sem (*mmu_sglist (*mmu_get_scsi_sgl)(struct de efeito *, int, linux_sbus de struct *sbus); sem (*mmu_release_scsi_one)(char de efeito *, unsigned linux_sbus longo de struct *sbus); sem (*mmu_sglist (*mmu_release_scsi_sgl)(struct de efeito *, int, linux_sbus de struct *sbus); sem (*mmu_map_dma_area)(unsigned de efeito addr longo, len de int); Essencialmente o mmu_get_* rotinas s o passadas por um indicador ou um conjunto de indicadores e especifica es de tamanho para res no espa o kernel para que o DMA ocorra, eles retornam para o endere o capaz do DMA (por exemplo um que pode ser carregado do controlador do DMA para o transferidor). Quando o driver feiro como DMA e o transferidor tiver completado com o(s) endere o(s) DMA para que recursos 252

possam ser liberados (se necessario) e cache flushes possam ser efetivados (se necessario). A rotina ter um bloqueio de memoria de DMA por um longo periodo de tempo, por exemplo, um motorista de networking usaria isto para uma transmissao de pesquisa ou receber buffers. O argumento final uma entidade especifica Sparc que permite o codigo do nivel da maquina efetuar o mapeamento se o mapeamento do DMA s o ordenados em uma base por-bus. 4.7.7 - Quest es abertas na Arquitetura Cache H pareceres para muita estupidas arquiteturas cache l fora que queira causar problemas quando um alias est situado dentro do cache (mesmo um protegido onde nenhuma das entradas do cache suposto s o escreviveis!). Da nota est o mipsr4000 que dar uma exce o quando tal situa o ocorre, elas podem ocorrer quando o processamento cow est acontecendo na corrente implementa o. No mais chips que fazem algo estupido como isto, um exception handler pode flush as entradas no cache que est sendo reclamado e tudo est em ordem. O autor esta mais concernido sobre o custo dessas exce es durante o processamento cow e seus efeitos que ocorrer o na performance cow, que essencialmente est para flush um user space page e se n o o fazendo ent o causaria os problemas acima descritos. Tem sido tardiamente aquecida a conversa sobre muito inteligentes networking hardware. Pode ser necessario estender a arquitetura flush para prover as interfaces e facilidades necessarias para estas mudan as para o codigo networking. claro que, a arquitetura flush sempre sujeita a aperfei oamentos e mudan as para buscar novas quest es ou novos hardwares que apresentam um problema que estava at este ponto desconhecido 262

5. Sistema de Arquivo no Linux (File System) 5.1. - Conceitos Fundamentais 5.1.1 - Arquivos Conceitualmente, arquivos s o mecanismos de abstra o que fornece uma forma de armazenar e recuperar informa es em disco. A caracter sticas mais importante de qualquer mecanismo abstra o a forma de identificar os objetos como os quais o mecanismo trata. Quando um processo cria um arquivo, preciso que tal arquivo receba um nome, normalmente dado pelo processo. Quando tal processo termina sua execu o, o arquivo continua a existir, podendo ser acessado por outros processos, usando para tanto o nome atribuido ao arquivo. O Linux faz distin o entre nome mai sculos e min sculos. Normalmente um nome de arquivo composto de nome e uma extens o, separada por ponto no Linux, o tamanho da extens o, se houver, fica a crit rio do usu rio, e uma arquivo pode at ter duas ou mais exten es, exemplo : prog.c.z. N o h limite de n meros de caracteres utilizados para dar nome a arquivos. O Sistema Operacional Linux, olha o arquivo como uma sequ ncia de byte, sem nenhuma estrutura, isto d uma flexibilidade espantosa ao sistema de arquivo. Os programas de usu rios, podem colocar o que desejarem nos arquivos e identific -los da forma que lhe for mais conveniente, o Unix n o influ ncia em NADA nesta processo de identifica o. 5.1.2 - Diret rios Para tratar dos arquivos, o sistema operacional normalmente lan a m o do diret rios, no caso do Linux diret rios hier rquico,vide figura 01. Os diret rios s o um tipo de arquivo. No Linux todos os arquivos fazem parte de um diret rio, assim eles s o mantidos e organizados, os diret rios s o meios de oferecer endere os dos arquivos, de 272