ndice

ndice1-Introduo.......................................................................................................62-Histrico do Linux...........................................................................................83-Gerncia de Processos.....................................................................................103.1-Consideraes Iniciais.............................................................................103.1.1-Inicializao (boot do sistema).................................................103.2-Gerncia do Processo pelo kernel............................................................123.3-Criando e Destruindo um Processo.........................................................133.4-Executando Processos............................................................................134- Gerncia de Memria.......................................................................................154.1-Gerenciamento de Memria do Linux.....................................................154.2-Memria Fsica.......................................................................................164.3-Distribuio da Memria do Processo Usurio........................................174.4-Inicializao da Memria........................................................................184.5-Adquirindo e Liberando Memria...........................................................194.6-Paginao (Paging).................................................................................224.7-Gerenciamento de Memria Cache..........................................................234.7.1-Arquitetura de Memria Cache do Linux (Linux Flush Architecture) .............................................................................. 234.7.2-Implementao de Memria Cache..............................................244.7.3-Arquitetura Baseada no SMP.......................................................24.7.3.1-Arquitetura Baseada no contexto MMU/CACHE......274.7.4-Contedo de uma Arquitetura Virtual..........................................27ndice4.7.5-Implicaes Referentes a Arquitetura..........................................284.7.5.1-Arquitetura baseado no contexto SMP......................284.7.5.2-Arquitetura baseado no contexto MMU/CACHE.......294.7.6-Como tratar o que a Arquitetura flush no executa com exemplos..................................................................................... 294.7.7-Questes Abertas na Arquitetura Cache.......................................305-Sistema de Arquivos do Linux (File System)....................................................315.1-Conceitos Fundamentais.........................................................................315.1.1-Arquivos.....................................................................................315.1.2-Diretrios....................................................................................315.1.3-Conta..........................................................................................325.1.4-Tipo de Arquivos......................................................................... 325.1.5-Acesso a Arquivos.......................................................................335.1.6-Atributos dos Arquivos................................................................335.2-Operaes sobre Arquivos......................................................................345.3-Arquivos Compartilhados........................................................................355.4-Estrutura do Sistema de Arquivos Linux Realease 1.2.............................365.4.1-Apresentao...............................................................................365.4.2-Caractersticas Sistema de Arquivos.............................................365.4.3-Composio dos Diretrios..........................................................385.4.3.1-Subdiretrio /bin.......................................................395.4.3.1.1-Arquivos e/ou Comandos disponveis em /bin............................................... 39ndice5.4.3.2-Subdiretrio /boot.....................................................405.4.3.3-Subdiretrio /dev.......................................................405.4.3.4-Subdiretrio /etc.......................................................415.4.3.4.1-Arquivos e/ou Comandos disponveis em /etc............................................... 415.4.3.5-Subdiretrio /home....................................................425.4.3.6-Subdiretrio /lib.......................................................425.4.3.7-Subdiretrio /mnt......................................................435.4.3.8-Subdiretrio /proc.....................................................435.4.3.9-Subdiretrio /root (opcional)....................................435.4.3.10-Subdiretrio /sbin......................................................445.4.3.10.1-Arquivos e/ou Comandos disponveis em /sbin.............................................. 445.4.3.10.2-Arquivos e/ou Comandos opcionais em /sbin.............................................. 455.4.3.11-Subdiretrio /tmp......................................................455.4.3.12-A hierrquia /usr.......................................................455.4.3.12.1-Subdiretrio /usr (permanente)...........465.4.3.12.2-Subdiretrio /usr/x386........................475.4.3.12.3-Subdiretrio /usr/bin...........................475.4.3.12.4-Subdiretrio /usr/dict..........................475.4.3.12.5-Subdiretrio /usr/etc...........................475.4.3.12.6-Subdiretrio /usr/include.....................485.4.3.12.7-Subdiretrio /usr/lib............................49ndice5.4.3.12.8-Subdiretrio /usr/local........................505.4.3.12.9-Subdiretrio /usr/man.........................505.4.3.12.10-Subdiretrio /usr/bin...........................525.4.3.12.11-Subdiretrio /usr/share.......................535.4.3.12.12-Subdiretrio /usr/src...........................545.4.3.13-A hierrquia /var.......................................................545.4.3.13.1-Subdiretrio /var/adm.........................545.4.3.13.2-Subdiretrio /var/catman.....................555.4.3.13.3-Subdiretrio /var/lib............................565.4.3.13.4-Subdiretrio /var/local........................565.4.3.13.5-Subdiretrio /var/ock.........................575.4.3.13.6-Subdiretrio /var/og............................575.4.3.13.7-Subdiretrio /var/name.......................585.4.3.13.8-Subdiretrio /var/nis...........................585.4.3.13.9-Subdiretrio /var/preview...................585.4.3.13.10-Subdiretrio /var/run..........................585.4.3.13.11-Subdiretrio /var/spool.......................585.4.3.13.12-Subdiretrio /var/tmp..........................595.4.4-Alguns Dilemas sobre o Sistema de Arquivos...............................595.4.5-Descrio sucinta do contedo dos manuais.................................616-Pontos Positivos e Negativos...........................................................................637-Concluso........................................................................................................64ndice9-Apndices........................................................................................................65A-Comandos Bsicos do Sistema Unix........................................................65B-Perguntas mais Frequentes (FAQs) colocadas na Linux-BR..................... 77C-Copyrights Linux e Esquema de numerao verso Linux.......................127D-Contrato de Licena................................................................................1288-Bibliografia e Referncias.................................................................................1341 - Introduo

O Linux um clone UNIX de distribuio livre para PCs baseados em processadores 386/486/Pentium. O Linux uma implementao independente da especificao POSIX, com a qual todas as verses do UNIX padro (true UNIX) esto convencionadas.O Linux foi primeiramente desenvolvido para PCs baseados em 386/486/Pentium, mas atualmente tambm roda em computadores Alpha da DEC, Sparcs da SUN, mquinas M68000 (semelhantes a Atari e Amiga), MIPS e PowerPCs.O Linux foi escrito inteiramente do nada, no h cdigo proprietrio em seu interior.O Linux est disponvel na forma de cdigo objeto, bem como em cdigo fonte.O Linux pode ser livremente distribudo nos termos da GNU General Public License (veja apndice). O Linux possui todos as caractersticas que voc pode esperar de um UNIX moderno, incluindo:

Multitarefa real Memria virtual Biblioteca compartilhada "Demand loading" Gerenciamento de memria prprio Executveis "copy-on-write" compartilhados Rede TCP/IP (incluindo SLIP/PPP/ISDN) X Windows

