driver de dispositivo e kernel

Question

Os drivers de dispositivo fazem parte de um kernel do sistema operacional ou fora do kernel, ou alguns fazem parte do kernel e outros estão fora do kernel?

Se o terceiro estiver correto, quais drivers de dispositivos geralmente fazem parte do kernel e quais estão fora do kernel?

Se o sistema operacional precisar ser específico, estou interessado em saber sobre o Linux (Ubuntu) e o Windows 7.

Obrigado!

    

Answer 1

No Windows, todos os drivers estão em arquivos separados, distintos do kernel.

No Linux, os drivers são um tipo de módulo. Você pode ter todos os drivers de dispositivos como módulos, alguns incorporados ao kernel e alguns restantes como módulos, ou todos integrados no kernel. Você pode criar um kernel Linux que tenha o carregamento do módulo desativado e, nesse caso, todo o hardware com o qual ele deverá funcionar deve ser incluído como parte do kernel.

Para o Linux, você precisa de dispositivos que precisem estar acessíveis durante a inicialização para serem integrados ao kernel. Isso inclui drivers de controlador de disco, drivers de rede (para inicialização de rede), porta serial ou drivers de console VGA (para exibir mensagens de diagnóstico) e drivers de barramento para hardware intermediário necessário para a CPU acessar esses dispositivos (por exemplo, controlador USB, PCIe, IDE, e / ou possivelmente drivers de chipset).

Tenho certeza de que é possível que o Windows inclua drivers como parte do kernel. Isso pode ser feito em algumas versões incorporadas ou personalizadas do Windows, mas não no Windows PC padrão, tanto quanto eu sei. Eu realmente acho que alguns drivers muito elementares estão tecnicamente dentro do kernel (como VgaSave e Beep), mas eu posso estar errado.

O Windows pode marcar alguns drivers como drivers "Boot Time", que geralmente seriam da mesma categoria que os drivers identificados acima. Se você acessar o modo de segurança, verá os nomes de vários drivers percorrendo, esses são todos os drivers de tempo de inicialização.

    

Answer 2

Existem duas maneiras de interpretar 'parte do kernel'.

O kernel inicia (na inicialização) como um arquivo no disco. Se você está perguntando sobre disco, eles não são parte do kernel, mas arquivos separados. Quase todos os sistemas agora os têm como arquivos separados. Nos dias realmente antigos do UNIX, adicionar um driver significava adicionar arquivos .o aos arquivos .o do kernel e relacionar novamente um kernel.

Se você quis dizer "parte do kernel executando a imagem", isso depende. O Windows pode fazer as duas coisas. Na verdade, o driver de exibição foi movido de não fazer parte do kernel para fazer parte da imagem de execução do kernel há algum tempo (de nt 3.51 para NT4.0) por motivos de desempenho.

Existem duas escolas gerais de design de sistema operacional:

Um é chamado de macrokernel. Todo o material do SO é tratado em uma única imagem de execução do kernel. O Linux e a maioria dos unixes são executados dessa maneira. A vantagem é que é rápido, todas as partes do kernel podem ler outras partes do kernel e se comunicar usando leituras e gravações de memória. A desvantagem é que isso fica confuso depois de um tempo, e agora você precisa coordenar o uso. Se você pode fazer algo de propósito, às vezes você pode fazer isso por acidente. Não há proteções e você pode ter um kernel panic.

O outro é chamado de microkernel (que o Windows NT começou a ser, e o Windows ainda está meio que). A teoria é que o kernel não funciona, mas faz o trabalho com código especial, mas o código não roda no espaço de memória do kernel. Este outro código não pode tocar na memória do kernel ou em qualquer outra. O lado positivo, isolamento de falhas - código ruim não kernel não pode arruinar o kernel. O lado negativo - indo e voltando para o modo kernel retarda as coisas. É por isso que o driver de exibição foi movido para o kernel no NT 4.0, a lentidão.

Estas são generalizações, é claro, eu não segui o design do microkernel do Windows há algum tempo, embora eu possa ter relativamente certeza do design do Linux.

O MacOSX é realmente interessante tecnicamente, usando um design híbrido microkernel / macro-UNIX-kernel. Ele costumava suportar binários OS9 antigos também - cultivando para coisas de espaço não kernel que eram chamadas de kernel no MacOS9.

O DragonFly BSD é um desdobramento interessante do FreeBSD que ainda é um macrokernel, mas usa a passagem de mensagens como um tipo de isolamento pobre, e torna o trabalho do kernel mais fácil como resultado.