O hardware do Kernel é específico?

Question

Pelo que entendi, o Kernel fornece o link entre o software e o hardware e, portanto, o Kernel deve direcionar as chamadas do sistema feitas pelos aplicativos do sistema operacional, correto? Então, diferentes mapas de endereços de E / S significam que o Kernel deve ser programado de forma diferente? Leia abaixo, pois não acredito que tenha formulado essa pergunta com muita precisão.

Deixe-me elaborar, e por favor me corrija se eu estiver errado, pois é assim que entendi o que vários artigos declararam. Eu estarei usando a família x86 como base para meus exemplos. Os processadores x86 usam o comando INT, bem como um índice chamado de Tabela Vetorial de Interrupções para mapear um ID INT para o local correto da rotina desejada (rotina e IVT localizados no BIOS, correto?). As próprias rotinas são escritas de tal forma que podem comandar o hardware específico de um sistema de computador para realizar uma tarefa com base no protocolo do hardware que está sendo usado. Isso permite que o SO faça chamadas do sistema e se comunique com o hardware sem ter nenhum conhecimento do hardware ou do mapeamento de E / S específico do sistema. Tudo o que é necessário para o sistema operacional se comunicar com o hardware é o id do ISR específico desejado. Como o kernel é o link entre hardware e software, estou supondo que os aplicativos que estão sendo executados pelo sistema operacional não precisam saber o ISR id #, eles simplesmente dizem ao kernel que desejam, por exemplo, gravar dados X no HDD, o kernel retransmite os dados X para o ISR correto, que grava os dados no disco rígido. Portanto, dois sistemas, completamente idênticos, exceto pelo fato de usarem ids ISR diferentes para tarefas diferentes, exigiriam núcleos ligeiramente diferentes?

E isso também significaria que o setor de inicialização que carrega o kernel também dependerá do mapeamento id do ISR, já que as chamadas do sistema para leitura do HDD precisariam ser feitas para carregar o kernel?

Peço desculpas se estiver no local errado, mas eu li que esse é o local correto para perguntas relacionadas a hardware. Obrigado!

    

Answer 1

Com relação aos comandos INTh que você faz referência (consulte: BIOS Interrupt Calls ), você está certo de que isso era verdade a maneira como um sistema operacional acessaria o hardware de baixo nível. Em uma máquina moderna, essas chamadas (se executadas) geralmente acabam no CSM (Módulo de Compatibilidade Compatível, pelo menos no jargão da AMI) que pode lidar com essas solicitações. No exemplo de uma chamada de BIOS de vídeo, isso executaria o código no BIOS de vídeo, se presente. Eu trabalhei com o IGP da Intel como desenvolvedor de BIOS, e como parte da imagem final, nós tivemos uma ferramenta da Intel onde colocamos o BIOS de vídeo deles como um blob.

Da mesma forma, o BIOS pode implementar versões "emuladas" de chamadas para ler / definir o RTC. Um sistema operacional moderno simplesmente não executará todos esses manipuladores legados, já que não precisa se apoiar na BIOS para esse suporte - por exemplo, pode haver um driver de kernel que saiba como falar diretamente com o seu PCH para mexer com o sistema operacional. Configurações RTC.

Como você pode imaginar, isso é muito, muito lento e não é mais usado pelo software moderno. Em vez disso, o sistema operacional possui a propriedade de hardware necessária para fornecer uma camada de abstração que permite que os aplicativos gráficos utilizem os drivers da GPU para executar essas tarefas; esse dispositivo, é claro, geralmente é PCIe de um POV SW e é mapeado pela memória.

Da mesma forma, se você olhar a pilha de armazenamento do Linux abaixo, verá que as unidades de kernel subjacentes cuidam de falar com o hardware, sem usar a BIOS - todo o código executado é do seu kernel.

Agora, com relação a diferentes mapas de endereços de E / S, lembre-se de que x86 possui espaço de endereço de E / S e espaço de endereço de memória. Se você se lembrar de Plug-and-Play, na inicialização, seu BIOS passará e enumerará a árvore de Dispositivos PCI, que para sistemas modernos, basicamente abrange todos os seus periféricos, pelo menos a partir de um SW POV (ou seja, o controlador DRAM PCIe Bus 0, seus controladores USB são dispositivos PCI de um PO PO, etc.). Usando as BARs (Base Address Registers), o BIOS sabe quanta memória e de que tipo o dispositivo de destino quer, e fará o melhor para acomodar o pedido.

O mapeamento final é passado para o SO no hand-off, e ele pode escolher respeitar isso, ou fazer sua própria fase de enumeração. O Linux, por exemplo, tem 'peculiaridades' que você pode aplicar a determinadas IDs de dispositivos PCI antes do sistema operacional ter sido inicializado, e você pode se lembrar dos parâmetros de inicialização do kernel que podem afetar a quantidade de memória alocada, quais IRQs acabam com etc. .