É possível deixar o kernel Linux menor se usarmos a diet libc ao invés da glibc?


Talvez depois do vídeo sobre o embutils tenha surgido a seguinte duvida: Se compilar programas utilizando a diet libc torna os programas menores, será então que é possível compilar o meu kernel utilizando a diet libc e torná-lo também menor?

A diet libc é uma biblioteca C que focada na otimização de tamanho dos programas (mesmo sendo utilizada estaticamente).

Tenho dois vídeos sobre a diet libc, um contando sua história e o ultimo sobre o embutils, uma vez que a diet libc é uma dependência do embutils. No primeiro vídeo também explico suas características e acredito que é uma grande solução:

Q: Por que ela não é compatível com a glibc? Eu achei que a interface fosse um padrão?
A: sim, a interface é, mas um monte de detalhes estão faltando. Por exemplo, a diet libc utiliza um layout de "struct stat" diferente da glibc. Nós utilizamos uma do kernel, glibc utiliza uma própria e linka translation code (código de tradução). Essa é a parte da razão porque a glibc é tão grande e tão feia. Se tivéssemos suporte a tudo isso, terminaríamos inchados quanto a glibc.
A glibc sempre teve esse grande defeito de gerar binários grandes demais e a equipe do projeto GNU nunca se importou com isso. O raciocínio apresentado por eles é basicamente o seguinte: "Com a quantidade crescente do poder do hardware, porque devemos nos preocupar com isso?"
E esse é até mesmo um erro cometido pela comunidade GNU. O projeto GNU e BSDs são muito bom no quesito recursos, porém não no resultado final de binários quando o quesito é tamanho. Tanto que antes de diet libc já havia surgido a uClibC para que pudessem estender Linux ao uso de embarcado (uma vez que é quase impossível utiliza glibc em embarcados).

Mais uma coisa que deve ser escolarecida sobre a diet libc é que já dizerem que a esta biblioteca originou do FreeBSD e foi portado para Linux. Na verdade não, essa biblioteca também é própria do Linux como descrito na mesma FAQ:
Porgunta: Pode portar a diet libc para FreeBSD/Solaris/Windows, por favor?
Resposta: Não.
Resposta grosseira; não? Mas no próprio site da diet libc consta em sua descrição que ela pode ser utilizada para criar para Linux binários pequenos lincados estaticamente nas arquiteturas alpha, arm, hppa, ia64, i386, mips, s390, sparc, sparc64, ppc e x86_64.

Bom, eu já postei um artigo complementar no blog Diolinux que vale a pena conferir, pois faço um complemento ao vídeo abaixo e até mesmo mostro o mesmo comando uname que mostra em sua saída o termo "GNU/Linux" assim como no toybox:


