Um kernel monolítico é um kernel em que todos os serviços (sistema de arquivos, VFS, drivers de dispositivo etc.), bem como a funcionalidade principal (agendamento, alocação de memória, etc.) são um grupo unido que compartilha o mesmo espaço. Isso se opõe diretamente a um microkernel .
Um microkernel prefere uma abordagem em que a funcionalidade principal é isolada dos serviços do sistema e dos drivers de dispositivo (que são basicamente apenas serviços do sistema). Por exemplo, o VFS (sistema de arquivos virtual) e os sistemas de arquivos de dispositivo de bloco (por exemplo, minixfs) são processos separados que são executados fora do espaço do kernel, usando o IPC para se comunicar com o kernel, outros serviços e processos do usuário. Em resumo, se é um módulo no Linux, é um serviço em um microkernel, indicando um processo isolado.
Não confunda o termo kernel modular como algo menos monolítico. Alguns kernels monolíticos podem ser compilados para serem modulares (por exemplo, Linux), o que importa é que o módulo seja inserido e executado no mesmo espaço que lida com a funcionalidade principal (espaço do kernel).
A vantagem para um microkernel é que qualquer serviço com falha pode ser facilmente reiniciado, por exemplo, não há interrupção do kernel se o sistema de arquivos raiz lançar um aborto. Isso também pode ser visto como uma desvantagem, pois pode ocultar bugs bastante críticos (ou fazê-los parecer não tão críticos, porque o problema parece se corrigir continuamente). É visto como uma grande vantagem em cenários em que você simplesmente não pode consertar algo convenientemente depois que ele foi implantado.
A desvantagem de um microkernel é que as mensagens IPC assíncronas podem se tornar muito difíceis de depurar, especialmente se fibrilas forem implementadas. Além disso, apenas rastrear um problema de FS / gravação significa examinar o processo de espaço do usuário, o serviço de dispositivo de bloco, o serviço VFS, o serviço de sistema de arquivos e (possivelmente) o serviço PCI. Se você ficar em branco, é hora de olhar para o serviço IPC. Isso geralmente é mais fácil em um kernel monolítico. O GNU Hurd sofre com esses problemas de depuração ( referência ). Nem vou entrar em pontos de verificação ao lidar com filas de mensagens complexas. Microkernels não são para os fracos de coração.
O caminho mais curto para um núcleo estável e funcional é a abordagem monolítica. Qualquer uma das abordagens pode oferecer uma interface POSIX, onde o design do kernel se torna de pouco interesse para alguém que simplesmente deseja escrever código para executar em qualquer design.
Eu uso Linux (monolítico) na produção. No entanto, a maior parte do meu aprendizado, hacking ou mexer no desenvolvimento do kernel vai para um microkernel, especificamente o HelenOS .
Editar
Se você chegou até aqui com a minha resposta muito extensa, provavelmente se divertirá lendo o ' Grande debate Torvalds-Tanenbaum sobre o design do kernel '. É ainda mais engraçado ler em 2013, mais de 20 anos após a sua transpiração. A parte mais engraçada foi a assinatura de Linus em uma das últimas mensagens:
Linus "my first, and hopefully last flamefest" Torvalds
Obviamente, isso não se concretizou mais do que a previsão de Tanenbaum de que o x86 logo seria obsoleto.
NB:
Quando digo "Minix", não implico o Minix 3. Além disso, quando menciono The HURD, estou referenciando (principalmente) o microkernel Mach. Não é minha intenção depreciar o trabalho recente de outros.