Por que definir os modos do kernel, em vez da separação de privilégios?

A configuração de modos do kernel foi meio dolorosa para o Linux, mas agora é incrível de se ter. Quero dizer, X não precisa executar como root? Consoles acelerados por hardware de alta resolução? Coisas legais.

O problema é que muitas plataformas UNIX não têm nenhum tipo de driver de kernel de configuração. Portanto, o hardware que depende do KMS agora se limita principalmente ao Linux.

Minha pergunta: por que realmente implementar isso no kernel?

Se for necessário acessar o hardware para definir a resolução da tela, por que não usar um daemon privilegiado separado ou um pequeno binário setuid? Isso manteria a vantagem de separar o código privilegiado e permitir que o servidor de exibição funcionasse como usuário limitado; enquanto se livra do requisito especial de driver e facilita o suporte a UNIX. Certo? Ou estou perdendo algo significativo aqui?

kernel xorg drivers

— DanL4096
fonte

Essa é a idéia por trás das arquiteturas de microkernel OS.

— Barmar 17/09/2015

Nesse caso, não estou pensando no modelo do tipo microkernel, mas apenas na portabilidade entre kernels díspares.

— precisa saber é o seguinte

O KMS também está sendo usado pelo OpenBSD e FreeBSD, e o Solaris também possui o KMS em andamento. Dessa forma, quando os desenvolvedores criam um driver funcional para Linux, o suporte ao driver também flui para outras pessoas que usam o KMS.

— hspaans

É uma coisa arquitetônica. O acesso ao hardware é uma tarefa, se não A, de um kernel. Dividir o trabalho entre o kernel e o espaço do usuário é complicado, porque você precisará de dois componentes que realmente fazem apenas um trabalho com uma interface embaçada. Por fim, você executará o trabalho dentro do domínio do kernel; portanto, há um forte argumento para colocar tudo no kernel. Claro que você pode implementá-lo como e onde quiser. Plataformas robustas são sobre arquiteturas e interfaces claramente definidas! É tudo oscilante e vacilante.

— Bananguin 02/11/2015

Houve um período bastante longo em que vários tipos de falhas deixavam o console em um modo estranho, onde o X não estava mais funcionando, mas o acesso ao console TTY no estilo TTY não foi realmente restaurado. Os problemas e as falhas de aceleração do IIRC GL costumavam provocar essa situação com bastante frequência. KMS significa que o kernel sabe como corrigir o problema e restaurar o estado do console. IOW parcialmente uma melhoria de usabilidade. Embora se possa argumentar que o kernel pode solicitar que um daemon do espaço do usuário faça isso, acho que nem sempre funciona bem. Também colocá-lo no kernel significa que não há dificuldades de código fechado.

— precisa

O kernel já gerencia hardware de rede, áudio, ventiladores e outro hardware, por isso faz sentido que o hardware gráfico também seja gerenciado pelo kernel.

— Alexander
fonte