A maioria dos programas rodando em Linux so freeware genricos para UNIX, muitos provenientes do projeto GNU.Muitas pessoas tem executado benchmarks em sistemas Linux rodando em 80486, e tem achado o Linux comparvel com workstations mdias da Sun e da Digital. O Linux est disponvel atravs 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 usurio final. O Linux tem se tornado uma alternativa efetiva de custo em relao aos caros sistemas UNIX existentes.Um exemplo de pacote de distrribuio do Linux mais populares distribuido pela InfoMagic (http://www.infomagic.com, e-mail info@infomagic.com), a verso LINUX Developers Resource CD-ROM, de dezembro de 1996, contm 6 CD-ROMs, seu contedo sucinto :

Verso Red Hat 4.0 (instalando kernel 2.0.18)Verso Slackware 3.1 (Slackware 96 - instalando kernel 2.0)Verso Debian GNU/Linux 1.2X-Windows - Xfree86 version 3.2 Arquivos Linux de tsx-11.mit.edu e sunsite.unc.eduArquivos GNU de prep.ai.mit.eduDocumnetao completa on-line & HOWTOs (Guia de Instalao e Guia do Administrador da Rede, em ingls)Softwares demostrao comerciais como : BRU, dbMan, StarOffice, Cockpit, Flagship, Smartware, GP Modula-2, Pathfinder, Scriptum, etc. 2. Historia do Linux

O Kernel do Linux foi, originalmente, escrito por Linus Torvalds do Departamento de Cincia da Computao da Universidades de Helsinki, Finlndia, com a ajuda de vrios programadores voluntrios atravs 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 prprias 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 sero homens e escrevero seus prprios "device drivers" ? Voc est sem um bom projeto e esta morrendo por colocar as mos 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 ? Ento esta mensagem pode ser exatamente para voc.

Como eu mencionei a um ms atrs, estou trabalhando em uma verso independente de um S.O. similar ao Minix para computadores AT-386. Ele est, finalmente, prximo do estgio em que poder ser utilizado (embora possa no ser o que voc esteja esperando), e eu estou disposto a colocar os fontes para ampla distribuio. Ele est na verso 0.02... contudo eu tive sucesso rodando bash, gcc, gnu-make, gnu-sed, compresso, etc. nele.

No dia 5 de outubro de 1991 Linus Torvalds anunciou a primeira verso "oficial" do Linux, verso 0.02. Desde ento muitos programadores tm respondido ao seu chamado, e tm ajudado a fazer do Linux o Sistema Operacional que hoje.

Ultimas verses do kernel do Linux

Release v1.0 1.0.9 Data: Sat Apr 16 21:18:02 UTC 1994

Release v1.1 1.1.95Data: 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 Release v2.0 2.0.28 Data: Tue Jan 14 12:33:26 UTC 1997ftp://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 3 - Gerncia de Processos

3.1 - Consideraes Iniciais

Para explicarmos como o Linux gerncia processos, faremos consideraes iniciais sobre o cdigo fonte do kernel do Linux (onde encontramos a implementao da Gerncia de Processos) e a inicializao boot do sistema. Neste tpico tentaremos explicar, de uma maneira ordenada o cdigo fonte do Linux, tentando conseguir um bom entendimento sobre como o cdigo fonte est situado e como as caractersticas mais relevantes do UNIX foram implementadas. O objetivo ajuda-lo a se familiarizar com o projeto geral do Linux. Ento, vamos comear por onde o Linux comea: seu sistema de boot.Um bom entendimento da linguagem C necessrio para entender este material, assim como familiaridade com conceitos de UNIX e arquitetura dos PCs. Porm, nenhum cdigo 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 informaes reportadas aqui tem como referencia o cdigo fonte do Linux verso 1.0. Referencias a verses posteriores contero o smbolo novo. Caso o smbolo no estiver presente, significa que no houveram modificaes aps as verses 1.0.9-1.1.76.mais Ocasionalmente um pargrafo como este ocorrer no texto. Indicando onde poderam ser obtidas mais informaes sobre o assunto corrente (geralmente o cdigo fonte).

3.1.1 - Inicializao ("boot" do sistema)

Quando o PC ligado, o processador 80x86 encontra-se em modo real e executa o cdigo contido no endereo 0xFFFF0, que corresponde a um endereo ROM-BIOS. O BIOS do PC realiza alguns testes no sistema e inicializa o vetor de interrupes no endereo fsico 0. Depois disto ele carrega o primeiro setor do device bootavel em 0x7C00, e passa a execuo para este endereo. O device , usualmente, o disquete ou o disco rgido. A descrio anterior um tanto simplificada, mas tudo que se necessita para entender o trabalho inicial do kernel.A primeirssima parte do kernel Linux est escrito em linguagem assembly 8086 (boot/bootsect.S). Quando executado, ele se move para o endereo absoluto 0x90000, carrega os prximos 2 kBytes de cdigo do device de boot at o endereo 0x90200, e o resto do kernel para o endereo 0x10000. A mensagem "Loading..." apresentada durante o carregamento do sistema. O controle , ento passado para o cdigo contido em boot/Setup.S, outro cdigo assembly de modo real.A parte de "setup" identifica algumas caractersticas do sistema (hardware) e o tipo da placa VGA. Se requerido, pede ao usurio para escolher o modo do vdeo da console. E, ento, move todo o sistema do endereo 0x10000 para o endereo 0x1000, passa para o modo protegido e passa o controle para o resto do sistema (endereo 0x1000).O prximo passo a descompresso do kernel. O cdigo 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 endereo 0x100000 (1 Mega), e esta a principal razo do por que o Linux no pode rodar com menos de 2 Megas de RAM.

mais O encapsulamento do kernel em um arquivo gzip realizado por Makefile e utilitrios no diretrio zBoot. So arquivos interessantes para se dar uma olhada.

novo A verso 1.1.75 moveu os diretrios boot e zBoot para arch/i386/boot. Esta modificao pretendeu possibilitar a construo de "kernel verdadeiro" para diferentes arquiteturas.

O cdigo "descompresso" executado a partir do endereo 0x1010000 , onde todo o setup 32-bit esta lotado: IDT, GDT e LDT so carregados, o processador e o co-processador so identificados, a rotina start_kernel invocada. Os arquivos fonte das operaes acima esto em boot/head.S. Este, talvez, seja o cdigo mais difcil em todo o kernel do Linux.Note que se algum erro ocorrer durante alguns dos passos precedentes, o computador ir travar. O sistema operacional no pode manipular erros enquanto no estiver totalmente operante.start_kernel() reside em init/main.c. Tode de agora em diante esta codificado em linguagem C, exceto gerncia de interrupes e chamadas de sistemas (Bem, a maior parte das macros possuem cdigos assembly embutidos, tambm).Depois dos procedimentos com todas as questes iniciais, start_kernel() inicializa todas as partes do kernel, especificamente:

Inicializa a memria 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 interrupo 16 est trabalhando com o co-processador.

Finalmente, o kernel est pronto para move_to_user_mode(), em seguida fork (bifurca) o processo de inicializao, cujos cdigos esto no mesmo arquivo fonte. E o processo nmero 0, tambm chamado idle task (tarefa preguiosa), se mantm rodando em um loop infinito.O processo de inicializao tenta executar /etc/init, ou /bin/init, ou /sbin/init.Se nenhum deles tem sucesso, o cdigo se desvia para "/bin/sh /etc/rc" e cria um root shell no primeiro terminal (console). Este cdigo remanescente do Linux 0.01, quando o S.O. era feito para um kernel stand-alone, e no havia processo de login.Depois de exec() o programa de inicializao de um dos lugares padro (deve haver um deles), o kernel no tem controle direto sobre o fluxo do programa. Sua funo, de agora em diante, prover processos atravs de chamadas ao sistema (system calls), assim como prover eventos para servios assncronos (como uma interrupo do hardware). A multitarefa est inicializada, e inicializar o gerenciamento de acesso a multiusurios, atravs do fork() e processos de login.Estando o kernel carregado e provendo servio, vamos prosseguir dando uma olhada nesses servios ("system calls").

3.2 - Gerncia de processo pelo kernel

Do ponto de vista do kernel, um processo uma entrada na tabela de processos. Nada mais.A tabela de processos, ento, uma das mais importantes estruturas de dados no sistema, conjuntamente com a tabela de gerenciamento de memria e o buffer cache. O item individual na tabela de processos a estrutura task_struct, definida em include/linux/sched.h. Com a task_struct, tanto informaes de baixo quanto de alto nvel, so mantidas variando da cpia de alguns registradores de hardware at o inode do diretrio de trabalho para o processo.A tabela de processos tanto um array quanto uma lista duplamente ligada, como uma rvore. A implementao fsica um array esttico de ponteiros, cujo tamanho NR_TASKS, uma constante definida em include/linux/tasks.h, e cada estrutura reside em uma pagina de memria reservada. A estrutura da lista est entre os ponteiros next_task e prev_task, a estrutura em arvore um tanto complexa, e no ser descrita aqui. Voce pode desejar mudar NR_TASKS do seu valor default (que 128), mas esteja certo de que h dependncias, e ser necessrio recompilar todos os arquivos fonte envolvidos.Depois do boot, o kernel est sempre trabalhando em um dos processos, e a varivel global "current", um ponteiro para um item da task_struct, usado para guardar o processo que est rodando. A varivel "current" s mudada pelo scheduler, em kernel/sched.c. Quando, porm, todos os processos necessitarem estar looked, a macro for_each_task usada. Isto consideravelmente mais rpido que uma procura seqencial no array.Um processo est sempre rodando em ou em "modo usurio" ou em "modo kernel". O corpo principal de um programa de usurio executado em modo usurio e chamadas a sistema so executados em modo kernel. A pilha usada pelos processos netes dois modos de execuo so diferentes um seguimento de pilha convencional usado para o modo usurio, enquanto uma pilha de tamanho fixo (uma pgina, cujo processo dono) usada no modo kernel. A pgina de pilha para o modo kernel nunca swapped out, porque ela pode estar disponvel sempre que um system call introduzido.Chamadas a sistema (System calls), no kernel do Linux, so como funes da linguagem C, seu nome "oficial" esta prefixado por "sys_". Uma chamada a sistema de nome, por exemplo, burnout invoca a funo de kernel sys_burnout().

mais O mecanismo de chamadas a sistema (System calls) est descrito no captulo 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.3.3 - Criando e destruindo processos

Um sistema UNIX cria um processo atravs da chamada a sistema fork(), e o seu trmino executado por exit(). A implementao do Linux para eles reside em kernel/fork.c e kernel/exit.c.Executar o "Forking" fcil, fork.c curto e de fcil leitura. Sua principal tarefa suprir a estrutura de dados para o novo processo. Passos relevantes nesse processo so:

Criar uma pgina livre para dar suporte task_struct Encontrar um process slot livre (find_empty_process()) Criar uma outra pgina 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() tambm gerencia descritores de arquivos e inodes.

novo A verso 1.0 do kernel possui algum vestgio de suporte ao "threading" (trabalho ou processo em paralelo), e a chamada a sistema fork() apresenta algumas aluses ele.

A morte de um processo difcil, porque o processo pai necessita ser notificado sobre qualquer filhos que existam (ou deixem de existir). Alm 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 acrscimo sys_exit().O cdigo pertencente exit.c no descrito aqui - ele no to 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 esto rodando. Uma delas usualmente executa - exec() - outro programa. A chamada a sistema exec() deve localizar a imagem binria do arquivo executvel, carrega-lo e executa-lo. "Carrega-lo" no significa, necessriamente, copiar na memria a imagem binria do arquivo, para que, assim, o Linux possa atender a demanda de programas a serem executados.A implementao Linux do exec() suporta formatos binrios diferentes. Isto dotado atravs da estrutura linux_binfmt, a qual embute dois ponteiros para funes - um para carregar o executvel e o outro para carregar a "library" associada, cada formato binrio deve conter, portanto, o executvel e sua "library". O sistema UNIX prove, ao programador, seis formas para a funo exec(). Quase todos podem ser implementados como uma "library" de funes, e o kernel do Linux implementa sys_execve() independentemente das providas pelo UNIX. Ele executa uma nica tarefa: carregar o cabealho do executvel, e tenta executa-lo. Se os dois primeiros bytes so "#!", ento a primeira linha ignorada e um interpretador invocado, caso contrrio o formato binrio, registrado, executado seqencialmente.O formato nativo do Linux suportado diretamente por fs/exec.c, e as funes relevantes so load_aout_binary e load_aout_library. Assim como para os binrios a funo de carregamento "a.out" invocada, e a funo mmap() (memory map - memria virtual ) aloca espao em disco (no caso da memria real estar cheia) para o processo, ou invoca read_exec(), caso haja espao em memria. "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 verso 1.1 do kernel, o Linux embutiu um sistema de arquivos (filesystem) revisado do msdos, que suporta mmap() (memory map - memria virtual). Alm disso a estrutura linux_binfmt uma "lista ligada" e no um array, para permitir carregar um novo formato binrio como um mdulo do kernel. Finalmente a estrutura, por si mesma, foi estendida para acessar rotinas com o formato relativo core-dump.

4 - Gerncia de Memria

4.1 - Gerenciamento de Memria do Linux (LMM)

A execuo do LMM (Linux Memory Manager) exige uma estratgia de paginao com uma copy-on-write confiando nas 386 pginas auxiliares. Um processo alcana suas tabelas de pginas de seu parent (durante um fork ) com as entradas marcadas como read-only ou trocado. Ento, se o processo tenta escrever para este espao de memria e a pgina uma copy on write page, isto copiado e a pgina marcada read-write. Um exec ( ) resulta na leitura de uma pgina ou mais do executvel. O processo ento erra em qualquer outra pgina que precisar.Cada processo tem uma tabela de pgina que significa que pode acessar 1 Kb de tabela de pgina indicando para 1 Kb de 4 Kb, pginas que 4 Gb de mmoria. Um diretrio de pgina do processo iniciado durante um Fork por copy-page-tables. O processo inativo tem seu diretrio de pgina inicializado durante a sequncia de inicializao.Cada processo usurio tem uma tabela descritria local que contm um cdigo de segmento e um segmento de dados. Estes segmentos usurios extendem de 0 para 3 Gb (0 X c 0000000). Nos espaos usurios, endereos lineares e endereos lgicos so idnticos.No 80386, endereos lineares vo de 0 Gb para 4 Gb. Um endereo linear indica uma posio particular de memria dentro deste espao. Um endereo linear no um endereo fsico --- isto um endereo virtual. Um endereo lgico consiste de um seletor e um offset. O seletor indica para um segmento e o offset diz que distncia na seo o endereo localizado.O cdigo Kernel e o segmento de dados so sees privilegiados definidos na tabela descritora global e extende de 3Gb para 4Gb. O Swapper - page - dir organizado para que estes endereos lgicos e fsicos sejam idnticos no espao Kernel.O espao 3Gb acima aparece no process page directory como indicadores para tabelas de pginas Kernel. Este espao invisvel para o processo no user mode, mas o modo privilegiado acionado, por exemplo, para sustentar um sistema de ligao. O modo surpevisor inserido dentro do contexto do processo atual ento a traduo do endereo ocorre com respeito ao diretrio de pgina do processo, mas usando segmentos Kernel. Isto idntico no mapeamento produzido com o uso de swapper - pg - dir e segmentos Kernel como ambos diretrios de pginas usa a mesma tabela de pgina neste espao. Apenas task [0] (A tarefa inativa, s vezes chamada de "tarefa trocadora" por razes histricas, mesmo assim isto no tem relao com trocas nos implementos Linux) usa o swapper - pg - dir diretamente.O segmento base do processo usurio = o X 00, page - dir particular, para o processo.O processo usurio faz um sistema de ligao : segment base = 0 X c 0000000 page - dir = mesmo usurio page dir.swapper - pg - dir contm um mapeamento para todas as pginas fsicas de 0 X 0000000 para 0 X c 0000000 + and_mem, ento as primeiras 768 entradas em swapper - pg - dir so 0's, e ento h 4 ou mais que indicam na tabela de pginas Kernel.O user page directories tm as mesmas entradas como swapper - pg - dir dos 768 acima. As primeiras 768 entradas mapeam o espao usurio.A vantagem que sempre que o endereo linear acima de 0 X c 0000000 tudo usa a mesma tabela de pginas Kernel (Kernel page Tables).O monte usurio permanece no topo do segmento de dados do usurio e desce. O Kernel Stack no uma bonita estrutura ou segmento de dados que eu possa apontar com um "aqui um Kernel Stack". Um Kernel Stack_frame (uma pgina) associada com cada 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 no est sendo usado? ]Pginas usurios podem ser roubados ou trocados - Um user page um que mapeado abaixo de 3 Gb em uma tabela de pginas usurios. Esta regio no contm page directories ou page tables. Apenas pginas sujas so trocadas.Menores alteraes so necessrias em alguns lugares ( testes para limites de memria vem para a mente) para prover suporte para definidos segmentos programados. [ H agora uma modificao - |c| + O sistema de ligao usado por dosane, Wine, Twin, and Wabi para criar segmentos arbitrrios. ]

4.2 - Memria Fsica

Aqui est um mapa de memria fsica antes que qualquer processo de usurio for executado. A coluna da esquerda mostra o endereo de partida do item e os nmeros em negrito so aproximados.A coluna do meio mostra os nomes dos itens. A grande coluna da direita mostra a rotina relevante ou o nome varivel ou explicaes para ingresso.

* Projeto - Inits que adquirem memria so (principais.c) profil - buffer, com, init, psaux, init, rd, , init, scsi.dev - init.Note que toda memria no marcada como livre reservada (mem-init). Pginas reservadas pertencem ao Kernel e nunca esto livres ou trocadas.Uma viso de memria do user process.O cdigo 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 no escreve para seu cdigo de espao.De qualquer modo, pegando o sinal segu, possvel escrever para o code space, causando ocorrncia de um copy - on - write. O Handler do_no_page assegura que qualquer pgina nova que o processo adquira pertena ao executvel, uma biblioteca dividida, ao stack, ou dentro do valor do brK.Um usurio de processo pode reordenar seu valor brK chamando sbrK ( ). Isto o que malloc ( ) faz quando precisa. O texto e a poro de dados so distribudos em pginas separadas ao menos que algum escolha o N opo composta. A biblioteca dividida carrega endereos so correntemente tornadas da imagem dividida por ele mesmo.O endereo entre 1.5 Gb e 3 Gb, exceto em casos especiais.4.3 - Distribuio da memria do processo usurio

O Stack, shlibs e os dados so muito afastados um do outro para serem spanned por uma tabela de pgina. Todas KPT so divididas por todos processo e deste modo eles no esto na lista. Apenas pginas sujas so trocadas. Pginas limpas so roubadas e deste modo o processo pode t-los de volta para o executvel se for desejado. A maioria das vezes apenas as pginas limpas so divididas. Uma pgina suja termina dividida sobre um fork at que parent ou child escolham para escrever isto de novo.Administrao dos dados da memria na tabela do processo.Aqui est um sumrio de algum dos dados mantidos na tabela do processo que usado para administrao da memria.Limites do processo da memria.Ulong - start_code - and_code - and_data - brk, atart - stock

Erro de contagem de pgina.

Tabela do descritor local.Sturct desc - sturct ldt {32} a mesa descritora local para tarefa.Nmeros de pginas residentes.Swappable - trocveisSe ento as pginas do processo no sero trocados.Kernel Stack pageIndicador para a pgina distribuda no fork.Saved - Kernel - StackV86 modo material (stuff)stract tsspilha de segmentos (stack segments)indicador da pilha KernelKernel stack pointersegmento da pilha KernelKernel stack segment (0X10)ssi = esp 2 = ss2 = 0Nveis de previlgio no 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 processo1 dt - LDT (n) seletores para tarefas correntes do LDT4.4 - Inicializao da memria

No Start Kernel (main.c) h 3 variveis relatadas para inicializao da memria:

memory_start comea a 1 Mb atualizado pelo projeto de inicializao.memory_endtrmino da memria fsica: 8 Mb, 16 Mb, ou qualquer outro.Low memory_starttrmino do cdigo Kernel e dados que carregado inicialmente

Cada projeto init tipicamente torna memory_start e retorna um valor atualizado, se distribui espaos no memory_start (simplesmente pegando-a). Paging init ( ) inicializa a page-tables no { \ tt swapper - pg - dir} ( comeando a 0 X 0000000) para cobrir toda a memria fsica 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 so adicionados.A primeira pgina zerada para bloquear os indicadores das referncias do alapo nulo no Kernel.No sched_init ( ) o 1 dt e tss descritores para tarefa [0] so 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 preparao para entrada do modo usurio: O cronmetro ligado. O task-struct para task [0] aparece por inteiro em < linux / sched.h >mem_map ento construdo por mem_init ( ) para refletir o corrente uso das pginas fsicas. Este o estado refletido no mapa da memria fsica da seo anterior. Ento Dinux move para dentro do modo usurio com um iret aps empurrar o corrente ss, esp, etc.Claro que o segmento usurio para task [0] so mapeados bem sobre os segmentos Kernel e deste modo a execuo continua exatamente onde isto termina.Task [0]:

pg_dir = swapper - pg - dir que sigmifica apenas endereos mapeados esto no alcance 3 Gb para 3 Gb + High memory.

LTD [1] = cdigo usurio, base = 0 x 0000000, tamanho = 640 KLDT [2] = dados usurios, base = 0 x 0000000, tamanho = 640 k

O primeiro exec ( ) pe a LTD entrada para task [1] para os valores usurios da base = 0x0, limite = task_size = 0 x c 0000000. Depois disso, nenhum processo v os segmentos Kernel enquanto no modo usurio.Processos e a Administrao da Memria.Memria relacionada trabalho feito por fork ( ):distribuio de memria1 pgina para o Task-struct1 pgina para o Kernel Stack1 para o pg_dir e algumas para pg_tables (cpias - pginas - tabelas)Outras mudanassso pe para o segmento Kernel stack (0x10) para ter certeza?espo pe para o topo da nova distribuio Kernel - stack - page.c r 3 pe por copy - page - tables ( ) para indicar para nova pgina de diretrio distribuda1 dt = LDT (task_nr) cria novo 1 dt descritordescritores pe no gdt para novo tss e 1 dt [ ]Os registros restantes so herdados do parent.Os processos resultam dividindo seus cdigos e segmentos de dados (embora eles tenham tabelas descritoras locais separados, as entradas indicam para os mesmos segmentos). O stack e pginas de dados sero copiados quando o parent ou child escreve para eles ( copy-on-write).Memria relacionada trabalho feito por exec ( ):distribuio de memria1 pgina para exec header para omagic1 pgina ou mais para stack (max_arg_pages)clear-pgina-tables ( ) usado para remover pginas velhas.change 1 dt ( ) pe os descritores no novo 1 dt [ ]1 dt [1] = cdigo base = 0 x 00, limite = task - size1 dt [2] = data base = 0 x 00, limite = task - sizeEstes segmentos so dpl = 3, p=1, s=1, g=1. Tipo = a (cdigo or 2 dados)Eleva para MAX_ARG_PAGES pginas sujas de arqu e enup so distribudos e guardado ao topo do segmento de dados para o novo usurio pilha criado.Ponha os indicadores de instruo do caller cip = ex.a_cutryPonha o stack indicador do caller para o stack criado (esp=stack indicador). Este sero eliminados do Stack quando o caller resume.

Limites de Memria Atualizadoscud_code = ex.a_textcud_data = cud_code + &x.d_databrK = end_data + ex._bss

Interrupes e traps so sustentadas dentro do contexto da corrente tarefa. Em particular, o diretrio de pginas do corrente processo usado na traduo de endereos. Os segmentos, de qualquer modo, so segmentos Kernel para que todos os endereos lineares apontem para dentro da memria Kernel quer acessar uma varivel no endereo 0 x 01. O endereo linear 0 x 00000001 (usando segmentos Kernel) e o endereo fsico 0 x 01. O ltimo porque a pgina do processo diretrio mapea esta extenso exatamente como page_pg_dir.O espao Kernel (0 x c 0000000 + high - memory) e mapeado pela tabela de pginas Kernel que so eles mesmos parte da memria reservada. Eles so consequentemente divididas por todos processos. Durante um fork copy-page-tables ( ) trata tabela de pginas reservadas diferentemente. Isto pe indicadores no diretrio de pginas de processo para indicar para tabelas de pgina Kernel e na verdade no distribui novas tabelas de pginas como isto faz normalmente. Como um exemplo o Kernel - Stack - page ( que ocupa algum lugar no espao Kernel ) no precisa de um associado page - table distribudos no pg-dir do processo para mape-lo.O interruptor de instrues pe o indicador stack e o segmento stack do privilgio valor salvo no Tss do corrente task. Note que o Kernel stack um objeto realmente fragmentado - Isto no um objeto nico, mas sim um grupo de stack frames. Cada um distribudo quando um processo criado e deixado quando ele sai. O Kernel stack no deveria crescer to rapidamente dentro de um contexto de um processo que extende abaixo da corrente frame.

4.5 - Adquirindo e liberando memrias

Quando qualquer rotina Kernel precisa de memria isto acaba chamando get-free-page ( ). Este est num nvel mais baixo do que Kmallor ( ) (de fato Kmalloc ( ) get-free-page ( ) quando isto precisa mais memria).Get-free-page ( ) toma um parmetro, a prioridade.Possveis valores so gfp_buffer_gfp, Kernel, gfp,nfs e gfp atomic. Isto tira uma pgina do the free-page-list, atualizados mem_map, zeram a pgina e retorna o endereo fsico da pgina (note que Kmalloc) retorna um endereo fsico. A lgica do mm depende do mapa da identidade entre o endereo lgico e fsico.Isto por ele mesmo bastante simples. O problema claro, que o free-page-list pode estar vazio. Se voc no requisitar uma operao atmica, nesta etapa, voc entra dentro do domnio de uma page stealing e que ns discutiremos em um momento. Como um ltimo recurso ( e para requisitos atmicos) uma pgina separada do secundary-page-list (como voc pode ter achado, quando pginas so libertadas, o secundary-page-list enche primeiro a manipulao 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 interrupes so incapacitados. [Eu penso que isto deveria ser explicado aqui. Isto no to difcil...]Agora de volta ao "Roubando pginas" get-free-page ( ) chame try-to-fre-page ( ) que chame repetidamente shrink_buffers ( ) e swap-out ( ) nesta ordem at conseguir liberar uma pgina. 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:Faa a tabela do processo e adquira uma swappable task, por exemplo, Q.Ache um user page-table (no reservado) no espao de Q.Para cada pgina na tabela try-to-swap-out (page)Termina quando a pgina liberada.

Note que swap-out ( ) (chamada try-to-free-page ( )) mantm variveis estatsticas 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) No brincar com as pginas (reserved) reservadas2) Envelhear a pgina se ela marcada acessada (1 bit)3) No mexa com pgina adquirida recentemente (last-free-pages ( ))4) Deixe pginas sujas com map-counts > 1 intocadas5) Diminua o map-count das pginas limpas6) Librere pginas limpas se elas no so mapeadas7) Troque pginas sujas com um map-count de 1

