Questão driver de dispositivo e kernel


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!


4


origem




Respostas:


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 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 do 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 "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.


5



Algumas notas, principalmente Windows: 0) Os drivers geralmente são executados no modo kernel (anel x86 0), mas o Windows tem "estrutura de driver em modo de usuário" para os drivers do anel 3. 1) Bip é externo em Beep.sys. 2) Você pode incluir drivers adicionais na mídia de instalação, mas não como parte do kernel (NTOSKRNL). O mesmo se aplica a todas as versões do Windows, incorporadas ou não. - grawity
Além de grawity: o Windows NT tem não há necessidade para drivers fazerem parte do kernel. Seu programa loader cuida do problema do ovo e da galinha com drivers de classe de inicialização que outros sistemas lidam combinando drivers com o kernel. (Este é o caso de muitos, se não a maioria dos sistemas operacionais PC de modo protegido, hoje em dia, na verdade.) - JdeBP
@JdeBP: Mas como é que é carregado, por exemplo? %SystemRoot%\system32\drivers\ntfs.sys? (IIRC, o carregador de boot tem suporte a NTFS embutido para carregar o kernel, mas eu não sei o que o kernel faz.) // A maioria dos sistemas Linux usa um arquivo "initrd" para carregar os drivers necessários para inicializar; Isso seria o mesmo que o Windows "drivers de inicialização de classe"? - grawity
Você respondeu sua primeira pergunta na frase entre parênteses. Sua segunda pergunta é uma questão apropriada em si mesma, para a qual a resposta curta é "Não", e que realmente é muito longa para ser tratada em um comentário. - JdeBP
... exceto que o processo não funcionou de maneira semelhante desde o Windows NT versão 5 (Windows NT 6 trabalhando de forma bastante diferente), o processo não funciona assim para ARCO e EFIe reconhecedores do sistema de arquivos complicam o mecanismo de carregamento do FSD. Como eu disse, isso é muito longo para comentários. Fazer uma pergunta. - JdeBP


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 imagem' 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 SO:

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 obter 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 coisas não espaciais 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.


5



Obrigado! Eu queria saber se "macrokernel" e kernel monolítico (en.wikipedia.org/wiki/Monolithic_kernel) são o mesmo conceito? - Tim
@Tim, @Rich: "Macrokernel" não significa "monolítico" - em vez disso, parece ser outro termo para kernel híbrido. Windows NT é classificado como "híbrido". - grawity
Também vale mencionar o GNU Hurd (microkernel Mach com quase tudo no espaço do usuário). - grawity
A confusão nesta resposta deriva do outro ponto de grawity feito em outro comentário. Existe uma diferença entre "executar no modo kernel" e "fazer parte da imagem do programa kernel". o O subsistema gráfico Win32 é executado no modo kernel do Windows NT versão 4 para a versão 5 (a versão 6 mudou as coisas novamente), mas não faz parte da imagem do programa do kernel. - JdeBP