O kernel do Linux precisa de um sistema de arquivos para ser executado?

Essa é uma pergunta bastante estranha porque você não executa o kernel como executa um programa. O kernel é uma plataforma para executar programas. Claro que existe o código de configuração e desligamento, mas não é possível executar o kernel sozinho. Deve haver sempre um processo "init" principal. E o kernel entrará em pânico se não estiver lá. Se o init tentar sair, o kernel também entrará em pânico.

Atualmente, o processo de inicialização é algo como systemd. Se não for especificado de outra forma, o kernel tentará executar um programa de uma lista de locais começando com /sbin/init. Veja o init Param aqui http://man7.org/linux/man-pages/man7/bootparam.7.html em uma emergência você pode inicializar o Linux com init=/bin/bash. Mas observe como você sempre especifica um arquivo no sistema de arquivos para ser executado.

Portanto, o kernel entrará em pânico se inicializar e não tiver sistema de arquivos porque sem um não há como carregá-lo.

Alguma confusão pode surgir devido a uma fase de inicialização do kernel. Um ramdisk inicial é carregado de uma imagem no disco contendo drivers vitais e scripts de configuração. Eles são executados antes que o sistema de arquivos seja carregado. Mas não se engane, o ramdisk inicial é um sistema de arquivos. Com um ramdisk inicial /inité chamado (que é armazenado no ramdisk inicial). Em muitas distribuições, em última análise, é isso que chama /sbin/init. Novamente, sem um sistema de arquivos, isso é impossível.

A resposta vai depender se você quer dizer literalmente sem um sistema de arquivos ou se a pergunta deve ser interpretada um pouco diferente de como ela é realmente declarada. As respostas para pequenas variações em como a pergunta é interpretada são:

• A execução do Linux sem nenhum dispositivo de bloco é totalmente viável e útil para alguns casos de uso especializados.
• A execução do Linux sem nenhum sistema de arquivos exigirá a reescrita de algumas partes do código do kernel e é improvável que seja um esforço útil.
• Executar o Linux sem usar nenhum descritor de arquivo exigirá muito esforço. Tenho certeza que não vai valer a pena o esforço.

As razões pelas quais você teria que reescrever partes do código do kernel para fazer um sistema funcional sem um sistema de arquivos são:

• Cada thread tem um diretório raiz e um diretório de trabalho atual que deve apontar para algum sistema de arquivos.
• Os programas são iniciados pela execvechamada do sistema que precisa de um executável de um sistema de arquivos.
• O kernel cria um sistema de arquivos baseado em memória durante o processo de inicialização.

Depois que um programa é iniciado usando execve, é possível desmapear o executável a partir do qual foi iniciado, embora para fazê-lo sem travar imediatamente, primeiro é necessário criar um mapeamento de memória executável que não seja apoiado por um arquivo, e tem que inicializar isso com algum código útil antes de pular para ele e desmapear o executável.

Assim, um programa em modo de usuário em execução pode existir em um estado em que não tenha mapeamentos de memória com suporte de arquivos e pode fechar todos os descritores de arquivo com suporte de arquivos. Ele não pode deixar de ter um diretório raiz e um diretório de trabalho atual, mas pode abster-se deles.

Portanto, embora nesse estado você possa implementar o código do kernel para remover o sistema de arquivos do programa e mantê-lo em execução, não parece útil. E chegar a esse estado final sem passar por um estado intermediário de uso de um sistema de arquivos será ainda mais trabalhoso sem nenhum benefício útil.

Uma configuração útil para alguns casos de uso especializados

Evitar o uso de dispositivos de bloqueio pode ser útil. Durante a inicialização, o kernel cria um sistema de arquivos de memória e também pode preencher esse sistema de arquivos com o conteúdo de um cpioarquivo antes de executar init. Dessa forma, você pode executar um sistema inteiramente a partir de um sistema de arquivos baseado em memória sem nenhum dispositivo de bloco para apoiá-lo.

Isso pode ser útil para sistemas em que você não deseja preservar nenhum estado e gosta que o sistema inicie do zero na reinicialização.

É claro que o kernel e o arquivo cpio precisam existir de alguma forma na memória antes que o kernel receba o controle. Como eles chegaram lá é um trabalho para o carregador de inicialização. O carregador de inicialização pode ter carregado aqueles de um dispositivo de bloco, mesmo que o sistema em execução final não use dispositivos de bloco. Mas também é possível que o carregador de inicialização adquira o kernel e o arquivo cpio sem usar um dispositivo de bloco, por exemplo, inicializando pela rede.

No Linux, quase todo dispositivo é um arquivo , então você precisa ter um sistema de arquivos para executá-lo.

Um kernel é um programa, como qualquer outro. Por padrão, o kernel do Linux tenta acessar o sistema de arquivos, porém esse comportamento pode ser trivialmente eliminado pela modificação do kernel (na verdade, apenas uma adição de uma função "arch_call_rest_init()"). Para realizar "trabalho útil", esperamos que o desenvolvedor inclua threads de kernel (kthreads), talvez em um driver personalizado, para executar alguma inicialização desejada e carga de trabalho do tipo de aplicativo. O kernel Linux já contém muitos kthreads, mas principalmente para realizar trabalhos auxiliares ao kernel ou drivers. As APIs disponíveis no contexto do kernel são bem diferentes daquelas disponíveis no espaço de usuário do Linux. Uma grande fração da funcionalidade de chamada do sistema se tornaria inútil em um cenário sem sistema de arquivos.

Sim, o Linux espera acesso a sistemas de arquivos por padrão. Não, um kernel modificado certamente poderia ser feito para realizar um trabalho útil sem qualquer sistema de arquivos. O uso prático do Linux sem sistema de arquivos é IMO bastante limitado, mas não nulo. FWIW, no passado, muitos kernels em tempo real foram construídos no mesmo espaço de nomes e binários que os aplicativos RT.