De todas essas aes, 6 e 7 vo parar o processo poruqe eles resultam na liberao atual de uma pgina fsica.A quinta ao resulta uma dos processos perdendo uma pgina limpa no dividida que no foi acessada recentemente (diminuindo Q rss) que no to ruim, mas os efeitos cumulativos de algumas iterations pode atrasar o processo muito. No presente, h 6 iterations, deste modo uma pgina dividida por 6 processos pode ser roubada se est limpa. Page table ento so atualizados e o TLB invalidado. O trabalho atual de liberar uma pgina feito por free-page ( ), a complementao de get-free-page ( ). Isto ignora pginas reservadas, atualiza mem-map, e libera a pgina e atualiza o page-list (s) se no mapeada. Para troca (em 6 em cima), write-swap-page ( ) chamada e no faz nada notvel da perspectiva da administrao da memria. Os detalhes de shink-buffers ( ) nos levaria muito longe. Essencialmente isto procura free "buffers" (buffers so uma parte da memria que segura informao temporariamente quando dados transferem de um lugar para outro) em seguida escreve buffers sujos, e depois comea com buffers ocupados e chama free-page ( ) quando pode liberar todos os buffers numa pgina.

Note que page directories, page-table, e reserved pages no so trocadas, roubadas ou envelhecidas. Eles so mapeadas no process page directories com reserved page tables. Eles so liberados somente na sada do processo.The page Fault HandlesQuando um processo criado por fork, ele comea com um page directoru e uma pgina ou mais do executvel. Deste modo the page fault handles a forte da maioria da memria do processo. The page fault handles do page-fault ( ) recupera o endereo faltando no registro c r 2. O cdigo do erro ( recobrado no sys-call.s) diferencia o acesso do user / supervisior e a regio para o fault-write proteo de uma pgina faltando. O anterior sustentado pelo do-wp-page ( ) e o posterior pelo do-no-page ( ). Se o endereo 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 proteo do nvel do segmento. Estas rotinas tem algumas sutilezas como elas podem ser chamadas num interrompimento. Voc no ode supor que a tarefa corrente que est executando de-no-page ( ) sustenta trs situaes possveis:1) A pgina trocada2) A pgina pertence a biblioteca executvel ou dividida.3) A pgina est faltando uma pgina de dados no foi distribudaEm todas as causas get-empty-pgtable ( ) chamada primeiro para assegurar a existncia de uma page table que cobre o endereo falatando. No terceiro para providenciar uma pgina no endereo requerido e no caso de uma pgina trocada, swap-in ( ) chamado. No segundo caso, o handles calls share-page ( ) para ver se a pgina pode ser dividida com algum outro processo. Se isto falhar leia a pgina do executvel ou biblioteca (Isto repete a chamada para Share-page ( ) se um outro processo fez o mesmo enquanto isso). Qualquer poro da pgina fora do valor brK zerada.A pgina lida do disco contada como um erro maior. Isto acontece com um swap-in ( ) ou quando lida da executvel ou uma biblioteca. Outras casos so consideradas erros menores (mim-flt). Quando uma pgina divisvel achada ela corite-protected. Um processo que escreve para uma pgina dividida vai precisar passar por um do-wp-page ( ) que faz o copy-on-write.Do-wp-page ( ) faa o seguinte:Mande SIGSEGV se qualquer usar process o est escrevendo para o corrente code-space.Se a pgina velha no dividida, ento simplesmente no proteja-o.Seno get-free-page ( ) and copy-page ( ). A pgina adquirire a bandeira suja da pgina velha. Diminua a conta do mapa da pgina velha.