Bom, puderam ver como os binários ficam pequenos mesmo tendo biblioteca estaticamente linkada. Surge então a pergunta após ficarmos impressionados com isso. Isso significa que é possível compilar meu kernel Linux com a diet libc ou outra biblioteca do Linux e obter como resultado um kernel menor? Na FAQ mesmo menciona que utilizam um layout do kernel; logo significa que é possível?
A resposta: NÃO!
POR QUE? :(

Bora responder a pergunta. Como descrito na própria FAQ da diet libc:
Pergunta: Devo compilar meu kernel com a diet libc?
Resposta: O kernel não é lincado a nenhuma libc. De fato, a libc é a interface do user space para o kernel. Então, a não ser que você esteja falando sobre o "user mode linux" (que é uma versão especial do kernel que ocorre ser um programa user space), você não consegue lincar o kernel a diet libc.  Lincar o user space Linux com a diet libc deve ser possível em teoria, mas eu não acho que alguém já tentou de verdade.
Explicando melhor a função das bibliotecas C pode ser lido também na FAQ da Musl que descreve o seguinte:
musl é uma “libc”, uma implementação de funcionalidade de biblioteca padrão descritos na ISO C e nos padrẽos POSIX, mais extensões comuns, destinadas a uso em sistemas baseados em Linux. Onde o kernel (Linux) governa acesso ao hardware, memória, filesystems, e privilégios para acesso desses recursos, a biblioteca C é responsável por fornecer as aplicações reais do userspace das interfaces da função C e para a construção de bufferd stdio de alto nível, gerenciamento de alocação de memória, operações de criação de thread e sincronização e assim por diante utilizando interfaces de baixo nível que o kernel fornece, assim como para a implementação puras rotinas de biblioteca da linguagem C como strstr, snprintf, strtol, exp, sqrt, etc.
Passe o cursos do mouse para ler a tradução do texto

Então sempre tenhamos em mente, a biblioteca é para os programas que utilizamos no user space, não para o kernel. O kernel é independente da biblioteca. Linux é um kernel que cresceu e evoluiu para mais do que um kernel tendo bibliotecas, comandos, terminais, init systems e muito mais. Exemplos de bibliotecas do Linux além da diet libc temos a Bionic do Android, a musl, a UclibC, a  newlib e klibc.

Comente com o Facebook:

Nenhum comentário:

Postar um comentário

Viu algum erro e quer compartilhar seu conhecimento? então comente aí.

Observação: somente um membro deste blog pode postar um comentário.

Marcadores

A pior história sobre Linux que já ouvi (5) A.I (2) ambiente gráfico (19) AMD (14) analise (10) Andriod (16) android (7) Apple (1) arm (5) artigo (5) aws (1) bc (23) benchmark (6) BetrFS (1) blackhat (1) BSDs (31) btrfs (32) bugs (2) Caixa de Ferramentas do UNIX (19) canto do Diego Lins (2) certificações Linux (7) Código Fonte (54) comandos (33) comp (1) compressores (7) container (8) CPU (19) cracker (1) criptografia (5) crowdfunding (9) cursos (24) daemons (13) Debian (31) desempenho (2) desenvolvimento (98) desktop (19) DevOps (3) DevSecOps (4) dic (1) Dica de leitura (91) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diet libc (3) diocast (1) dioliunx (3) distribuições Linux (14) Docker (13) DragonflyBSD (22) driver (2) dropbear (3) ead Diolinux (2) edição de vídeo (5) embarcados (1) EMMI Linux (4) emuladores (9) endless (5) English interview (3) Enless OS (2) entrevista (17) espaço aberto (82) evento (6) facebook (1) Fedora (11) filesystem (82) financiamento coletivo (2) fork (4) fox n forests (4) FreeBSD (21) Funtoo Linux (13) games (94) garbage collector (1) gerenciadores de pacotes (4) glaucus (7) GOG (3) google (9) gpu (3) hacker (2) hardware (104) hash (1) helenos (3) I.A (1) init system (12) Intel (15) inteligencia artificial (2) IoT (1) ispconfig (1) jogos (38) kde (1) kernel (141) lançamento (64) leis (1) LFCS (1) libs (2) licenças (8) Linus (16) linus torvalds (2) Linux (194) linux foundation (3) linux para leigos (1) live (5) lkgr (1) LPI (8) LTS (1) Mac (1) machine learning (1) matemática (9) mesa redonda (27) microcontroladores (1) microsoft (6) microst (1) muito além do GNU (172) musl (3) não viva de boatos (9) navegadores (5) NetBSD (7) newlib (1) nim (6) nintendo (1) novatec (17) novidades (1) nuvem (1) o meu ambiente de trabalho (3) off-topic (12) ONLYOFFICE (1) open source (84) OpenBSD (7) OpenShift (1) oracle (1) os vários sabores de Linux (44) padrim (2) palestras e eventos (5) partições (6) pentest (8) performance (1) pipewire (1) plan9 (2) playstation (1) processadores (30) professor Augusto Manzano (11) Programação (68) promoção (1) propagandas com Linux (8) ps4 (1) real-time. (1) Red Hat (23) redes (4) resenha nerd (4) Resumo da Semana do Dlins (2) resumo do Tux (19) retrospectiva Linux (1) risc-V (14) RISCV (13) rtos (1) runlevel (2) rust (14) segurança digital (25) servidor web (2) servidores (3) shell (9) shell script (8) sistema operacional (25) skarnet (2) smartphones (3) Software livre e de código aberto (151) sorteio (3) Steam (10) Steam no Linux (8) supercomputadores (4) suse (6) systemd (8) terminal (89) terminal de comandos (19) toca do tux (1) toybox (27) tutorial (6) Tux (3) unboxing (7) UNIX (17) UNIX Toolbox (14) vartroy (1) vga (1) virtualização (3) vulnerabilidade (6) wayland (5) web (1) whatsapp (1) whitehat (1) Windows Subsystem for Linux (2) wine (14) WoT (1) yash (1) ZFS (16) zsh (3)