Estou tentando entender exatamente o que é userland? todo mundo que eu pergunto diz: "Qualquer coisa que não seja kernel". mas não é tangível para mim. Quando estou lendo esse kernel posso rodar aquele driver no userland ou algo parecido; Não consigo imaginar o que vai acontecer! Portanto, agradecerei se alguém me esclarecer a esse respeito.
Responder1
Em um nível conceitual, o kernel é tudo que roda em um nível “mais privilegiado” de proteção de hardware. Isso seria como o anel 0 em processadores x86, modo de sistema em ARM, modo kernel em MIPS, modo supervisor em 68xxx, etc. O kernel geralmente é acionado por interrupções, sejam interrupções de software (chamadas de sistema) ou interrupções de hardware (unidades de disco, rede cartões, temporizadores de hardware).
Nesse mesmo nível conceitual, "terreno do usuário" é o que roda no modo menos privilegiado (anel 3 em CPUs x86, modo de usuário em ARM ou MIPS, etc.). O usuário aproveita a maneira como o kernel suaviza pequenas diferenças de hardware, apresentando a mesma API para todos os programas. Por exemplo, algumas placas sem fio podem ter registros de controle extras em relação a outras ou conter mais ou menos buffer integrado para pacotes recebidos. O código do driver leva em conta essas diferenças (às vezes ignorando recursos avançados ou incomuns) e apresenta a mesma API de soquete para todos os programas.
Alguns processadores (por exemplo, x86, VAX, Alpha AXP) possuem mais de dois modos, mas a arquitetura Unix genérica não utiliza os modos intermediários.
Os programas e processos que você vê em execução no Unix, Linux ou *BSD são de propriedade do usuário. Como os processos são preemptivos, na verdade você nunca vê o kernel rodando, apenas vê efeitos colaterais, como read()o retorno de uma chamada de sistema ou uma função manipuladora de sinal em execução.
Para responder sua pergunta específica, em Unix, Linux, *BSD, um "driver" geralmente é um pequeno software que lida com as peculiaridades específicas de algum hardware: uma placa de rede, uma unidade de disco, uma placa de vídeo. O software do driver quase sempre precisa ser executado no Ring 0/modo supervisor/espaço do kernel para ter acesso às interrupções de hardware, ou à memória mapeada do hardware ou qualquer outra coisa. O driver cuida de recursos específicos de hardware e faz com que esse hardware se encaixe na visão padronizada ou convencionalizada do código do kernel de como o hardware deve funcionar. Portanto, executar um driver no usuário requer que o kernel mostre ao programa do usuário coisas como memória mapeada ou registros de dispositivo ou interrupções ou outros recursos especiais. Isso pode ser complicado, pois os recursos especiais que um dispositivo pode exigir não se enquadram facilmente na API usual do estilo Unix apresentada aos programas do usuário. Além disso, o agendamento é um problema, já que os programas de usuários geralmente não respondem às interrupções tão rapidamente.
Responder2
A maioria das CPUs modernas tem umnúcleoou modo supervisor e um modo restritodo utilizadormodo. Este é um recurso de hardware da CPU. "Userland" é outro nome para código executado em modo de usuário.
Uma grande diferença entre os modos é como o MMU da maioria das CPUs modernas atua sob eles.
Uma MMU permite que um kernel reorganize blocos (ou páginas) de RAM para que pareçam codificar em uma ordem diferente daquela em que estão fisicamente na RAM, e também faz com que o código do modo de usuário seja alterado.armadilhaou "falta"de volta ao modo kernel se certas páginas forem acessadas. O modo de usuário não pode alterar o que o MMU faz, apenas o modo kernel pode fazer isso.
Portanto, o MMU permite que o código do modo kernel faça todo tipo de coisas legais, como:
- "organizar" ou "mapear" a memória para o código do modo de usuário para que esse código pense que possui RAM contígua.
- implementar um esquema de gerenciamento de memória dinâmico onde um processo precisaria solicitar memória antes de tentar usá-la.
- interrompa os processos do usuário se eles usarem memória que não deveriam.
- troque as páginas menos usadas para o disco se a memória livre estiver baixa e troque-as de volta quando um processo tentar acessá-las.
Você pode ver que o MMU, junto com o modo kernel/usuário, é a base de um sistema operacional multitarefa e, usando essas ferramentas, é possível criar um sistema que funcione com coisas de nível superior, como a ideia de processos. Um kernel mantém tabelas de páginas para cada processo e basicamente reprograma a MMU antes de mudar para o modo de usuário e dar controle a um processo para seu intervalo de tempo. Coisas como malloconde um processo adquire memória estão fazendo com que o kernel modifique as tabelas de páginas MMU.
Novamente, o modo de usuário não pode fazer nada com as tabelas de páginas (e realmente não precisa saber que elas existem); se precisar de memória, precisaráchamaro kernel, o que causa uma mudança do modo de usuário para o modo kernel. As CPUs fornecem um mecanismo simples chamadointerrupção de softwarepara fazer isso,e existem outras maneiras mais rápidas que o kernel Linux usa.
Por causa dessa proteção que existe no modo de usuário, se um programa fizer algo como travar ou ficar descontrolado e se sobrescrever, o kernel poderá interromper esse processo. No modo kernel, esta proteção não existe, então o kernel irá parar de funcionar e assim todo o seu sistema também irá parar de funcionar. Quando um erro irrecuperável como esse acontece no modo kernel, ele é chamado de kernel panic. VerO que é um “pânico do kernel”?para detalhes.
o kernel pode executar esse driver na área do usuário
O modo kernel ou supervisor das CPUs também evita que o modo usuário acesse diretamente os dispositivos de E/S, a ideia é que ele tenha que chamar o kernel para fazer isso. No Linux, o código que se comunica diretamente com os dispositivos (eles são executados no modo kernel) édrivers de dispositivo(um tipo demódulo do kernel, você pode manipulá-los com comandos como lsmod, insmod, modprobee rmmod).
O que acontece se o driver do seu dispositivo, que estaria rodando no modo kernel na configuração mais simples, tiver um bug e fizer algo desagradável como sobrescrever coisas aleatórias na RAM (e como está no modo kernel, ele tem acesso irrestrito a toda a RAM e pode sobrescrever o próprio kernel). Seria bom se pudéssemos fazer o driver do dispositivo rodar em modo de usuário, de modo que ele não pudesse fazer nada ao próprio kernel ou a outros processos.
Infelizmente, mudar do modo usuário para o modo kernel (chamado demudança de contexto) é lento, pois basicamente todo o estado da CPU precisa ser ativado e desativado para cada processo ou para o próprio kernel. Então, temos duas coisas em desacordo, segurança ou velocidade, e portanto é um ponto de discórdia e de design.
Kernels que tentam fazer o máximo possível no modo usuário são chamadosmicronúcleos, e o Linux é o oposto, que é chamadomonolítico. Existem drivers de modo de usuário para Linux (veja o FUSE como exemplo) e há até umestruturaisso permite.
Responder3
Com base no que Bruce disse, todo código fornecido ao kernel deve ser confiável. Se houver alguma maneira de o código malicioso ser executado pelo kernel, o jogo termina. É aí que entra em jogo a separação de privilégios entre o código executado pelo usuário e o código executado pelo kernel. O código executado por um usuário não precisa necessariamente ser 100% livre de malefícios. Não é executado diretamente pelo kernel.
Os programas Userland simplesmente interagem com partes expostas do kernel, como APIs e módulos carregados. Um exemplo seria iptables. Existem vários módulos do kernel (.ko) ou 'drivers' que realmente fazem o trabalho do iptables, eles fazem parte doestrutura do netfilter. Ao executar comandos usando /sbin/iptablesvocê está usando o componente userland que por sua vez se comunica com os módulos netfilter que são carregados no kernel. Isso permite a separação para que o código do usuário não possa ser executado inadvertidamente pelo kernel.
Responder4
Nos sistemas operacionais Unix/Linux, diferimos entreespaço do usuárioeespaço do kernel. Isso são apenas sinônimos de userland e de onde o kernel pertence.
Você pode entender isso da seguinte maneira. Você pode interagir com tudo o que acontece no espaço do usuário. O que não é o caso no espaço do kernel. Daemons, bibliotecas e aplicativos pertencem ao espaço do usuário. Todo código executado fora do kernel do sistema operacional pertence ao espaço do usuário (userland).
O espaço do kernel é onde o próprio kernel é executado. É uma área restrita onde nem o root tem acesso. Mas o usuário root pode manipular alguns parâmetros do kernel por uma interface fornecida pelo kernel (procfs, sysfs).
A memória do sistema é um bom exemplo para explicar a diferença entre o kernel e o espaço do usuário. Um daemon (que roda no espaço do usuário) precisa de alguma memória para funcionar. O kernel gerencia toda a memória disponível. O daemon obtém alguma "memória virtual" do kernel, onde o daemon não sabe se é memória física ou espaço de troca ou qualquer outra coisa. O kernel é quem determina que tipo de memória o processo obtém. Porque o gerenciamento de memória acontece no espaço do kernel. Outras coisas que acontecem no espaço do kernel são agendamento de processos, comunicação entre processos, proteção e gerenciamento de memória, chamadas de sistema...
O que exatamente é a área do usuário?
Portanto, userland é o que o daemon faz (ou pode fazer) ao interagir com os recursos do sistema operacional (E/S, rede, memória, tempo de CPU). Esses recursos estão ocultos do processo no espaço do kernel.
A resposta curta:
É o que é a cabine de um avião para o piloto.