4.6 - Paginando (Paging)

Paginando a troca numa base da pgina melhor do que os processos inteiros. Ns vamos usar trocando aqui para referir "paginando" , uma vez que apenas Linux pgina, e no trocar, e pessoas so mais acostumadas palavra "Swap" / "trocar" do que "page" / "paginar". Kernel pages nunca so trocadas pginas limpas tambm no so escritas para trocar. Elas so liberadas e recarregadas quando requerida. O trocador mantm um nico bit de informao de envelhecimento nas Pginas acessadas bit da page table cutries - [ O que so os detalhes de manuteno? Como isto usado?]Linux suporta mltiplos swap files ou projetos que podem ser ligados ou desligados pelas ligaes 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 espao no vai ser distribudo neste arquivo. Isto usado por Swapoff quando isto tenta de no usar um arquivo. Quando swapoff adiciona um arquivo de troca nova isto aplica SWP-USED. Um varivel imvel no Swap files armazena o nmero dos arquivos ativos correntemente ativos. Os campos lowest - bit e hihgest - bit limitam a regio livre na pasta de troca e so usadas para adiantar a procura por espao de troca livre.O programa do usurio m | < swap inicializa um swap device ou file. A primeira pgina contm uma assinatura (swap-space) nos ltimos 10 bytes, e contm um mapa de bit. Inicialmente 1's no bitmap significam pginas ruins A'1' no bitmap significa que a pgina correspondente livre. Esta pgina nunca distribuda deste modo a inicializao precisa ser feita somente uma vez.The Syscall Swapor ( ) chamado pelo user program swapon tipicamente de / etc / rc. Algumas pginas da memria so distribudas por swap-map e swap-lockmap, swap-map contm um byte para cada pgina no swapfile. Isto inicializado do bitmap para conter 0 para pginas disponveis e 128 para pginas que no pode ser usadas. Isto para manter uma conta das peties da troca em cada pgina no swap file. Swap-lockmap contm um bit para cada pgina que usada para assegurar excluso mtua quando lendo ou escrevendo swap-files.Quando uma pgina da memria est para ser trocada, um ndice para posio 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 pgina trocada possa ser localizada pela page fault handles, do-no-page ( ) quando necessrio.Os 7 bits mais altos do ndice do o swap file ( ou projeto) e os 24 bits mais baixos do o nmero da pgina neste projeto. Isto faz at 128 swap files, cada um com espao para mais ou menos 64 Gb, mas o espao em cima devido o swap map seria grande. Ao invs o tamanho do swap file limitado para 16 Mb, porque o swap map ento toma 1 pgina.A funo swap-duplicate ( ) usado por copy-page-tables ( ) para deixar o processo da child herdar pginas trocadas durante um fork. Isto somente incrementa a conta mantendo no Swap-map para aquela pgina. Cada processo vai trocar numa cpia da pgina separa quando acess-la. Swap-free diminui a conta mantendo no swap-map. Quando a conta abaixa para 0 a pgina pode ser redistribuda por get-swap-page ( ). Isto chamado cada vez que uma pgina trocada lida na memria ( swap-inc ) ou quando uma pgina est para ser descartada ( free-one-table ( ), etc ).

