segunda-feira, 30 de novembro de 2009


Init: Inicialização do Controle de Processos

manual-boot-init
7,5 Init: Inicialização do Controle de Processos

Uma vez que o kernel termina a inicialização, ele passa o controle para o processo de inicialização de usuário (8), que está localizado em / sbin / init, ou o caminho do programa especificado na variável init_path no carregador.
7.5.1 Automatic Sequence Reboot

A seqüência de reinicialização automática garante que os sistemas de arquivos disponíveis no sistema são consistentes. Se eles não são, fsck (8) não pode corrigir as inconsistências, init (8) ignora o sistema em modo de usuário único para o administrador do sistema para cuidar dos problemas diretamente.
7.5.2 Single-User Mode

Este modo pode ser alcançado através da seqüência do reinício automático, ou pelo usuário na inicialização com a opção-s ou ajustando a variável boot_single no carregador.

Ele também pode ser alcançado chamando shutdown (8) sem a reinicialização (-r) ou parar (-h) opções, de modo multi-usuário.

Se o console do sistema é definida como inseguras no arquivo / etc / ttys, então o sistema pede a senha de root antes de iniciar o modo de usuário único.

'Exemplo 7-3. Um Console Insecure em / etc / ttys '

# Nome de comentários status tipo getty

#

# Se o console está marcado como "inseguros", em seguida init irá pedir a senha de root

# Quando vai para o modo de usuário único.

console none unknown off insecure

Nota: Um console insecure significa que você considere a sua segurança física para o console de ser inseguro, e quer fazer alguém apenas a certeza de quem sabe a senha de root pode usar o modo de usuário único, e isso não significa que você deseja executar o seu console insegura. Assim, se você quiser segurança, escolha insecure, não segura.
7.5.3 Multi-User Mode

Se init (8) encontra seus sistemas de arquivos estar em ordem, ou uma vez que o usuário tenha terminado em modo de usuário único, o sistema entra em modo multi-usuário, na qual se inicia a configuração de recursos do sistema.
7.5.3.1 Configuração de Recurso (RC)

O sistema de configuração de recursos lê as configurações padrões do / etc / defaults / rc.conf, eo sistema de detalhes específicos do arquivo / etc / rc.conf, e então começa a montar o sistema de arquivos mencionados em / etc / fstab, o arranque de rede serviços, iniciar vários daemons do sistema e, finalmente, executa os scripts de inicialização de pacotes instalados localmente.

O rc (8) página de manual é uma boa referência para o sistema de configuração de recursos, como está a analisar os scripts.
O kernel do FreeBSD virtual

A idéia por trás do desenvolvimento da arquitetura VKernel era encontrar uma solução elegante para a depuração do kernel e seus componentes. Facilita a depuração, pois permite um kernel virtual sendo carregado no ambiente do usuário e, consequentemente, depurá-lo sem afetar o kernel do próprio real. Ao ser capaz de carregá-lo em um sistema executando também remove a necessidade de reinicializações entre kernel compila.

A arquitetura VKernel permite executar kernels FreeBSD em userland.
Dispositivos suportados

Um número de controladores de dispositivos virtuais existem para completar o kernel virtual.
Dispositivo de disco

O motorista vkd permite até 16 vn (4) dispositivos baseados em disco. O dispositivo raiz será vkd0.
Dispositivo de CD-ROM

O motorista vcd permite até 16 virtual CD-ROM dispositivos. Basicamente, esta é uma leitura apenas um dispositivo vkd com um tamanho de bloco de 2048.
Interface de rede

O motorista VKE suporta até 16 interfaces de rede virtual que são.

Origem [Parte II]

DragonFly BSD é um sistema operacional livre do tipo Unix, o qual originou-se de um fork do FreeBSD 4.8. Matt Dillon, antigo desenvolvedor FreeBSD desde 1994, começou a trabalhar no DragonFly BSD em junho de 2003, anunciando o fork do projeto FreeBSD na lista de e-mails do mesmo em 16 de Julho de 2003. [1]

Dillon começou o DragonFly na crença de que os métodos e técnicas de thread e multiprocessamento assimétrico adotadas no FreeBSD 5 o levaria a uma performance pobre e de difícil manutenção. Ele tentou corrigir suas suspeitas no projeto FreeBSD 5. Devido aos conflitos com os outros desenvolvedores do FreeBSD sobre a implementação de suas idéias, e outras razões, sua habilidade de modificar o código do FreeBSD acabou renovada. Apesar disto, os projetos DragonFly BSD e FreeBSD ainda trabalham em conjunto contribuindo na correção de bugs, drivers e outras atualizações e melhorias dos sistemas.

Destinado a ser a continuação lógica da série 4.x do FreeBSD, o DragonFly está sendo desenvolvido em um sentido completamente diferente do FreeBSD 5, incluindo uma nova implementação de Threads para processos leves no kernel. Muitos conceitos planejados para o DragonFly foram inspirados no AmigaOS.

Segundo seus desenvolvedores, o DragonFly BSD pode ser considerado a "evolução lógica do FreeBSD série 4.x". Outra característica interessante do DragonFly BSD é que muitos conceitos empregados em seu desenvolvimento são inspirados no AmigaOS.


DragonFly BSD foi bifurcado do FreeBSD 4.8, em junho de 2003, por Matthew Dillon. O projeto é "a continuação lógica do FreeBSD 4.x série”.