Curso Completo-Linux e avançado, Notas de estudo de Matemática

Baixe Curso Completo-Linux e avançado e outras Notas de estudo em PDF para Matemática, somente na Docsity! Índice 1 Introdução................................................................................. ...................... 6 2 Histórico do Linux................................................................................. .......... 8 3 Gerência de Processos........................................................................... .......... 10 3.1 Considerações Iniciais....................................................................... ...... 10 3.1. Inicialização (“boot” do sistema)................................................. 10 3.2 Gerência do Processo pelo kernel............................................................ 12 3.3 Criando e Destruindo um Processo......................................................... 13 3.4 Executando Processos.................................................................... ........ 13 4 Gerência de Memória............................................................................. .......... 15 4.1 Gerenciamento de Memória do Linux..................................................... 15 4.2 Memória Física.......................................................................... ............. 16 4.3 Distribuição da Memória do Processo Usuário........................................ 17 4.4 Inicialização da Memória..................................................................... ... 18 4.5 Adquirindo e Liberando Memória........................................................... 19 4.6 Paginação (Paging)...................................................................... ........... 22 4.7 Gerenciamento de Memória Cache.......................................................... 23 4.7. Arquitetura de Memória Cache do Linux (Linux Flush Architecture) .................................................... .......................... 4.7. Implementação de Memória Cache.............................................. 24 4.7. Arquitetura Baseada no SMP....................................................... 2 4.7.3.1- Arquitetura Baseada no contexto MMU/CACHE...... 27 4.7. Conteúdo de uma Arquitetura Virtual.......................................... 27 Índice 2 5.4.3.2- Subdiretório /boot.................................................. ... 40 5.4.3.3- Subdiretório /dev................................................... .... 40 5.4.3.4- Subdiretório /etc.................................................... ... 41 5.4.3.4.1- Arquivos e/ou Comandos disponíveis em /etc.................................. ............. 5.4.3.5- Subdiretório /home................................................ .... 42 5.4.3.6- Subdiretório /lib..................................................... .. 42 5.4.3.7- Subdiretório /mnt.................................................. .... 43 5.4.3.8- Subdiretório /proc.................................................. ... 43 5.4.3.9- Subdiretório /root (opcional).................................... 43 5 5.4.3.10 - Subdiretório /sbin.................................................. .... 44 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................................ .............. 5.4.3.11 - Subdiretório /tmp................................................... ... 45 5.4.3.12 - A hierárquia /usr................................................... .... 45 5.4.3.12.1 - Subdiretório /usr (permanente)........... 46 5.4.3.12.2 - Subdiretório /usr/x386........................ 47 5.4.3.12.3 - Subdiretório /usr/bin.......................... . 47 5.4.3.12.4 - Subdiretório /usr/dict......................... . 47 6 5.4.3.12.5 - Subdiretório /usr/etc........................... 47 5.4.3.12.6 - Subdiretório /usr/include.................... . 48 5.4.3.12.7 - Subdiretório /usr/lib........................... . 49 Índice 5.4.3.12.8 - Subdiretório /usr/local........................ 50 5.4.3.12.9 - Subdiretório /usr/man........................ . 50 5.4.3.12.1 0- Subdiretório /usr/bin.......................... . 52 5.4.3.12.1 1- Subdiretório /usr/share....................... 53 5.4.3.12.1 2- Subdiretório /usr/src........................... 54 5.4.3.13 - A hierárquia /var.................................................... ... 54 5.4.3.13.1 - Subdiretório /var/adm......................... 54 7 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 10 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. 11 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 12 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) 15 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. 16 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. 17 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. 20 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 21 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 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 22 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). 25 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 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. 26 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. 27 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. Os processos resultam dividindo seus códigos e segmentos de dados (embora eles tenham tabelas descritoras locais separados, as 30 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 é 31 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. 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. 32 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: 35 • 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 imóvel no Swap files armazena o número dos arquivos ativos correntemente ativos. Os campos lowest - bit e hihgest - bit limitam 36 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 37 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); void flush - tlb - all (void); 40 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 41 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 via uma -um-mm) aplica aqui também. A implemetação deve também : 42 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. 45 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 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 46 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 47 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 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 50 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 51 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 52 Figura 03 carvalho:/usr $ ls X11@ etc/ lib/ spool@ X11R6/ games/ local/ src/ X386@ i486-linux/ man/ tclX/ adm@ i486- linuxaout/ opemwin/ tkX/ bin/ i486-sesv4/ préerve@ tmp@ dict/ include/ sbin/ doc/ info/ share/ ftpusers mtools.conf sesog.conf carvalho:/usr $ 5.1.5 - Acesso a arquivos O Sistema Operacional Linux, bem como os demais SO, trata o acesso a arquivos de forma radômica, 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. Além disso, o Sistema Operacional associa a cada arquivo algumas outras informações que chamaremos de atributos de arquivos. A figura 04, nos mostra alguns dos atributos dos arquivos. Figura 04 carvalho:/etc$ ls -l 55 total 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.cf drwxr-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.login lrwxrwxrwx 1 root root 13 Dec 9 13:59 utmp -> /var/og/utmp lrwxrwxrwx 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.example Como vimos neste exemplo, o Sistema de Arquivo do Linux permite restringir o acesso aos arquivos e diretórios permitindo que somente determinados usuários possam acessá-los. A cada arquivo e diretório é associado um conjunto de permissões. Essas permissòes determinam quais usuários podem ler, escrever, ou alterar um arquivo, e no caso de arquivos executáveis como programas, quais usuários podem executá-lo. Se um usuário tem permissão de execução de um diretório, significa que ele pode realizar buscas dentro daquele diretório, e não executá-lo como se fosse programa. Passaremos a explicar a codificação, escolhemos aleatoriamente o sétimo arquivo skel/ da figura 04 : d r w x r - x r - x nome do arquivo 1 2 3 4 5 6 7 8 9 10 skel/ obs : o que está em negrito,caixa maior, corresponde a posição do arquivo skel/ 56 • 1 - informa o tipo de arquivo (ddiretório,l  link, - demais arquivo) • 2 - Permissões do Proprietário (r  leitura, , - não permitida leitura ) • 3 - Permissões do Proprietário (w  escrita, - não permitida escrita) • 4 - Permissões do Proprietário (x  execução, - não permitida execução) • 5 - Permissões do Grupo (r leitura, , - não permitida leitura ) • 6 - Permissões do Grupo (w  escrita, - não permitida escrita) • 7 - Permissões do Grupo (x  execução, - não permitida execução) • 8 - Permissões do Sistema (r  leitura, , - não permitida leitura ) • 9 - Permissões do Sistema (w  escrita, - não permitida escrita) • 10 -Permissões do sistema (x  execução, - não permitida execução) 5.2 - Operações sobre arquivos Os arquivos existem para armazenar informações e permitir a sua recuperação. As Chamadas de Sistemas mais comum relacionadas ao Sistema de Arquivo Linux são chamadas que operam sobre arquivos individuais ou envolvendo diretórios e sistema de arquivos como um todo . A chamada CREAT não só cria um arquivo, mas também abre esta arquivo para escrita, indepedente do modo de proteção 57 compartilhado apareça simultâneamente em diretórios diferentes que pertençam a diferentes usuários. A conecção entre um diretório e um arquivo compartilhado é chamada de ligação (link). O próprio sistema de arquivo é um gráfico acíclico dirigido , ou DAG, em vez de árvore. No Linux os blocos do disco não são listados no diretório, mas numa estrutura de dados associada ao próprio 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 - Apresentação Este trabalho é baseado na versão 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 <Daniel.Quinlan@linux.org>. Uma parte considerável deste trabalho foi tirado da FAQ (Lista de perguntas mais frequentes) mantida por Ian McCoghrie (FSSTND-FAQ). Este documento está disponível via ftp anonymous em tsx-11.mit.edu no diretório /pub/linux/docs/linux- standards/fsstnd/ FSSTND-FAQ Nosso trabalho enfocará a estrutura do sistema de arquivos para LINUX típico, incluindo a localização de arquivos e diretórios, e o conteúdo de alguns arquivos de sistema. 60 5.4.2 - Características Sistema de Arquivos O sistema de arquivos Linux esta caracterizado por: • Uma estrutura hierárquica. • Um tratamento consistente da informação dos arquivos. • Proteção dos arquivos. O sistema de arquivos Linux segue o mesmo princípio básico que a maioria dos sistemas de arquivos UNIX seguem. Apesar que o sistema de arquivo não concordar em 100% com cada aspecto possível de alguma implementação particular do sistema UNIX. De qualquer forma, muitos dos aspectos da implementação do sistema de arquivos estão baseados em idéias encontradas em sistemas similar ao UNIX system V, outros fatores também foram levado em conta tais como : • Práticas comuns na comunidade LINUX. • A implementação de outras estruturas de sistemas de arquivos. • Definição das categorização ortogonal de arquivos: Compatível vs. não compátivel. e variável vs. estáticos. A informação compatível é aquela que pode ser compartida entre várias máquinas diferentes. A não compatível é aquela que deve ser localizada em uma máquina particular. Por exemplo, os diretórios local dos usuários são compatível, porém os arquivos de bloqueio do dispositivo (lock file) não são compatíveis. A informação estática inclui arquivos, biblilotecas, documentação e tudo aquilo que não precisa da intervenção do administrador do sistema. A informação variável é tudo aquilo que se troca com a intervenção do administrador. 61 O entendimento destes princípios básicos ajudará a guiar a estrutura de qualquer sistema de arquivos bem planejado. A distinção entre informação compatível e não compatível é necessária por várias razões: • Em um ambiente de rede, existe uma boa quantidade de informação que se pode compartilhar entre diferentes máquinas para o aproveitamento de espaço e facilitar a tarefa da administração. • Em um ambiente de rede, certos arquivos contém informação especifica de uma só máquina, portanto, estes sistemas de arquivos não podem ser compartilhados (antes de tomar medidas especiais). • As implementações de fato do sistema de arquivos não nos permitem que a hierárquia /usr fosse montada somente para leitura, porque possuía arquivos e diretórios que necessitavam ser escritos muito freqüentemente. Este é um fator que deve ser atacado quando algumas parte de /usr são compartilhadas na rede. A distinção "compatível" pode ser usada para suportar, por exemplo: • uma partição /usr (o componente de /usr) montada (somente para leitura) através da rede (usando NFS). • uma partição /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 distinção "estática" contra "variável" afeta o sistema de arquivos de duas maneiras principais: • Arquivo da /(raiz) contém ambos tipos de informação, variável e estática necessita permitir leitura e escrita. • Arquivo do /usr tradicional contém ambos tipos de informação variável e estática e os arquivos poderíamos desejar montar-los 62 etc Configuração do sistema da máquina local com arquivos diversos para a administração de sistema. home diretórios local(home) dos usuários. lib arquivos da biblilotecas compartilhadas usados com freqüencia mnt Ponto de montagem de partição temporários root Diretório local do superusuário (root) sbin Arquvios de sistema essenciais tmp arquivos temporários gerados por alguns utilitários usr todos os arquivos de usuários devem estar aqui (segunda maior hierárquia) var Informação variável Cada diretório listado será discutido em detalhe em uma subsessão separada mas adiante. /usr e /var, cada un tem seu própria sessão 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 informação da localização do kern pode-se encontar na sessão sobre a raiz / neste trabalho. 5.4.3.1 - Subdiretório /bin • Composição : Arquivos Binários de comandos essenciais de usuários (disponíveis para todos os usuários). Contém os comandos que podem ser utilizados pelos usuários e pelo administrador do sistema, porém que são requeridos no modo mono-usuário (single-user mode) pode também conter comandos que são 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 são ou não essenciais. Não abra subdiretórios dentro /bin. 65 Os arquivos dos comandos que não são suficientemente essenciais para estar em /bin estaram localizados em /usr/bin, os elementos que são utilizados pelos usuários isoladamente (porém não pelo root) (mail, chsh, etc.) não são suficientemente essenciais para estar dentro da partição /. 5.4.3.1.1 - Arquivos e/ou comandos disponíveis em bin Os arquivos que devem estar em /bin são : comandos gerais e comandos de rede. Comandos gerais: Os seguintes comandos deverão sido incluídos porque são essenciais. Alguns estaram presente e tradicionalmente deverão 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, então /bin/sh seria em links simbólico 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 instalação e seria igualmente carregada a que /bin/sh faz um links simbólico a /bin/ksh. Outros links simbólicos de sistemas utilizando outros programas, então a partição / conterá os componente mínimos necessários. Por exemplos, muitos sistemas incluiria cpio como de segunda utilidade mais é usado para reparos depois do tar. Porém jamais se espera restaurar o sistema da partição /, então estes arquivos podem ser omitidos (montar / em chip ROM, montar /usr no NFS). Se a 66 restauração do sistema se planeja através da rede, Então FTP o TFTP (junto com todo o necessário para obter uma conexão FTP) estariam disponíveis na partição /. Os comandos de restauração podem aparecer em /bin ou /usr/bin em sistemas LINUX diferentes. Comandos de redes. Estes são unicamente os arquivos de rede que os usuários e o root queiram ou necessitem executar que não estejam no /usr/bin ou /usr/local/bin {domain name, hostname, netstat, ping}. 5.4.3.2 - Subdiretório /boot: • Composição : arquivos estáticos do boot de inicialização (boot loader). Este diretório contém tudo que é necessário para carregar o sistema, exceto os arquivos de configuração 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 inicialização (master boot sectors) guardados, arquivos de mapa de setor e qualquer outra coisa que não é editada manualmente. Os programas necessários para consertar o boot de inicialização e capaz de carregar um arquivo (tal como o gerenciador de boot [lilo]) estaram localizados em /sbin. Os arquivos de configuração para carregar de inicialização 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. 67 são a maioria dos arquivos normalmente gravados em /usr/lib/X11/xdm; veja /var/lib/xdm, para maior informação. 5.4.3.4.1 - Arquivos e/ou comandos disponíveis em /etc Este descrição do conteúdo é generica, portanto não está totalmente completa, pode haver algumas variações dependendo do distribuidor do Linux ou do administrador de sistema. Os arquivos /etc são composto de : • Arquivos gerais; • Arquivos de rede. Os arquivos gerais são necessários na maioria dos sistemas LINUX, tais como : {adjtime, csh.login, disktab, fdprm, fstab, gettedefs, group, inittab, issue, ld.so.conf, lilo.conf, magic, motd, mtab, mtools, passwd, profile, psdaTabelase, securette , shells, se sog.conf, tercamp, tte te pe} Os arquivos de Rede mais utilizados na maioria dos sistemas LINUX são : {exports, ftpusers, gateway, hosts, host.conf, host.equiv, host.lpd, inetd.conf, networks, printcap, protocols, reolv.conf.rpc, service} Existe dois modo para a instalação dos scripts de comandos "rc" os quais são chamados por init no momento de carregar, ou o modo /etc/rc.d/* etc do System V. Qualquer que seja o escolhido pode ser utilizado uma mescla dos dois. 70 Os sistemas com a senha de passwords sombreadas (shadow password) terão arquivos de configuração adicionais, em /etc (/etc/shadow e outros) e /usr/bin (useradd, usermod, e outros). 5.4.3.5 - Subdiretório /home: Composição : diretórios locais dos usuários (opcional) O sudiretório /home é claramente um sistema de arquivos específico do diretório local. A regra de criá-lo difere de máquina para máquina. Descreve uma localização sugerida para os diretórios local dos usuários, assim, recomendamos que todas as distribuições LINUX usem esta lugar como localização default dos diretórios locais. Em sistemas pequenos, cada diretório de usuário é um dos subdiretórios debaixo /home, /home/dirson, /home/raulison, /home/weslei, etc. Em sistemas grande (especialmente quando os diretórios /home são compartilhados entre várias máquinas usando NFS) é útil subdividir os diretórios local . A subdivisão pode ser implementada utilizando subdiretórios tal como /home/apoio, /home/docs, /home/cartas, etc. Muitas pessoas preferem colocar as contas dos usuários numa variedade de lugares, portanto, ninguém deverá confiar nesta localização. Se você deseja encontar o diretório local de qualquer usuário, deveria usar a função de bibliloteca getpwent em vez de contar com /etc/passwd, porque a informação pode estar armazenada remotamente usando sistemas como NIS. 5.4.3.6 - Sudiretório /lib: 71 • Composição : Biblilotecas compartilhadas e módulos do kern essenciais. O diretório /lib contém aquelas biblilotecas compartilhadas que são necessária para carregar o sistema e executar os comandos do sistema de arquivos raiz. Módulos -> Módulos de kern carregavéis. Estes incluem em /lib/libc.so.*, /lib/libm.so.*, O linkador dinâmico compartilhado /lib/ld.so.*, e outras biblilotecas compartilhadas requeridas por arquivos em /bin e /sbin. As biblilotecas que são necessárias somente pelos arquivos /usr (como qualquer arquivo X Windows) não pertencem a /lib. Só as biblilotecas compartilhadas requeridas para executar os arquivos dentro de /bin e /sbin devem estar ali. A bibliloteca libm.so.* poderia estar localizada em /usr/lib se não é utilizada de nenhuma forma em /bin ou /sbin. Por razão de compatibilidade, /lib/cpp necessita existir como uma referência ao pre-processador C instalado no sistema. A localização usual do arquivo é /usr/lib/gcc-lib/ <target>/<versão>/cpp. Pode existir links /lib/cpp apontando para estes arquivo ou a qualquer outra referência a ele que exista no sistema de arquivos. (Por exemplo, /usr/bin/cpp é utilizado frequentemente). A especificação para /lib/module ainda não foi definida, pois ainda não há um concenso na comunidade Linux. 5.4.3.7 - Subdiretório /mnt • Composição : Utilizados para armazenamento de arquivos montados temporariamente. Este diretórios foi previsto para o administador poder montar temporariamente sistemas de arquivos quando necessitar. O 72 por motivos de segurança para evitar que os usuários violem o sistema operacional, foi cirada para promover uma boa partição entre arquivos que todos usam e os que são utilizados principalmente para as tarefas administrativas. Não há utilidade inerente na segurança em fazer que /sbin esteja fora do alcance dos usuários. 5.4.3.10.1 - Arquivos e/ou comandos armazenados em /sbin Arquivos armazenados são dos seguintes tipos : • comandos gerais; • comandos de saída; • comandos de manipular sistema de arquivos; • gerenciador de boot de inicialização e • comandos de rede. Os comandos gerais são clock, gette, init, update, mkswap, swapon, swapoff, telinit. Os comandos de saída são fastboot, fasthalt, halt, reboot, shutdown. Os comandos de manipular sistemas de arquivos são fdisk, fsck, fsck.*, mkfs, mkfs.*, onde * = é um dos seguinte. ext, ext2 minix, msdos, xia, e talvez outros. Os comandos do sistema de arquivos ext2 (opcional) são badbocks, dumpe2fs, e2fsck, mke2fs, mkost+found, tune2fs. O Gerenciador do boot de inicialização (lilo) e os comandos de Rede : arp, ifconfig, route. 75 5.4.3.10.2 - Arquivos opcionais em /sbin: Os arquivos estáticos (compilados estaticamente) estão o sln e nc estático, nc são utilitários quando ocorrem erros. O principal uso do sln (reparar links simbólicos incorretos em /lib depois de uma atualização mal sucedidas) não é a preocupação maior, já que existe o programa ldconfig (usualmente localizado em /usr/sbin) e pode atuar como um assistente guiando para atualizar as biblilotecas dinâmicas. O nc estático é útil em algumas ocasiões de emergência. Note que estes não necessitam ser obricatoriamente versões compiladas estaticamente dos ln e nc, porém podem ser compilados estáticamente. O arquivo ldconfig é opcional em /sbin, dado que um usuário pode escolher executar ldconfig ao dar boot, em vez de só quando atualizam as biblilotecas compartilhadas . (Não está claro se é ou não vantajoso executar ldconfig em cada inicialização). Assim, alguns que gostam de ter ldconfig a mão na situação que se tem um sln, pois não se sabe como nomear os links. 5.4.3.11- Subdiretório /tmp Composição : arquivos temporários gerados por alguns arquivos utilitários. O /tmp é utilizado para arquivos temporários, preferencialmente em dispositivo rápido (um sistema de arquivos basado em memória por exemplo). A "permanência" da informação que é armazenada em /tmp é diferente de aquela que é armazenada em /var/tmp. /tmp pode ser limpo em cada inicialização ou a intervalos relativamente frequentemente. Portanto, não se deve 76 operar a informação armazenada em /tmp permanecendo por algum período determinado de tempo. Os programas devem utilizar /tmp ou /var/tmp (que era originalmente /usr/tmp) de acordo os requisitos esperados da informação, pois não devem colocar nenhum arquivo particular em qualquer diretório de armazenamento temporário. Os administradores de sistemas podem querer ajuntar /tmp a algum outro diretório, tal como /var/tmp. Isto é útil, por exemplo, para conservar espaço na partição raiz. Se está é executada, então a permanência de arquivos em /var/tmp deve ser mesmo tão grande como a de /tmp. O subdiretório /tmp pode estar na memória RAM, /var/tmp nunca poderá se localizar-se em algum dispositivo RAM. 5.4.3.12 - A hierárquia /usr. O subdiretório /usr é a segunda maior seção do sistema de arquivos. /usr é informação compartilhada, somente de leitura, isto significa que /usr, deve ser compartilhada entre várias máquinas que utilizam o LINUX e não deve exibir qualquer informação local de uma máquina ou que varia com o tempo, deve ser armazenada em outro lugar. Nenhum pacote grande (como TeX o GNUEmacs) deve utilizar o subdiretório direto abaixo de /usr, em vez disso, deve haver um subdiretório dentro /usr/lib (o /usr/local/lib caso tenha sido instalado localmente), a propósito, como o sistema X Windows faz-se uma exceção permitindo um considerável precedente e a prática amplamente aceita. Exemplo de um subdiretório /usr típico : carvalho:/usr $ ls X11@ etc/ lib/ spool@ X11R6/ games/ local/ src/ X386@ i486-linux/ man/ tclX/ 77 5.4.3.12.4 - Subdiretório /usr/dict - Listas de palavras Arquivos recomendados em /usr/dict (words), tradicionalmente esta diretório contém somente arquivos words de palavras inglesas, o qual é utilizado por "look" para vários programas de ortografia, words pode utilizar ortografia americana ou britânica. Os usuários que precisam ambos, podem concatenar words a /usr/dict/american- english ou /usr/dict/ british-english. As listas de palavras para outros linguagem pode usar o nome em inglês para a linguagem, por exemplo, /usr/dict/french, /usr/dict/danish, etc. Estes devem, se possível, utilizar o jogos de caracteres ISO 8859 que faz aprópriado para linguagem em questão, e se possível, o jogo de caracteres ISO 8859-1 (Atin1) deve ser utilizado (muito raramente é possível fazê-lo) Qualquer outra lista de palavras, tal como o diretório web2, deve ser incluido aqui, É razoável ter aqui só as listas de palavras, e que elas são os únicos arquivos comum a todos os verificadores de ortografia. 5.4.3.12.5 - Subdiretório /usr/etc Contém a configuração do sistema, porém armazenar a configuração /usr/etc do software que se encontra em /usr/bin e /usr/sbin é um problema. Montar /usr somente para leitura de um CD-ROM ou através de NFS é difícil no melhor dos casos. Uma possível solução que considerada foi eliminar completamente /usr/etc e especificar que todas as configurações se armazenem em /etc. Acontece que existe a possibilidade de que muitos site podem querer ter alguns arquivos de configuração que não estejam na sua máquina local. 80 Eventualmente, decide-se que /etc deverá ser o único diretório que seja referenciado pelos programas (Isto é, todos devem buscar configurações em /etc e não /usr/etc). Qualquer arquivo de configuração que necessissário para todo o sistema e que não era necessário antes de montar /usr (em uma situação de emergência deve estar localizado em /usr/etc). Arquivos especificos em /etc, em máquinas específicas podem ter ou não um link simbólicos aos arquivos de configuração localizados em /usr/etc. Isto também significa que /usr/etc é tecnicamente um diretório opcional no sentido restrito, mesmo assim recomendamos que todos os sistemas LINUX o incorporem. Não é recomendado que /usr/etc contenha links simbólicos que apontem para arquivos /etc. Isto é desnecessário e interferem no controle local das máquinas que compartem o diretório/usr. 5.4.3.12.6 - Subdiretório /usr/include Neste diretório é onde todos os arquivos include de uso geral do sistema para programação em linguagem C e C++ podem ser localizados. Descrição dos principais sudiretórios de /usr/include : /usr/include arquivos include X11 Link simbólico até /usr/X11R6/include/X11 arpa Definição do protocolo definido por ARPNET. asm Link simbólico até /usr/scr/linux/include/asm-<arch>. bsd arquivos include de compatibilidade com BSD. g++ arquivos include de GNU C++. gnu arquivos include GNU. linux Link simbólico a /usr/src/linux/include/linux. net Definição genéricas relacionadas com rede. 81 netax25 Definição específicas a +AX25 ( ARRL AX25). Netinet Definição específicas a TCP/IP. netipx Definição específicas a +IPX (NovOIPX/SPX). protocols Definição de protocolos( basadas em INET) readline A bibliloteca readline GNU. rpc Definição RPC de Sun Microsystem. Rpcsvc Definição de serviços RPC de Sun Microsystem. sys arquivos include de geração de sistemas O subdiretório arpa contém definições de header de protocolos para os protocolos ARPANET, TCP/IP, definições para ftp, prototipos telnet e material similar. O subdiretório net contém definições genéricas relacionadas com a rede, define a interface sistema vs. kern, detalhes da família de protocolo, etc. O subdiretório netinet contém definições específicas de INET (DARPA Internet, que também é contida no TCP/IP ) ARRL AX.25 é melhor conhecido como pacote de transmissão via radio (packet radio). Os protocolos novell IPX/SPX são parte dos serviços de arquivos Novell Netware. 5.4.3.12.7 - Subdiretório /usr/lib Inclui as biblilotecas para programas e pacotes, inclue as biblilotecas objeto, arquivos de programa compilador, informação estática de várias casos, ambos, códigos executável (por exemplo os arquivos internos de gcc estão localizados abaixo /usr/lib/gcc-lib) e outros tipos de informação. /usr/lib/ - biblilotecas para programação e pacotes: X11 Link simbólico para /usr/X11R6/lib/X11 82 /usr/local Diretórios da Hierárquia local bin arquivos doc Documentação local etc arquivos de configuração utilizados somente no local games Jogos instalados localmente lib Biblilotecas para /usr/local info Páginas de informação local man Hierárquias de páginas de manual para /usr/local sbin Administração do sistema scr Código fonte local. Este diretório deve estar vazio ao terminar de instalar LINUX pela primeira vez. Não deve haver exceções regra , exceto quiça os subdiretórios vazios listados. O software instalado localmente deve estar localizado dentro de /usr/local, em vez de /usr a menos que esteja sendo instalado para reemplantar ou atualizar software em /usr. Note que o software localizado em / ou em /usr pode ser sobrescrito por atualizações do sistema (assim mesmo, é recomendado que as distribuições não sobrescrevam informações /etc fora destas circunstâncias). Por esta razão, o software local não deve se colocado fora de /usr/local sem uma boa causa. 5.4.3.12.9 - Subdiretório /usr/man Inclui as paginas do manual, detalha a organização das páginas do manual através do sistema, devem estar dentro de /usr/man. As páginas do manual estão armazenadas <mandir>/<locais>/man [1-9]. Faremos uma pequena listagem de <mandir> e <locais> : 85 <mandir>/<locais> uma hierarquia de páginas de manual. man1 Programas para usuários. man2 Chamadas do sistema. man3 Subrotinas e funções de bibliloteca. man4 Dispositivos. man5 Formatos arquivos. man6 Jogos. man7 Misceláneas. man8 Administração do Sistema. man9 Funções e variáveis internas do kernel. O <mandir> primário do sistema é /usr/man contém informação do manual para comandos e informação abaixo dos sistemas de arquivos / e /usr. Obviamente não há páginas de manual em / porque não se necessitam para carregar nas emergências. Deve-se fazer reserva na estrutura de /usr/man para o suporte de páginas do manual que estão escritas em diferentes idiomas (multiplos idiomas). Estas providências devem levar em conta o armazenamento e referência destas páginas do manual. Os fatores relevantes incluir no idioma (inclue diferenças basedas na geografia) e código do conjunto caracteres. Esta nomenclatura dos subdiretórios de idiomas de /usr/man esta basada no apêndice e do padrão POSIX 1003.1 que descreve a cadeia de identificação locais. O método mas aceito para descrever um ambiente cultural. A cadeia <locais> é: • <idioma>[<_territorio>][.<conjunto_de_caracteres>][,<versão>] O campo <idioma> vem do ISO639 (um código para a representação dos nomes dos idiomas). Seja os caracteres especificado no padrão ISO, com minúsculas somente. O campo <_territorio> será o código das letras de ISO3116 (uma especificação da representação dos nomes dos países, se 86 possível (muita gente está familiarizada com o código 2 letras espelhado no código país como e-mail). O campo <conjunto_de_caracteres> deve representar o layout que descreve o código caracteres. Se o campo <conjunto_de_caracteres> é só uma especificação numérica, o número representa o número do layout internacional que descreve o conjunto caracteres. Recomenda-se que utilizar uma representação numérica, sempre que for possível (especialmente o padrão ISO), que não inclua símbolos de pontuação e que todas as letras sejam minúsculas. Um parâmetro que especifique <versão> do perfil pode ser colocada depois do campo <conjunto_de_caracteres >. Esta pode utilizar-se para diferenciar as necessidade culturais. Em sistemas que usem só um idioma e um código do conjunto de caracteres para todas as páginas do manual, pode-se omitir a subcadeia <locais> e armazenar todas as páginas do manual em <mandir>. Por exemplo no sistemas que só tem páginas do manual em inglês codificados na ASCII, podem armazenar as páginas do manual (Os diretórios man[1-9]) diretamente em /usr/man. Em países nos quais existe um código do conjunto caracteres no layout, pode omitir o campo <conjunto_de_caracteres>, porém é bastante recomendado que a inclua, especialmente para países com vários layouts. Exemplos de vários manuais encontrados : 87 São informação que independente da arquitetura, quaisquer especificação para /usr/share será incluida em um documento suplementar ao FSSTND, de acordo com a Linux Organization, os pesquisadores do FSSTND acham que /usr/share não é necessário na maioria dos sistemas Linux. 5.4.3.12.12 - Subdiretório /usr/src Contém o Código fonte para o kern do Linux, qualquer código fonte não local deve localizar-se neste diretório . O único código fonte que sempre deve localizar-se em um lugar específicos é o código do kern(quando exista ou esteja enlaçado como parte de uma estrutura /usr/include). Podem-se usar subdiretórios que desejar. O código fonte para Kern deve sempre estar em seu lugar mesmos. Os arquivos include do código do kernel. Esses arquivos estão localizados neste diretórios. /usr/src/linux/include/asm-<arch> /usr/src/linux/include/linux /usr/include deve conter links a estes diretórios, chamados asm e linux, dados que são necessitados pelo compilador de C, ao menos estes arquivos include devem sempre ser distribuidos nas intalações que incluem um compilador C. Devem ser distribuidos no diretório/usr/src/linux de forma que não existão problemas quanto os administradores do sistema atualizem sua versão do kern pela primeira vez. /usr/src/linux pode também ser um links simbólico a um árvore de código fonte do kernel. 5.4.3.13 - A Hierárquia /var 90 /var Informação variável adm Informações administrativa do sistema (obsoleto). Link simbólico até /var/og catman Páginas do manual formatadas localmente lib Informação do estado das aplicações local Informação variável do software de /usr/local ock arquivos de bloqueio og arquivos de Agenda named arquivos DNS, somente rede nis arquivos base de dados NIS run arquivos relevantes a processos execução do sistema spool Diretórios de trabalhos em fila para realizar-se depois tmp arquivos temporários, utilizado para manter /tmp menor possível /var contém arquivos com informação variável. Esta incluem arquivos e diretórios em fila de execução, informação de ordem administrativa e arquivos temporários e transitorios. Algumas porção de /var são não compatível entre diferentes sistemas. Por exemplo, /var/og, /var/ock e /var/run. Outras porção são compatível, notoriamente /var/spool/mail e /var/spool/news. /var é especificada aqui para fazer possível montar /usr somente para leitura. Tudo aquilo que alguma vez ficou em /usr é escrito durante a operação normal do sistema (não durante a instalação e manutenção do software) deve ir em /var. Se /var não pode ser uma participação separada, é preferivel mover /var para fora do diretório raiz, pois dentro da partição /usr (Isto se fazia algumas vezes para reduzir o tamanho da partição raiz ou quando há pouco espaço na partição raiz). Sendo assim, /var não deve ser enlaçada a /usr, porque fazia que a separação entre /usr e /var seja mais difícil e seguramente criará um conflito do nomes, em vez links /var e / usr/var. 91 5.4.3.13.1 - /var/adm : Agenda do sistema e arquivos contabilizados (obsoleto) Este diretório tem sido repassado para /var/og e outros diretórios . Deve ser um links simbólico a /var/og até que todos os programas não se refiram mas a algum arquivo em /var/adm. utmp seja movido a /var/run. Todos os arquivos agendas vão ser movidos a /var/og incluindo o arquivo wtmp. O suporte de empacotamento das distribuições deve armazenar em /var/lib/<nome>. Nota: O links simbólico /var/adm não deve ser necessário a maioria dos sistemas Linux-i386ELF dado que Otroca foi introducido antes que ELF fora liberado al público. 5.4.3.13.2 - /var/catman : Páginas do Manual Formatadas localmente (opcional) Este diretório poporcionara uma localização padrão para os computadores que utilizam uma partição /usr somente para leitura , pois desejam permitir o armazenamento temporário de páginas do manual formateados localmente. Os administradores que montaram /usr como escrita (intalações mono-usuários) podem escolher não usar /var/catman e exibir as páginas do manual formatadas dentro dos diretórios cat[1-9] dentro /usr diretamente. Recomendamos que a maioria dos administradores utilizem uma das seguintes opções em seu lugar. Preformatando todas as páginas do manual dentro /usr com o programa (catman). Não será permido o armazenamento temporário das páginas formatadas do manual e precise que se execute nroff cada vez que necessite uma página. 92 /var/lib/news deve usar para armazenar toda a informação variável asociada com os servidores de news tais como Cnews e INN, inclusive o arquivo histórico, o arquivo ativo. /var/lib/texmf /var/lib/texmf deve usar para armazenar a informação variável associada com TeX. Particularmente, em /var/lib/texmf/fonts armazenaram todas as fonte tipográficas que são geradas automáticamente por MakeTeXPK. Deve haver um links desde /usr/lib/texmf/fonts/tmp até /usr/lib/texmf/fonts. Este links permite os usuários fazer uso de uma só rota /usr/lib/texmf/fonts/tfm quando houver trocas da sua variável TEXFONTS (Esta é A rota default nas ferramentas TeX de Karl Berre distribuidas por ftp.cs.umb.edu:pub/tex [A razão de mencionar-lo aqui é que são o padrão de fato nas intalações UNIX, estas ferramentas são amplamente usadas na comunidade LINUX]. Se se utiliza outra distribução de TeX, deve fazer um links deste diretório de fonte apropriada até /usr/lib/texmf/fonts). O MakeTeXPK que se distribue e com dvipsk colocará os arquivos .pk em fonts/pk/<dispositivo>/<nome_da_fonte>, (por exemplo, fonts/pk/Canon_CX/cmr10.300pk). Os arquivos .pk podem ser plugados periodicamente do árvore /var/lib/texmf ou pode-se mover dentro da árvore /usr/lib/texmf. Se usarem geradores automáticos de .mf ou .tfm, estes devem por sua informações nos subdiretórios mf ou tfm de /var/lib/texmf/fonts. /var/lib/xdm /var/lib/xdm contém a informação variável de xdm que consiste nos arquivos xdm-errors e quaisquer arquivo pertencentes a xdm. Os arquivos de xdm tais como chooser devem até estar 95 localizados na localidade histórica em /usr/X11R6/lib/X11/xdm. O arquivo xdm-pid devem estar em /var/lib/xdm apesar de existir /var/run. Os arquivos restantes devem estar em /etc/X11/xdm. 5.4.3.13.4 - /var/local : Informação variável do software que está em /usr/local Este diretório contém toda a informação variável que esta relacionada com o software que se encontra em /usr/local. Naturalmente a implementação desta subdiretório é prerrogativa do administrador do sistema . Como a informação pode estar noutro lugar do diretório/var, não deve colocar em /var/local. Por exemplo, todos os arquivos de bloqueios estarão em /var/ock. 5.4.3.13.5 - /var/ock : arquivos de Bloqueio Os arquivos de bloqueio devem de armazenar-se dentro uma estrutura do diretório de /var/ock. Para preservar a habilidade de montar /usr somente para leitura , não se deverá colocar os arquivos de bloqueio na partição /usr. Os arquivos de boqueio dos dispositivo, tais como os arquivos de boqueio do dispositivos serie que antes se encontravam em /usr/spool/ock ou em /usr/spool/uucp devem agora ser armazenado em /var/ock. A convenção para a nomenclatura que deve utilizar-se é LCK., seguido do nome base do dispositivo. Por exemplo, para bloquear /dev/cua0 se deverá criar o arquivoLCK..cua0. O formato usado para os arquivos de bloqueios de dispositivo no Linux deverá ser o Formatos arquivos de bloqueio HDB UUCP. O formato HDB é armazenado em OPID (Identificador de processo) com 96 um número decimal na ASCII de 10 bytes, com um caracter de linha nova. Por exemplo, se o processo 1230 retém um arquivo de bloqueio, contém dados seguinte onze(11) caracteres: espaço, espaço, espaço, espaço, espaço, espaço, um, dois, três, qautro e nova linha. Então quaisquer coisa que usar /dev/cua0, pode ler o arquivo de bloqueio e atuar de acordo (todos os arquivos de bloqueio em /var/ock devem ser lidos por todos). 54.3.13.6 - /var/og : Arquivos agenda e diretórios Este diretório contém arquivos agenda misceláneos. A maioria dos arquivos agenda se devem exibir neste diretórios ou subdiretórios aprópriados. astog Registro do último acesso de cada usuário mesage Mensagem do sistema desde que logou ao sistema wtmp Registro de todos os acessos e saídas Pode requerer um links simbólico desde /var/og/utmp até /var/run/utmp basta que nenhum programa se refira a /var/adm/utmp (/var/adm é em si mesmo um links simbólico transicional até /var/og). 5.4.3.13.7 - /var/named : arquivos DNS Este diretório contém todos os arquivos de trabalho do servidor de nomes Internet, named. Recomendamos que /etc/named.boot seja um links simbólico até /var/named/named.boot, dado que 97