4.7 - Gerenciamento de Memria Cache

4.7.1 - Arquitetura de Memria 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 caracterstica nica so isto mantem em ordem o mapeamento do processo kernel de algum modo, queira softivare ou hardware. Cdigo especfico 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 cpias de dados que podem ser visto como atualizado pelo processo local.

O funcionamento prprio pode ser relacionado ao TLB e o mapeamento do processo/Kernel page de algum jeito, isto para dizer que eles podem depender um do outro.

Isto pode, numa configurao cached virtual, causar problemas aliasing se uma pgina fisica mapeada no mesmo tempo da que duas pginas virtuais e por causa dos bits de um endereo usado para catalogar a linha cache, a mesma poro do dedo pode acabar residindo no cache duas vezes, deixando resultados incompativis.

Projetos e DMA podem ou no ter capacidade para ver a cpia de um dedo mais atualizado que resida no cache do processo local.

Corretamente, suposto que a coerncia num ambiente multiprocessador mantida pelo subsistema cache/memria. Isto que dizer que, quando um processador requerer um dado no memory bus de maneira e um outro processador tem uma cpia mais atualizada, de qualquer jeito o requesitor vai obter uma cpia atualizada que pertena um outro processador.

(NOTA: SMP arquiteturas sem hardware cache conferece mechansms so realmente possveis, o arquitetura current flush no sustenta isto corretamente, se em algum ponto o Zinux apontar em algum sistema onda isto uma questo debatida, eu vou adicionar os ganchos necessrios mas no vai ser bonito)

Sobre o que o Fluch Architecture se importa: sempre, a viso da administrao de memria hardware de um conjunto de mapeamento do processo Kernel sero consistentes com aqueles do Kernel page tables.Se o memory managemat kernel code faz uma modificao para a user process page modificando o dado via kernel space alias da pgina fsica subjacente, o fio controle de usurio vai ser o dado correto antes que permitido continuar a execuo, indiferente da cache architecture e/ou a semntica.Em geral, quando o estado do espao de endereo mudado somente (em cdigo genrico da administrao da memria 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 no importa: que o mapeamento do DMA DMA/driver coerncia. Isto inclui DMA mappings (no sentido do MMU mappings) e o cache/DMA dado consistncia. Estes tipos des assuntos no devem esta no flush architecture, veja embaixo como eles devem ser manuseados.Split Instrution/data cache consistncia com respeitro as modificaes feito para processo de instruo de espao realizado pelo cdigo 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 vo ser chamados na sequncia seguinte: Fluch-cache-foo(...);modify-address-space ();clush - tlb-foo (...)a lgica aqui : Isto pode ser ilegal num arquitetura dada por um pedao de dado cache para ensitir quando o mapeamento por aquele dado no existe, portanto o flush deve ocorrer antes que a mudana feita.

possivl 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 cpia nova da informao de page table para o TLBvoid flush - cache - all (void);void flush - tlb - all (void);Essas rotinas so para notificar o architecture specific cade que mapeamento do espao do endereo kernel uma mudana foi feita ao kernel address space mappings, que significa que os mapeamentos de todos processos foram efetivamente mudados.

4.7.2 - Implementao da Memria Cache

Uma implementao deve:

Eliminar todos os entradas do cache que so vlidas 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 fsicos, no necessrio realizar uma ao j que mapeamento fsico no 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 nao

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 espao de endereo 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 tambm.

Para Flush-cache-range num virtualmente cached system, todas entradess cache que so nolidas pena a range partem para o fim no address space descrito pelo mm-struect so para ser invalidadas.

Para Flush-tlb-range, qualquer ao necessria para causar o MMUITLB hardware no conter tradues estragados so para ser realizados. Isso significa que quaiquer tradues esto no Kernel page tables no range start para acabar no address space descrito pelo mm-struet so para que a administrao da memoria hardware sera deste ponto avanado, 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 pgina no address dentro do usar space para o address space descrito pelo um area-struet passado esta ocorrendo. Uma efetivao, se necessria, pode obter na mm-struet associado para este address space via uma um - Flags. Este caminho em uma efetivao onde a instruo e dara space no so 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 via uma -um-mm) aplica aqui tambm.

A implemetao deve tambm :

Para flush-cache-range, num virtualmente cache systam, todas entradas cacha que so validas para a pgina no addrees no address space descrito pelo uma so para ser invalidados.

Para flush-tlb-range, qualquer ao necessria para causar o MMU/TLB hardware para no conter tradues estragadas so para ser efetuadas. Isto significa que quaisquer tradues esto nos kernel page tables para a pgina no address space descrito pelo uma passado so para que a administrao de memria hardware, sero vistas deste ponto avanado de qualquer maneira.

4.7.3 - Carregando o Flush-PAGE para a RAM (Unsigned Long Page);

Este o patinho feio. Mas sera semntica necessrio 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 espao kernal para efetuar a cpia da pgina em questo para uma nova pgina. Este apresenta um problema para caches virtualmente catalogados que so write-back escritos de volta na natureza. Neste caso, o Kernel toca duas pginas fisicas no espao Kernel. A sequencia do cdigo 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 cdigos atuais tem sido simplificados para propositos espesificos.

Considere um cache virtualmente catalogados que escrito de volta write-back. Neste momento que a cpia da pgina acontece para o supisto espao kernel, possivel para usar space a viso da pgina original para estar no caches (no endereo do usurio, por exemplo, onde o erro esta ocorrendo). A cpia da pgina pode trazer este dado (para a pgina velha) dentro do caches. Ser tambm colocado o dado (no novo suporte kernel mapeado da pgina) 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 no ser a cpia mais recente do dado. Os caches so estpidos, ento para a nova pgina que estamos dando ao usurio, sem forar o dado cached no suposto kernel para a memria principal o processo ser o contedo velho da pgina. (Por exemplo qualquer lixo que estarem l antes da cpia ter sido feita pelo processamento COW acima).

4.7.3.1 - Exemplo concreto de flush-page

Considere um processo que divide uma pgina, l somente READ-ONLY com maior uma tarefa (ou varias) no endereo virtual Ox2000, no usar space. E para propsito espesficos deixe nos dizer que este endereo virtual mapeia para a pgina fsica 0x14000.

Se a tarefa 2 tenha escrever para a pgina l apenas no endereo 0x2000 ns alteremos um esso e (eventual fragmento do cdigo)mente resultado no code fragment mostrando acima no do-WP-PAGE ( ).O Kernel vai obter uma nova pgina para tarefa 2, deixe-nos dizer que esta e uma pgina fsica 0x2600, e deixe-nos tambem dizer que os mapeamentos do suposto Kernel para pginas fsicas 0x14000 e 0x26000 podem residir em dias nicos linhas cache ao mesmo tempo buscando no esquema da linha catalogada deste cache.O contedo da pgina e copiado do mapeamento Kernel para pgina fsica 0x14000 para uns para pgina fsica 0x26000.Neste momento, numa arquitetura cache virtualmente catalogada write - back nos temos uma inconsistncia potencial. O novo dado copiado dentro da pgina fsica 0x26000 no e necessrio na memria principal neste momento, de fato isto poder estar toda no cache apenas no suposto kernel do endereo fsico.Tambm, o (no modificando, por exemplo, limpo) dado para a (velha) pgina original esta no cache do suposto kernel para pgina fsica 0x14000, isto pode produzir uma inconsistncia mais tarde, ento para proteger isto e melhor eliminar as cpias cached deste dado tambm.Deixe-nos dizer no escrevemos os dados de volta para a pgina no 0x256000 e nos apenas deixamos isto l. Nos retornariamos para a tarefa 2 (Quem teve esta nova pgina agora mapeada no endereo virtual 0x2000) ele completaria sua escrita, ento ele leria algumas outras pores de dados nesta nova pgina (por exemplo, esperando o contedo que existe l antes). Neste momento seo dado e deixado no cache no suposto kernel para nova pgina fsica, o usurio obter o que que estava na memria principal antes da cpia para sua leitura. Isto pode levar a resultados dasastrosos.

