O ponto que a documentação está tentando fazer é que esse é um espaço de usuário bastante completo, mas você (como alguém que está procurando implementar um firmware para um dispositivo incorporado) ainda tem um papel a desempenhar.
O Busybox tem algumas suposições sobre o ambiente em que será executado, dentro do qual esta declaração está documentando aqui:
- Você de alguma forma cuidará do processo de inicialização antecipada. Isso inclui obter um gerenciador de inicialização para entregar a um kernel. O kernel precisa ser apropriado para o hardware e suficientemente "sadio" em geral.
- O Busybox não é suficiente para inicializar um dispositivo utilizável sem algum trabalho adicional. Você não pode simplesmente compilar o busybox, despejá-lo em um sistema de arquivos e entregar o controle assim que o kernel for inicializado sem fazer um pouco mais de trabalho em algum lugar primeiro. Você precisa ter certeza de que / dev existe no sistema de arquivos e é preenchido com inodes de dispositivo para corresponder ao seu hardware. O mecanismo exato para fazer isso depende da versão do kernel e do hardware / plataforma que você está mirando, ele mudou muito ao longo da evolução das versões do kernel do Linux e há mais de uma maneira de fazê-lo.
- Finalmente, muitas das peças que o busybox fornece (e as que você provavelmente vai querer de outro lugar) precisam de algum tipo de configuração. Como você gerencia isso depende de você, mas o resultado é que muitos dos comandos que você executará a partir do busybox leem arquivos de configuração de / etc e simplesmente não funcionarão se você não tiver fornecido um mecanismo para preencher e manter esses arquivos. .
Potencialmente no seu dispositivo incorporado, você terá apenas um sistema de arquivos, usando algo como o squashfs e tudo será somente para leitura dentro dele. Mas o ponto é que a sua imagem / instalador precisa fazer todo o trabalho para conseguir isso no lugar certo quando você tiver passado o controle.