É oficial! Chegou o HarmonyOS, o novo sistema operativo da Huawei

arc says:

Vamos lá tentar esclarecer alguns factos, destinado aos menos esclarecidos e acabar de vez com tamanhas confusões!

* O que é um Kernel?

Vou abstrair e sendo assim, Kernel…mais não é do que um componente central de um SO.

Assim, a sua função é agir como sendo uma “interface” entre toda e qualquer aplicação e o user e com o hardware, sendo que o ÚNICO objectivo de um Kernel é precisamente realizar a gestão da comunicação entre o software presente nessa máquina, ou se quiserem todas as aplicações no user level, e o hardware (CPU, memória, etc) ou se quiserem a comunicação via IPC.

(Simplifiquei para não criar “nós” nos neurónios!), a quem ainda tem paciência para me ler no Pplware.

PS: se ainda se recordam, e abordei sem mencionar isto mesmo, quando escrevi:
“Deterministic Latency Engine e ainda com comunicação entre processos, o tal de IPC, de elevado desempenho.”, penso que foi em 2.

Back…

Eis as principais tarefas atribuídas a um qualquer Kernel:

+ Process Management
+ Device Management
+ Interrupt Handling
+ I/O Communication
+ File System, etc., etc.

* O Linux é um Kernel ou um Sistema Operativo?

Se olharmos para o que é um Kernel (acima em definição simples), então o Linux (Linux Kernel), NÃO é um SO.

Hein?!?!

Então como é possível um Kernel não ser um SO e porque quase todos o chamam de SO ao Kernel?

Vejamos…

Se o Kernel é o coração de um Sistema Operativo (seja ele qual for) e que realiza a gestão dos principais recursos de um Sistema Operativo, enquanto que algumas aplicações e outro tipo de utilitários são adicionados posteriormente ao Kernel, então SÓ assim poderemos ter um Sistema Operativo.

A pergunta que se impõe neste momento, é …. Então o que é um SO afinal?

Nada mais é do que: um kernel space e um user space, ambos em simbiose!!

Tão simples quanto isto, verdade?

Mas, voltemos pois, ao que muitos gostam de falar de Linux como sendo um SO e estão ERRADOS!

Assim se o Linux é um kernel e NÃO um SO, na medida em que não inclui aplicações como utilitários de sistema de ficheiros, windowing systems e ambientes gráficos, comandos de administração do sistema, editores de texto, etc., etc.

Então deve ser por isso isso mesmo que várias empresas, adicionam este e outros tipos de aplicações ao Linux Kernel e passam a disponibilizar um SO (Distribuições) como o Debian Linux, centOS, Arch Linux, etc., etc.

(IMPORTANTE: chamo à atenção, que o Linux Kernel, para além das suas multi-facetas, tem uma que eu gosto imenso, ele pode ser compilado para a execução numa grande variedade de CPUs e plataformas com diferentes limitações e necessidades de arquitectura. A titulo de exemplo, poderei citar, a sua capacidade de execução de um processo com uma MMU (Memory Mnagement Unit), bem como processos que não fornecem de todo suporte para MMU.).

Para não me alongar muito no tema, vou passar de imediato para as Diferenças entre um Microkernel e um Monolithic Kernel.

PS: existem mais tipos de kernel em *nix e derivados e não *nixs, mas por agora para não complicar vamos com estes “fazer a festa”.

Como escrevi acima, o kernel nada mais é do que a ponte entre as aplicações e o hardware do nosso computador, e NÃO é RIGOROSAMENTE mais NADA, por muito que andem por aí a dizerem o contrário!

* Classificações do Kernel

+ O kernel, pode ser classificado em: Microkernel e Monolithic Kernel (mas há mais: Hybrid Kernel, Nanokernel e Exo-Kernel, quem sabe um dia falo destes!!).