4.7.4 - Contedo de uma arquitetura virtual

Numa arquitetura cache virtualmente catalogada, fica o que foi necessrio para fazer a memria principal consistente com a cpia cached da pgina passada do espao kernel.

Nota: Isto na verdade necessrio para esta rotina invalidar linhos em um cache virtual que no escrito de volta write - back na natureza. Para ver porque isto e realmente necessrio, refaa o exemplo acima com a tarefa 1 e 2, mas agora fork ( ) ainda outra tarefa 3 antes dos erros do cow ocorreram, considere o contedo do caches no kernel e user space se a sequencia seguinte ocorre na exata sucesso:

Tarefa 1 l uma parte da pgina no 0x2000Tarefa 2 COW erra a pgina no 0x2000Tarefa 2 efetiva suas escritas para a nova pgina no 0x2000Tarefa 3 COW erra a pgina 0x2000

Mesmo em um cache no escrito devolta virtualmente catalogado, a tarefa 3 pode ver o dado incossistente depois do erro COW se FLUSH-PAGE-TO-RAM no invalida a pgina fsica do suposto kernel do cache.

VOID-UP-DATE

Embora no estritamente parte da arquitetura flush, em certas arquiteturas algumas operaes 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 pgina no 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 pginas que traduzem para a exata pgina fsica, e devido ao algarismo catalogado do cache pode tambm residir na nica e mutualmente exclusiva linhas cache.Se um BAD ALIAS detectado, uma implementao precisa resolver esta inconsistncia de alguma maneira, uma soluo e andar atravs de todo os mapeamentos e mudar as page-tables para fazer estas pginas como no concreveis se o hardaware permite tal coisa.As conferncias para isto so muito simples, tudo que uma implementao precisa fazer :Se ((uma -Um - Flags 6 (Um - Write/Um - Shared)) confere sua potncia mau supostas, ento para o caso comum (mapeamento escrevveis devidos so extremamente raros) apenas uma comparao necessitada para sistemas COW CAHCES virtualmente catalogados.

4.7.5 - Implicaes Referentes a Arquitetura4.7.5.1 - Arquitetura baseada no Modelo SMP

Dependendo da arquitetura certos consertos podem ser necessrios para permitir a arquitetura FLUSH para trabalhar num sistema SMP.O principal assunto e se uma das operaes 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 necessrio. Os dois correntes sistemas SMP suportados no LiNUX (intel e space) usam inter-processor interrupts para transmitir a operao FLUSH e faz isto correr localmente em todo processador se necessrio como um exemplo, no sistema SUNHM Space todos precessadores no sistema precisam executar o pedido FLUSH para garantir a consistncia atravs do sistema inteiro. De qualquer modo, nas mquinas SUNHD Space, TLB FLUSHES efetivamente no processador local so transmitidos sobre o BUS-SYSTEM pelo hardware e desta forma uma ligao cruzada no e necessria

4.7.5.2 - Implicaes para arquitetura baseados no contexto MMU/CACHE.

A idia inteira por trs 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 coerncia descrita acima, requer-se algumas consideraes extras do implementador.As questes envolvidas variam muito de uma implementao para outro, pelo menos esta tem sido a experincia do autor. Mas em particular algumas destas questes so provavelmente para ser:

A relao do mapeamento do espao Kernel para os USER-SPACE, num contexto so convertidas, alguns mapeamentos do sistema kernel tem um atributo global, naquele o hardware no concerde ele mesmo com o contexto da informao quando uma traduo 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 possvel um outros implementaes para o Kernel para dividir o contexto chave associado com um ADDRESS SPACE particular. Pode ser necessrio em tal caso andar por todos contextos que so contentemente vlidos e efetuam o Flush completo em cada um para um Kernall Address Space Flush.O custo por contexto Flush podem tornar uma questo chave, especialmente com respeito ao TLB. Por exemplo, se um Tlb Flush e necessrio, em um grande Range de endereos (ou um inteiro Address Space) pode ser mais prudente distribuir e assumir um nova contexto MMU/para este processo por causa da eficincia

4.7.6 - Como tratar o que a arquitetura flush no executa com exemplos

A arquitetura Flush descrita no faz emendas para coerncia de projetos DMA com dados Cached. Isto tambm no tem provises para nenhuma estratgia de mapeamento necessrios pelo DMA e projetos se forem necessrios em um certa mquina Linux Portad To.Nenhuma destas questes so para a arquitetura Flush.Tais questes so negociadas mais claramente no nvel do Driver do projeto. O autor est mais convencido disto depois de sua experincia com um conjunto comum de sparc device drivers que precisaram de toda funo corretamente em mais do que uma hand full de cache/mmu e bus architetures no mesmo kernel. De fato esta implementao mais eficiente porque o motorista sabe exatamente quando o DMA precisa ver o dado consistente ou quando o DMA est indo criar uma inconsistncia 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 so 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 so passadas por um indicador ou um conjunto de indicadores e especificaes de tamanho para res no espao kernel para que o DMA ocorra, eles retornam para o endereo 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) endereo(s) DMA para que recursos 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 so ordenados em uma base por-bus.

4.7.7 - Questes 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 so escreviveis!). Da nota est o mipsr4000 que dar uma exceo quando tal situao ocorre, elas podem ocorrer quando o processamento cow est acontecendo na corrente implementao. 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 excees durante o processamento cow e seus efeitos que ocorrero na performance cow, que essencialmente est para flush um user space page e se no o fazendo ento 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 mudanas para o codigo networking. claro que, a arquitetura flush sempre sujeita a aperfeioamentos e mudanas para buscar novas questes ou novos hardwares que apresentam um problema que estava at este ponto desconhecido

5. Sistema de Arquivo no Linux (File System)

5.1. - Conceitos Fundamentais5.1.1 - Arquivos

Conceitualmente, arquivos so mecanismos de abstrao que fornece uma forma de armazenar e recuperar informaes em disco. A caractersticas mais importante de qualquer mecanismo abstrao 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 execuo, o arquivo continua a existir, podendo ser acessado por outros processos, usando para tanto o nome atribuido ao arquivo.O Linux faz distino entre nome maisculos e minsculos. Normalmente um nome de arquivo composto de nome e uma extenso, separada por ponto no Linux, o tamanho da extenso, se houver, fica a critrio do usurio, e uma arquivo pode at ter duas ou mais extenes, exemplo : prog.c.Z.No h limite de nmeros de caracteres utilizados para dar nome a arquivos. O Sistema Operacional Linux, olha o arquivo como uma sequncia de byte, sem nenhuma estrutura, isto d uma flexibilidade espantosa ao sistema de arquivo. Os programas de usurios, podem colocar o que desejarem nos arquivos e identific-los da forma que lhe for mais conveniente, o Unix no influncia em NADA nesta processo de identificao.5.1.2 - Diretrios

Para tratar dos arquivos, o sistema operacional normalmente lana mo do diretrios, no caso do Linux diretrios hierrquico,vide figura 01. Os diretrios so um tipo de arquivo.

No Linux todos os arquivos fazem parte de um diretrio, assim eles so mantidos e organizados, os diretrios so meios de oferecer endereos dos arquivos, de maneira que o SO possa acess-los rapidamente e facilmente, ao entra pela primeira vez em sua conta, o usurio j esta em um subdiretrio denominado subdiretrio de entrada.

5.1.3 - Conta

uma senha que aberta pelo administrador do sistema (denominado de root) onde o usurio indentifica-se para o computador, que ento d acesso ao seu diretrio de entrada, onde voc pode executar os comandos permitidos a sua senha. Nos SO padro Unix, a conta obrigatria para todos, a figura 02 mostra um exemplo de abertura de conta no Linux.

Figura 02

Linux 2.0.0 (carvalho.cpd.ufg.br) (tte p0)carvalho login: rootPassword:Ast login: Wed Jan 29 12:16:37 from jacaranda.cpd.ufLinux 2.0.0.carvalho:~$

5.1.4 - Tipos de arquivos

O Linux suporta arquivos regulares, arquivos de diretrio, arquivos especiais de caracteres e arquivos especiais blocados.

Os arquivos regulares so aqueles que contm informaes de usurios, por exemplos, tipo ASCII. Arquivos diretrios so arquivos usado na manuteno do sistema de arquivo. Arquivos especiais de caracteres esto diretamente ligado entrada/sada e so usados para dispositivos seriais de entrada/sada, tais como terminais, impressoras e rede. Os arquivos especiais blocados so usado modelar dispositivos. Um exemplo de tipos de arquivos utilizados no Linux pode ser visto na figura 03.

Figura 03carvalho:/usr$ lsX11@ etc/lib/spool@X11R6/games/local/src/X386@i486-linux/man/tclX/adm@i486-linuxaout/opemwin/tkX/bin/i486-sesv4/prerve@tmp@dict/include/sbin/doc/info/share/ftpusersmtools.conf sesog.confcarvalho:/usr$

5.1.5 - Acesso a arquivos

O Sistema Operacional Linux, bem como os demais SO, trata o acesso a arquivos de forma radmica, ou seja, seus byte ou registros podem ser lidos em qualquer ordem.

5.1.6 - Atributos dos arquivos