++ Microkernel, é todo o kernel em que os user services e os kernel services, são mantidos em separado no que se designa por address space. No entanto, no Monolithic Kernel, kernel user services e kernel services (ambos), são mantidos no mesmo address space.

Maionese do tema!?

* Microkernel versus Monolithic Kernel

+ No Microkernel, o user services e o kernel services, são mantidos em separado no address space.
+ No Monolithic Kernel, quer os users services bem como os kernel services, encontram-se no mesmo address space.

+ Microkernel, é sempre menor no seu tamanho.
+ Monolithic Kernel, é maior que o Microkernel.

+ Microkernel, tem sempre uma execução lenta.
+ Monolithic Kernel, tem sempre uma execução rápida.

+ Em termos de segurança para o Microkernel, se um qualquer serviço falhar, isso afecta grandemente o total funcionamento do Microkernel.
+ Em termos de segurança para Monolithic Kernel, se um qualquer serviço falhar, a totalidade do sistema pode falhar.

E muito mais haveria para dizer….

Mini Resumo

* Microkernel

Como user services são mantidos no user address space e kernel services são mantidos em kernel address space, então podemos afirmar, que EXISTE uma redução para o tamanho real do Kernel e ao mesmo tempo, EXISTE uma redução para o tamanho final do SO.

Vamos ao mix da “coisa”?

Além da comunicação entre as aplicações e o hardware presente no sistema, o Microkernel, fornece por si só serviços mínimos de gestão de memoria e processos.

As comunicações entre o programa cliente / aplicação e os serviços em execução no user address space é estabelecida, pelo que é designado por message passing, nunca interagindo directamente, reduzindo por isso mesmo a velocidade de execução do Microkernel.

PS: no caso vertente da Huawei (para nos situarmos todos), é aqui que entra o Ark Compiler (mas não só, no SO deles), como venho a descrever.

Num Microkernel, user services são isolados totalmente dos kernel services, assim se qualquer serviço do user falhar, isso mesmo não afecta o kernel service e por consequência o SO não sofre desse problema.

Esta é a PRINCIPAL vantagem do Microkernel.

Microkernel, é facilmente extensível, que isto dizer, se novos serviços forem necessários, eles vão ser adicionados ao user address space e por isso mesmo, o kernel space, não necessita de qualquer tipo de modificação.

Microkernel, é também seguro e confiável bem como portable.

* Monolithic Kernel

O kernel monolítico realiza a gestão de todos os recursos do sistema entre as aplicações e o hardware do sistema.
Mas,… contrariamente ao Microkernel, os user services e os kernel services, são implementados no mesmo address space.

Assim sendo, isto vai aumentar o tamanho do Monolithic Kernel e aumenta mais o tamanho do SO.

(lembram-se de eu ter escrito:

“NOTA: se eu me lembrar que aproximadamente 3/4 do code do Linux Kernel, são drivers, sistemas de ficheiros e arquitectura de código especifico, para além de uma abundância de comentários e linhas em branco, e se me lembrar ainda que o Linux kernel 5.2 vem com mais de 596.000 novas linhas de code (mais de 25 000 000 para o total do Linux Kernel 5.2)), olhem o que será este microkernel!”).

O Monolithic Kernel fornece CPU scheduling, gestão de memória, gestão de ficheiros e outra funções do sistema operativo via system calls.

NOTA: system calls, um tema “medonho, mas doce” para ser falado um dia, com muita paciência, que tem todo o cabimento ser debatido, na medida em que envolve a transferência de controlo do user space para o kernel space e todas as suas “implicações”.

Como os user service e os kernel services residem no mesmo address space, tem como resultante um SO com uma execução rápida.

Uma das desvantagens do Monolithic Kernel é que, se algum serviço falha, todo o sistema pode falhar.

Se um novo serviço for necessário ser adicionado no Monolithic Kernel, todo o sistema operativo deve ser modificado.

Simplifiquei ao máximo definições e conceitos, para facilitar a vida a quem precisa dum mini-mini manual do Kernel.

The End!