Cada arquivo tem necessariamente um nome e um conjunto dados. Alm disso, o Sistema Operacional associa a cada arquivo algumas outras informaes que chamaremos de atributos de arquivos. A figura 04, nos mostra alguns dos atributos dos arquivos. Figura 04carvalho:/etc$ ls -ltotal 11 lrwxrwxrwx 1 root root 9 Dec 9 14:01 rmt -> /sbin/rmt*-rw-r--r-- 1 root root 743 Jul 31 1994 rpc-rw-r--r-- 1 root root 86 Jan 28 1994 securette -rw-r--r-- 1 root root 21394 Dec 9 14:22 sendmail.000-rw-r--r-- 1 root root 23580 Jan 6 12:28 sendmail.cfdrwxr-xr-x 2 root root 1024 Dec 9 13:59 skel/-rw-r--r-- 1 root root 314 Jan 9 1995 slip.hosts-rw-r--r-- 1 root root 342 Jan 9 1995 slip.loginlrwxrwxrwx 1 root root 13 Dec 9 13:59 utmp -> /var/og/utmplrwxrwxrwx 1 root root 13 Dec 9 13:59 wtmp -> /var/og/wtmp-rw-r--r-- 1 root root 76 Mae 8 1995 e p.conf.exampleComo vimos neste exemplo, o Sistema de Arquivo do Linux permite restringir o acesso aos arquivos e diretrios permitindo que somente determinados usurios possam acess-los. A cada arquivo e diretrio associado um conjunto de permisses. Essas permisses determinam quais usurios podem ler, escrever, ou alterar um arquivo, e no caso de arquivos executveis como programas, quais usurios podem execut-lo. Se um usurio tem permisso de execuo de um diretrio, significa que ele pode realizar buscas dentro daquele diretrio, e no execut-lo como se fosse programa. Passaremos a explicar a codificao, escolhemos aleatoriamente o stimo arquivo skel/ da figura 04 :

drwxr-xr-xnome do arquivo12345678910skel/obs : o que est em negrito,caixa maior, corresponde a posio do arquivo skel/1 - informa o tipo de arquivo (d(diretrio,l ( link, - (demais arquivo)2 - Permisses do Proprietrio (r ( leitura, , - no permitida leitura )3 - Permisses do Proprietrio (w ( escrita, - no permitida escrita)4 - Permisses do Proprietrio (x ( execuo, - no permitida execuo)5 - Permisses do Grupo (r (leitura, , - no permitida leitura )6 - Permisses do Grupo (w ( escrita, - no permitida escrita)7 - Permisses do Grupo (x ( execuo, - no permitida execuo)8 - Permisses do Sistema (r ( leitura, , - no permitida leitura )9 - Permisses do Sistema(w ( escrita, - no permitida escrita)10 -Permisses do sistema (x ( execuo, - no permitida execuo)

5.2 - Operaes sobre arquivos

Os arquivos existem para armazenar informaes e permitir a sua recuperao. As Chamadas de Sistemas mais comum relacionadas ao Sistema de Arquivo Linux so chamadas que operam sobre arquivos individuais ou envolvendo diretrios e sistema de arquivos como um todo .A chamada CREAT no s cria um arquivo, mas tambm abre esta arquivo para escrita, indepedente do modo de proteo especificado para ele. O descritor de arquivo que a chama retorna, fd, pode ser usado para escrever no arquivo. Se a chamada CREAT for executada sobre um arquivo existente, esta arquivo ser truncado para o comprimento 0, desde que os direitos do arquivos assim o permitam.Para que um arquivo existente possa ser lido ou escrito, necessrio que ele seja primeiramente aberto e se ele esta aberto para leitura, escrita ou para ambas as operaes. Vrias opes podem ser especificadas. O descritor de arquivo que a chamada retorna pode ento ser usado para leitura ou escrita. Posteriormente, o arquivo deve ser fechado atravs da chamada CLOSE, cuja execuo torna o descritor de arquivo disponvel para ser novamente utilizado numa chamada CREAT ou OPEN subseqente.A chamada READ utilizada para ler o arquivo, os bytes lidos vm em posio corrente de leitura. O processo que faz a chamada deve indicar a quantidade de informao a ser lida e providenciar um buffer para possibilitar a leitura. A chamada WRITE, os dados so escritos no arquivo, geralmente a partir da posio corrente. Se tal posio for a de final de arquivo, o tamanho do mesmo cresce. Se a posio corrente no momento da escrita estiver no meio do arquivo, os dados existente nesta posio estaram perdidos para sempre, pois a operao de write escreve os novos dados em cima dos antigos.Apesar da maioria dos programas ler e escrever arquivos sequncialmente, em algumas aplicaes os programas devem ser capaz de acessar randomicamente qualquer parte do arquivo. Associado a cada arquivo, existe um ponteiro que indica a posio corrente do arquivo. Quando a leitura ou escrita for seqncial, em geral, ele aponta para o prximo byte a ser lido ou a ser escrito. A chamada LSEEK tm trs parmetros: o primeiro do descritor de rea para o arquivo, o segundo a posio do arquivo, o terceiro informa se a posio relativa ao inicio do arquivo, posio corrente ou final do arquivo. O valor que o LSEEK retorna a posio absoluta no arquivo aps a mudana no ponteiro.Para cada arquivo o Linux mantem o modo do arquivo (regular, diretrio ou arquivo especial), seu tamanho, o instante da ltima modificao, e outra informaes pertinentes. Os programas podem verificar estas informaes, usando a chamada STAT. Seu primeiro parmetro o nome do arquivo. O segundo um ponteiro para a estrutura onde a informao solicitada deve ser colocada. As chamadas do sistema relacionadas com os diretrios ou com o sistema de arquivo como um todo , em vez de um arquivo especficos. Os diretrios so criados utilizando as chamadas MKDIR e RMDIR, respectivamente. um diretrios o pode ser removido se estiver vazio.A ligao de um arquivo cria uma nova entrada no diretrio que aponta para um arquivo existente. A chamada LINK cria esta ligao. Os seus parmetros especificam os nome originais e novo, respectivamente. As entrada do diretrios so removidas via UNLINK. Quando a ltima ligao para um arquivo removida, automaticamente apagada . Para um arquivo que nunca foi ligado, o primeiro UNLINK faz com que ele desaparea.Os diretrios de trabalho especificado pela chamada CHDIR. Sua execuo faz com que haja mudana na interpretao dos nome dos caminhos realtivos.A chamada CHMODE torne possvel a mudana do modo um arquivo, ou seja, de seus bits de proteo.

5.3 - Arquivos Compartilhados

Quando vrios usurios esto trabalhando juntos em um projeto, ele comumente precisam compartilhar arquivos. Em decorrncia disto, muitas vezes conveniente que um arquivo compartilhado aparea simultneamente em diretrios diferentes que pertenam a diferentes usurios. A coneco entre um diretrio e um arquivo compartilhado chamada de ligao (link). O prprio sistema de arquivo um grfico acclico dirigido , ou DAG, em vez de rvore. No Linux os blocos do disco no so listados no diretrio, mas numa estrutura de dados associada ao prprio arquivo. Esta estrutura chamada n-i, a forma como o Linux implementa compartilhamentdo arquivo.

5.4 - Estrutura do Sistema de arquivos do LINUX Release 1.2

5.4.1 - Apresentao

Este trabalho baseado na verso 1.2 da Estrutura do Sistema de arquivos do LINUX (LINUX File System Structure) FSSTND, que por sua vez baseado em um documento de consenso da comunidade Linux (que poder ser encontrado na internet -www.linux .org) o layout do sistema de arquivos foi inicialmente desenvolvido dentro da lista de e-mail FSSTND do LINUX-ACTIVISTS. O coordenador do FSSTND Daniel Quinlan . Uma parte considervel deste trabalho foi tirado da FAQ (Lista de perguntas mais frequentes) mantida por Ian McCoghrie (FSSTND-FAQ). Este documento est disponvel via ftp anonymous em tsx-11.mit.edu no diretrio /pub/linux/docs/linux-standards/fsstnd/ FSSTND-FAQNosso trabalho enfocar a estrutura do sistema de arquivos para LINUX tpico, incluindo a localizao de arquivos e diretrios, e o contedo de alguns arquivos de sistema.

5.4.2 - Caractersticas Sistema de Arquivos

O sistema de arquivos Linux esta caracterizado por:

Uma estrutura hierrquica.Um tratamento consistente da informao dos arquivos.Proteo dos arquivos.

O sistema de arquivos Linux segue o mesmo princpio bsico que a maioria dos sistemas de arquivos UNIX seguem. Apesar que o sistema de arquivo no concordar em 100% com cada aspecto possvel de alguma implementao particular do sistema UNIX. De qualquer forma, muitos dos aspectos da implementao do sistema de arquivos esto baseados em idias encontradas em sistemas similar ao UNIX system V, outros fatores tambm foram levado em conta tais como :Prticas comuns na comunidade LINUX.A implementao de outras estruturas de sistemas de arquivos. Definio das categorizao ortogonal de arquivos: Compatvel vs. no comptivel. e varivel vs. estticos.

A informao compatvel aquela que pode ser compartida entre vrias mquinas diferentes. A no compatvel aquela que deve ser localizada em uma mquina particular. Por exemplo, os diretrios local dos usurios so compatvel, porm os arquivos de bloqueio do dispositivo (lock file) no so compatveis.A informao esttica inclui arquivos, biblilotecas, documentao e tudo aquilo que no precisa da interveno do administrador do sistema. A informao varivel tudo aquilo que se troca com a interveno do administrador.O entendimento destes princpios bsicos ajudar a guiar a estrutura de qualquer sistema de arquivos bem planejado. A distino entre informao compatvel e no compatvel necessria por vrias razes:Em um ambiente de rede, existe uma boa quantidade de informao que se pode compartilhar entre diferentes mquinas para o aproveitamento de espao e facilitar a tarefa da administrao.Em um ambiente de rede, certos arquivos contm informao especifica de uma s mquina, portanto, estes sistemas de arquivos no podem ser compartilhados (antes de tomar medidas especiais).As implementaes de fato do sistema de arquivos no nos permitem que a hierrquia /usr fosse montada somente para leitura, porque possua arquivos e diretrios que necessitavam ser escritos muito freqentemente. Este um fator que deve ser atacado quando algumas parte de /usr so compartilhadas na rede.A distino "compatvel" pode ser usada para suportar, por exemplo:

uma partio /usr (o componente de /usr) montada (somente para leitura) atravs da rede (usando NFS).

uma partio /usr (o componente de /usr) montada somente para leitura de um cd-rom, pode ser considerado como um sistema de arquivos somente para leitura, compartilhado com outros sistemas LINUX utilizando o sistema de e-mail como uma rede.A distino "esttica" contra "varivel" afeta o sistema de arquivos de duas maneiras principais:Arquivo da /(raiz) contm ambos tipos de informao, varivel e esttica necessita permitir leitura e escrita.Arquivo do /usr tradicional contm ambos tipos de informao varivel e esttica e os arquivos poderamos desejar montar-los somente para leitura, necessrio proporcionar um mtodo para fazer que /usr funcione somente para leitura. Isto se faz com a criao de uma hierrquia /var que funciona leitura e escrita (ou parte de uma partio leitura-escrita tal como /), que diminui muito a funcionalidade tradicional da partio /usr.O diretrio raiz / . Esta sesso descreve a estrutura do diretrio raiz. O contedo do sistema de arquivos raiz ser adequado para carregar, dar boot, restaurar, recuperar o sistema:

Para carregar o sistema, deve estar presente o suficiente como para montar /usr e outras parte no essenciais do sistema de arquivos.Esta inclui ferrramentas, informao do configurao e do boot de inicializao (boot loader) e algum outra informao essenciais ao inicilizar.Para habilitar a recuperao e /ou a reparao do sistema, estar presente no sistema de arquivos raiz aquelas ferrramentas que o administrador experimentado necessitaria para diagnosticar e reconstruir um sistema danificado .Para restaurar um sistema, estaram presente no sistema de arquivos raiz aquelas ferrramentas necessrias para restaurar o sistema em floppy , fitas, etc.A principal preocupao e que procuraremos colocar muito pouca coisas do sistema de arquivos raiz, a meta de manter / to pequeno quanto possvel. Por vrias razes desejvel mante-lo pequeno. freqentemente montado em mdia muitas pequenas. Por exemplo muitos usurios de LINUX instalam e recuperam sistemas montando como o disco copiado de disquete 1.44Mb.O sistema de arquivos / tem muitos arquivos de configurao especificos de um sistema. Possveis exemplos so de um kern, que especficos do sistema, um hostname diferente, etc. Isto significa que o sistema de arquivos / no sempre compatvel entre sistemas em rede. Mantendo-o pequeno no sistemas de rede, se minimiza o espao perdido no servidor utilizados pelos arquivos no compatvel. Tambm permite estaes de trabalho com winchesters locais menores.Os erros do disco, que corrompe as informao no sistema de arquivos / so um problema maior que os erros em qualquer outra partio. Um sistema de arquivos / pequeno menos propenso a perder arquivos como resultado de uma falha do sistema. recomendvel colocar principalmente os arquivos em /etc/mtab. De qualquer forma, no se necessita que o sistema de arquivos / esta totalmente armazenado localmente. A partio / no tem porque estar armazenada localmente pode ser especificada pelo sistema por exemplo, poderiam estar montada de um servidor NFS. O software no dever criar ou pedir arquivos de subdiretrios especiais. A estrutura do sistema de arquivos LINUX proporciona suficiente flexibilidade para qualquer pacote.

5.4.3 - Composio dos Diretrios

/ --- O Diretrio Raiz

A composio do diretorio raiz de um sistema Linux tpico pode ser representado pela Tabela 01.

Tabela 01 bin arquivos executveis(binrios) de comandos essenciais pertencentes ao sistema e que so usados com freqencia. boot arquivos estticos de boot de inicializao(boot-loader)dev arquivos de dispositivos de entrada/sadaetc Configurao do sistema da mquina local com arquivos diversos para a administrao de sistema.home diretrios local(home) dos usurios.lib arquivos da biblilotecas compartilhadas usados com freqenciamnt Ponto de montagem de partio temporriosroot Diretrio local do superusurio (root)sbin Arquvios de sistema essenciaistmp arquivos temporrios gerados por alguns utilitriosusr todos os arquivos de usurios devem estar aqui (segunda maior hierrquia)var Informao varivelCada diretrio listado ser discutido em detalhe em uma subsesso separada mas adiante. /usr e /var, cada un tem seu prpria sesso de documentos. O kern do LINUX estaria localizado na raiz / ou no /boot. Se estiver localizado em / recomendado usar O nome VMLINUX o VMLINUZ, nome que dever ser usados em programas fonte do kern do LINUX recentemente. Mais informao da localizao do kern pode-se encontar na sesso sobre a raiz / neste trabalho.

5.4.3.1 - Subdiretrio /bin

Composio : Arquivos Binrios de comandos essenciais de usurios (disponveis para todos os usurios).

Contm os comandos que podem ser utilizados pelos usurios e pelo administrador do sistema, porm que so requeridos no modo mono-usurio (single-user mode) pode tambm conter comandos que so utilizados indiretamente por alguns scripts. Todos os arquivos utilizados somente pelo root, tal como daemons, init, gette, update, etc. Estariam localizados em /sbin ou /usr/sbin dependendo se so ou no essenciais. No abra subdiretrios dentro /bin.Os arquivos dos comandos que no so suficientemente essenciais para estar em /bin estaram localizados em /usr/bin, os elementos que so utilizados pelos usurios isoladamente (porm no pelo root) (mail, chsh, etc.) no so suficientemente essenciais para estar dentro da partio /.

5.4.3.1.1 - Arquivos e/ou comandos disponveis em bin

Os arquivos que devem estar em /bin so : comandos gerais e comandos de rede.

Comandos gerais:

Os seguintes comandos devero sido includos porque so essenciais.Alguns estaram presente e tradicionalmente devero estado em /bin.{arch, cat, chgrp, chmod, chown, cp, date, dd, df, dmeg, echo, ed, false, kill, in, login, mkdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, sed, setserial, sh, sfte , seu, sinc, true, umount, uname}. Se /bin/sh bash, ento /bin/sh seria em links simblico a /bin/bash dado que bash se comporta diferente quando carregado como sh ou bash. A pdksh que pode ser a /bin/sh nos discos de instalao e seria igualmente carregada a que /bin/sh faz um links simblico a /bin/ksh. Outros links simblicos de sistemas utilizando outros programas, ento a partio / conter os componente mnimos necessrios.Por exemplos, muitos sistemas incluiria cpio como de segunda utilidade mais usado para reparos depois do tar. Porm jamais se espera restaurar o sistema da partio /, ento estes arquivos podem ser omitidos (montar / em chip ROM, montar /usr no NFS). Se a restaurao do sistema se planeja atravs da rede, Ento FTP o TFTP (junto com todo o necessrio para obter uma conexo FTP) estariam disponveis na partio /.Os comandos de restaurao podem aparecer em /bin ou /usr/bin em sistemas LINUX diferentes.Comandos de redes.

Estes so unicamente os arquivos de rede que os usurios e o root queiram ou necessitem executar que no estejam no /usr/bin ou /usr/local/bin {domain name, hostname, netstat, ping}.

- Subdiretrio /boot:

Composio : arquivos estticos do boot de inicializao (boot loader).

Este diretrio contm tudo que necessrio para carregar o sistema, exceto os arquivos de configurao e o gerenciador de boot. O /boot utilizado para qualquer coisa que se utiliza antes do kernel execute /sbin/init. Este inclui setores master de inicializao (master boot sectors) guardados, arquivos de mapa de setor e qualquer outra coisa que no editada manualmente. Os programas necessrios para consertar o boot de inicializao e capaz de carregar um arquivo (tal como o gerenciador de boot [lilo]) estaram localizados em /sbin. Os arquivos de configurao para carregar de inicializao poderiam estar localizados em /etc.Como o exposto acima, o kern do LINUX pode estar localizado em / ou /boot, se estiver em /boot, recomendado usar um nome mais descritivo.

5.4.3.3 - Subdiretrio /dev

Composio : arquivos de dispositivos de entrada/sada.

Este diretrio dos dispositivos. Contm um arquivo para cada dispositivo que o kern do LINUX pode suportar./dev tambm contm. um script carregado MAKEDEV o qual pode criar dispositivos quando necessitar. Pode conter um MAKEDEV local para dispositivos locais.MAKEDEV deve fazer previso para criar qualquer arquivo de dispositivo especial listado na lista de dispositivos suportados pelo Linux.Os links simblicos no devem ser distribuidos no sistemas LINUX, somente como preve na lista de dispositivos de LINUX. Isto porque as instalaes locais seguro diferem daquelas da mquina do administrador. Alm disso, um script de instalao configura links simblicos na instalao, estes ligao seguramente no se atualizaram se houverem trocas locais no hardware. Quando utilizados responsavelmente so de bom uso.A lista de dispositivos compatvel com o LINUX, mantida por Peter Anvin (peter.anvin@linux.org). Estes arquivos especial de dispositivo esto disponvel no endereo eletrnico da internet ftp.eggdrassiml.com, no diretrio /pub/device-list.5.4.3.4 - Subdiretrio /etc

Composio : Configurao do sistema da mquina local com arquivos diversos para a administrao de sistema.

Contm arquivos e diretrios que so locais ao sistema atual.

Nenhum arquivo deve ir diretamente dentro /etc. Os arquivos que nas primeiras verses encontravam-se em /etc, ir em /sbin ou /usr/sbin. Isto inclui arquivos tal como init, gette e update, arquivos como hostname que so utilizados por usurios comuns e pelo root no iriam em /sbin seriam em /bin.

Subdiretrios de /etc

Tipicamente /etc possui dois sudiretrios :

X11 arquivos