Guilherme Monteiro · São Paulo, SP

Quem paga o kernel: a engenharia corporativa por trás do Linux

Commits, mantenedores, subsistemas e dinheiro: quem escreve, quem paga e quem decide o kernel Linux em 2026.

3 de outubro de 202657 min de leitura

Resumo

O Linux começou em 1991 como hobby de um estudante, e é assim que muita gente ainda o imagina. Os números contam outra história. No kernel 7.2, lançado em agosto de 2026, 78,8% dos 16.418 commits vieram de pessoas com vínculo identificado pela LWN, seja empresa, consultoria ou instituição. Só 4,5% vieram de quem trabalhava por conta própria, contra 16,8% em 2009. Quem aceita os patches é ainda mais corporativo: no 6.19, só 1,6% das assinaturas de mantenedores vieram de gente sem empregador. Cgroups, KVM, eBPF, io_uring, Btrfs, sched_ext, PREEMPT_RT e o suporte a ARM64 nasceram de necessidades de empresas e chegaram ao mainline escritos por funcionários delas. Os robôs que testam o kernel também têm dono. Este artigo reconstrói essa história com o git log, o arquivo MAINTAINERS, as estatísticas da LWN e os relatórios da Linux Foundation, que destinou ao kernel 2,95% das despesas previstas para 2025. Mostra o que esse modelo explica e o que não resolve: revisão escassa, mantenedores sobrecarregados, concentração, sanções e a briga em torno do Rust. A origem foi pessoal. A infraestrutura é industrial.

De um hobby a uma linha de orçamento (1991–2005)

Em 25 de agosto de 1991, um estudante da Universidade de Helsinque postou no grupo comp.os.minix uma pesquisa curta sobre um sistema operacional que vinha escrevendo desde abril: "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones" [1]. No pós-escrito, Linus Torvalds avisou que o código não era portável e que provavelmente nunca rodaria em nada além de discos AT, "as that's all I have".

Trinta e cinco anos depois, o mesmo projeto fechou a versão 7.2 com 16.418 commits feitos em nove semanas por 2.652 pessoas, e a LWN identificou 249 empresas pagando parte delas [2]. O hobby não ficou grande e profissional por acaso. Ficou porque alguém começou a pagar.

Havia um concorrente óbvio. O BSD de Berkeley já tinha um porte para PC, o 386BSD, mas estava preso num processo longo sobre o status legal da fita Net/2, entre a Universidade da Califórnia e a dona do código Unix, a AT&T, depois a Novell. O acordo só saiu em 1994 e exigiu a remoção de três arquivos considerados "encumbered" [3]. Em novembro de 1993, Linus contou à revista Meta que nunca tinha testado o 386BSD: "If 386BSD had been available when I started on Linux, Linux would probably never had happened" [4]. O Linux cresceu numa janela aberta por um litígio entre uma universidade e uma empresa. Não seria o último litígio da história.

Os primeiros salários vieram de quem vendia o sistema. A Red Hat abriu capital em 11 de agosto de 1999, oferecendo 6 milhões de ações a US$ 14 [5]; no primeiro pregão, a ação abriu a US$ 48,50 [6]. Em novembro de 2001, as mensagens em que Marcelo Tosatti conduzia a série estável 2.4, a que rodava nos servidores da época, saíam de marcelo@conectiva.com.br [7]. A Conectiva era uma distribuição de Curitiba. O mantenedor da árvore estável do kernel estava na folha de pagamento de uma empresa brasileira.

Em dezembro de 2000, a IBM anunciou que gastaria US$ 1 bilhão com Linux em 2001, segundo a cobertura da News.com e da ZDNet reunida pela LWN [8]. Não encontrei o comunicado original da IBM. O vice-presidente de tecnologia, Irving Wladawsky-Berger, disse que a empresa já tinha investido cerca de 1 bilhão e que o número ia crescer, e a LWN comentou na mesma edição: "IBM is not a philanthropic organization. What they invest now they expect to get back" [9]. A IBM mantinha desde agosto de 1999 um Linux Technology Center, que em 2001 tinha cerca de 185 funcionários [10].

Em 31 de agosto de 2000, HP, Intel, IBM e NEC fundaram o Open Source Development Lab, o OSDL, com Caldera, Dell, Red Hat, SuSE, SGI e outras como patrocinadoras [11]. Em 17 de junho de 2003, Linus deixou a Transmeta, uma fabricante de processadores onde trabalhava havia mais de seis anos, e virou o primeiro "OSDL Fellow". O comunicado dizia que ele passaria a trabalhar "exclusively on leading the development of Linux" [12]. Pela primeira vez, o criador do kernel recebia para cuidar só dele, e quem pagava era um consórcio de fabricantes. Em janeiro de 2007, o OSDL se fundiu ao Free Standards Group e virou a Linux Foundation [13].

O dinheiro também mudava de mão em aquisições. Em 4 de novembro de 2003, a Novell anunciou a compra da SUSE: "Novell will pay $210 million in cash". No mesmo comunicado, a IBM se comprometia a investir US$ 50 milhões em ações preferenciais da Novell [14].

Três meses antes de Linus ir para o OSDL, em março de 2003, a SCO Group processou a IBM num tribunal de Utah por apropriação de segredos comerciais, interferência, concorrência desleal e quebra de contrato, pedindo indenização de "no less than $1 billion" [15]. A acusação de fundo era que código Unix tinha chegado ao Linux pelas mãos da IBM. Em agosto de 2007, a própria SCO informou à SEC a decisão contrária sobre a titularidade dos copyrights do UNIX, no processo contra a Novell [16]. O caso contra a IBM só terminou em 2021, com um acordo de US$ 14,25 milhões entre a IBM e o administrador da falência da SCO [17].

A resposta do kernel não foi jurídica, foi de processo. Em 23 de maio de 2004, Linus propôs que todo patch passasse a carregar uma linha Signed-off-by: [18]. A mensagem abre com "this crazy company called SCO", que teria dificuldade em acreditar que o open source funciona melhor "than their five engineers do". Quem assina certifica, pelo Developer's Certificate of Origin, que escreveu a contribuição ou tem o direito de repassá-la sob licença aberta [19], [20]. A assinatura nasceu como defesa contra um processo. Vinte anos depois, é ela que permite contar, patch por patch, quem trabalha para quem. É a matéria-prima de quase todas as estatísticas da próxima seção.

O controle de versão também veio de uma empresa. Durante a série 2.5, Linus adotou o BitKeeper, da BitMover. Era software proprietário, distribuído só em binário, com uma licença gratuita para projetos open source que impunha restrições [21]. Em novembro de 2003, alguém inseriu duas linhas na função wait4() do espelho CVS do kernel [22]:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
        retval = -EINVAL;

É um = no lugar de ==. Em vez de testar se o usuário era root, a linha o transformava em root. Quem chamasse wait4() com aquelas duas flags ganhava privilégio total. A mudança foi pega porque todo commit legítimo do CVS apontava para um changeset do BitKeeper, e aquele não apontava. Quem notou foi Larry McVoy, o dono da BitMover [22].

Em abril de 2005, a versão gratuita acabou. A LWN registrou que a gota d'água foi "a certain high-profile developer who refused to stop reverse engineering work while simultaneously doing some work for OSDL" [21]. Em 6 de abril, Linus escreveu que "the kernel team is looking at alternatives" e pediu que ninguém culpasse a BitMover [23]. No dia seguinte fez o primeiro commit de uma ferramenta nova: "Initial revision of "git", the information manager from hell" [24]. Em 16 de abril, o kernel entrou no Git com o commit 1da177e4, "Linux-2.6.12-rc2", sem o histórico anterior, que somaria "about 3.2GB" [25].

No mesmo período mudou o modelo de desenvolvimento. Na Kernel Summit de julho de 2004, Andrew Morton defendeu uma série 2.6 que continuasse mudando e deixasse "the distributors do the final stabilization work" [26]. As séries ímpares de desenvolvimento acabaram. A estabilização passou para quem vende suporte.

Data	Fato	Quem pagou ou motivou
ago/1991	Post no comp.os.minix	ninguém: um hobby
nov/1993	Linus diz que o 386BSD não estava disponível quando começou	o processo sobre o Net/2
ago/1999	IPO da Red Hat; Linux Technology Center	Red Hat; IBM
ago/2000	Fundação do OSDL	HP, Intel, IBM e NEC
dez/2000	US$ 1 bilhão para Linux em 2001	IBM
nov/2001	Série 2.4 conduzida de um e-mail da Conectiva	Conectiva
mar/2003	SCO processa a IBM	SCO
jun/2003	Linus vira o primeiro OSDL Fellow	OSDL, isto é, as empresas associadas
nov/2003	Novell compra a SUSE; tentativa de backdoor em `wait4()`	Novell e IBM; BitKeeper detecta
mai/2004	Developer's Certificate of Origin e `Signed-off-by`	resposta ao processo da SCO
abr/2005	Fim do BitKeeper gratuito; nasce o Git	BitMover

Em 2005, o kernel tinha um criador pago por um consórcio de fabricantes, uma regra de assinatura criada contra um processo corporativo e uma ferramenta de versionamento nascida de uma briga de licença. A origem foi pessoal. A infraestrutura que deixou o projeto crescer, não.

Quem escreve o kernel

Já escrevi por aí que uns 80% do kernel é feito por big tech. Fui conferir. O número está quase certo. A palavra, não.

Em fevereiro de 2007, Jonathan Corbet, editor da LWN, escreveu uns scripts para descobrir de onde vinha o código do 2.6.20. O método era simples e assumidamente imperfeito, porque "very few developers say 'I wrote this on behalf of my employer.'" Todo patch cujo endereço de e-mail indicasse uma empresa foi contado como trabalho daquela empresa [27]. A LWN repete a análise a cada versão desde então, e duas linhas das tabelas importam mais que as outras. "(None)" são desenvolvedores que a LWN sabe que trabalham por conta própria. "(Unknown)" são os que ela não conseguiu identificar, uma mistura de voluntários com funcionários que usam e-mail pessoal. Já em 2007, a conclusão era que "at least 65% of the code which went into 2.6.20 was created by people working for companies". O "pelo menos" vinha do fato de 25,0% dos commits estarem em "(Unknown)", e a hipótese de que todos fossem voluntários era tratada como "an unlikely result" [27].

Os relatórios anuais da Linux Foundation, escritos pelo mesmo Corbet com Greg Kroah-Hartman, chegaram ao mesmo lugar. Em 2008, estimavam que entre 70% e 95% dos desenvolvedores eram pagos, o que derrubaria o "'hobbyist' myth present from the start of open source development" [28]. Em 2012, eram 75% do desenvolvimento [29]. Em 2015, mais de 80% [30]. O relatório de 2017 é o mais direto: mesmo supondo que todos os "unknown" trabalhassem de graça, "well over 85 percent of all kernel development is demonstrably done by developers who are being paid for their work". A fatia sem salário tinha caído de 14,6% no relatório de 2012 para 8,2%, e a explicação dada é de mercado de trabalho: "kernel developers are in short supply, so anybody who demonstrates an ability to get code into the mainline tends not to have trouble finding job offers" [31]. O voluntário que dá certo vira funcionário.

A série da LWN mostra o pico do trabalho sem patrão em 2009, com 16,8% dos commits do 2.6.30 [32]. Depois, a fatia cai quase sem parar: 12,0% no 3.0 [33], 8,6% no 4.0 [34], 3,1% no 6.0 [35]. Houve uma exceção grande e instrutiva. No 6.7, de janeiro de 2024, "(None)" saltou para 18,1%. Não foi uma volta dos voluntários. Foi o bcachefs, um sistema de arquivos que Kent Overstreet desenvolveu "on his own, supported by interested users on Patreon", e cujo histórico inteiro entrou de uma vez [36]. Uma pessoa moveu a média do kernel inteiro, e o mesmo bcachefs sairia do mainline menos de dois anos depois, como a seção sobre tensões conta.

Versão	Lançamento	Commits (LWN)	Sem empregador, "(None)"	Não identificado, "(Unknown)"
2.6.20	04/02/2007	4.983	7,7%	25,0%
2.6.30	09/06/2009	11.733 até o rc7	16,8%	10,1%
3.0	21/07/2011	9.007 até o rc7	12,0%	6,3%
4.0	12/04/2015	pouco mais de 10.000	8,6%	7,1%
6.0	02/10/2022	15.402	3,1%	6,6%
6.7	07/01/2024	17.284	18,1% (bcachefs)	6,7%
6.18	30/11/2025	13.710	4,6%	9,5%
7.2	16/08/2026	16.418	4,5%	16,7%

As datas são as das tags no repositório do kernel [37]; as porcentagens contam commits, e as fontes são as matérias da LWN de cada versão [27], [32], [33], [34], [35], [36], [38], [2]. No ano de 2025 inteiro, do 6.13 ao 6.18, a LWN contou 5,3% sem empregador e 8,5% não identificados [38].

O "(Unknown)" de 16,7% do 7.2 é o número mais alto da série recente, e a própria LWN o atribui "partially, at least" à "ongoing flood of new developers entering the kernel community". Foram 613 estreantes, um recorde. No mesmo ciclo, 1.111 mudanças, "under 7% of the total", traziam a etiqueta Assisted-by, que declara o uso de ferramentas de IA, contra 301 no 7.1 [2]. O desconhecido está crescendo, e parte dele chega com um modelo de linguagem do lado.

Estas são as empresas do 7.2, por commits [2]:

Empregador	Commits	Parcela
(Unknown)	2.743	16,7%
Intel	1.512	9,2%
Google	1.191	7,3%
Red Hat	873	5,3%
AMD	813	5,0%
Qualcomm	767	4,7%
(None)	743	4,5%
NVIDIA	535	3,3%
Meta	441	2,7%
(Consultant)	429	2,6%
SUSE	358	2,2%
Renesas Electronics	328	2,0%
IBM	307	1,9%
Kylin	278	1,7%
NXP Semiconductors	264	1,6%

Volto à minha frase. Tirando "(Unknown)" e "(None)", sobram 12.932 dos 16.418 commits do 7.2, ou 78,8%, de gente com vínculo identificado: empresas, consultorias, universidades [2]. "Uns 80%" passa. "Big tech", não. As cinco maiores empresas nomeadas, Intel, Google, Red Hat, AMD e Qualcomm, somam 5.156 commits, 31,4%. As dez maiores, 43,4%. O resto se espalha por 249 empregadores: fabricantes de chips como Renesas e NXP, consultorias como BayLibre e Bootlin, distribuições como SUSE e Kylin. Por linhas alteradas, a ordem muda: a AMD lidera, com 22,4% [2]. O kernel não é escrito por meia dúzia de empresas. É escrito por uma indústria inteira.

Escrever é metade do poder. A outra metade é aceitar. Quando um mantenedor aplica um patch na sua árvore, acrescenta o próprio Signed-off-by; contar essas assinaturas de quem não é o autor mostra quem controla o que entra. Em 2009, 42,4% delas eram de funcionários da Red Hat [32]. Em 2017, "over half of the patches going into the kernel pass through the hands of developers employed by just five companies" [31]. Em 2023, a LWN refez a conta e chegou ao mesmo ponto: "over 50% of the changes going into the kernel pass through the hands of maintainers working for just five companies" [39]. No 6.19, de fevereiro de 2026, a Meta lidera, e as assinaturas de mantenedores sem empregador são 1,6% [40].

Empregador	2.6.30 (2009)	4.8 a 4.13 (2017)	6.19 (2026)
Red Hat	42,4%	20,6%	4,9%
Intel	9,5%	9,7%	9,5%
Google	6,6%	7,4%	9,9%
Linux Foundation	2,2%	9,1%	3,4%
Novell, depois SUSE	13,8% (Novell)	2,4% (SUSE)	3,2% (SUSE)
Linaro	fora da lista	7,9%	6,0%
Meta (antes Facebook)	fora da lista	2,0%	11,8%
Arm	fora da lista	1,3%	8,9%
AMD	fora da lista	2,4%	6,5%
Sem empregador	4,1%	3,9%	1,6%

A tabela mostra Signed-off-by de quem não é o autor do patch, isto é, de quem aceitou o código [32], [31], [40]. "Fora da lista" quer dizer que a empresa não aparece entre as publicadas naquele levantamento.

E quem lê o que entra? As etiquetas do commit contam parte da história. Contei no git log a fatia de commits com pelo menos um Reviewed-by, Acked-by ou Tested-by [37]:

Versão	Commits sem merge	Reviewed-by	Acked-by	Tested-by	Pelo menos um dos três
2.6.20	4.768	0,0%	10,2%	0,1%	10,3%
3.0	9.153	7,5%	13,6%	3,8%	22,4%
4.0	10.346	16,8%	15,5%	5,6%	34,1%
5.0	12.808	31,6%	16,6%	5,7%	46,2%
6.0	15.402	39,2%	16,2%	9,0%	52,9%
7.0	14.251	53,8%	13,3%	9,4%	64,1%
7.2	16.418	48,2%	13,6%	8,0%	58,6%

O método é o seguinte: git log --no-merges entre as tags de cada versão, num clone do repositório torvalds/linux de 2 de outubro de 2026, contando os commits cuja mensagem tem uma linha começando por uma das três etiquetas. Nas versões antigas, as contagens do git log diferem um pouco das da LWN, que usava outro recorte. Para o 6.18, a LWN registrou 53,6% com Reviewed-by e chamou o número de "typical" [38]. Em 2026, então, de cada cinco commits, dois entram sem nenhuma etiqueta de revisão, só com a assinatura de quem escreveu e de quem aplicou. No 7.2, foram 6.794. Isso não quer dizer que ninguém leu: muito review acontece na lista sem virar etiqueta, e o mantenedor que aplica um patch lê o que aplica. Mas "qualquer um pode auditar o kernel" pede um asterisco. Poder, pode. O registro de que alguém além do autor e do mantenedor olhou existe em pouco mais da metade do que entra.

A academia chega a números parecidos por outros caminhos. A tese de Urs Lerch na TU Berlin analisou todos os logs do kernel de 2007 e concluiu que "commercial companies contribute 75 percent to the kernel development" [41]. Um estudo de 2014 sobre o open source em geral estimou que cerca de metade do trabalho é pago [42]. O kernel está bem acima dessa média.

Por commits, quatro em cada cinco vêm de quem está na folha de pagamento de alguém. Pelo poder de aceitar, são mais de 95%. O voluntário existe, é mensurável e está nas bordas: 4,5% do código do 7.2 e 1,6% das chaves do 6.19.

Feito sob encomenda: subsistemas de origem corporativa

O post de 1991 dizia que o sistema "is NOT protable (uses 386 task switching etc)" e que provavelmente nunca suportaria nada além de discos AT [1]. No 7.2, o kernel tem 37,7 milhões de linhas de código-fonte em C, Rust e assembly; 69,0% delas estão em drivers/, e o diretório arch/ tem 21 subdiretórios [37]. Contei os arquivos .c, .h, .rs e .S da tag v7.2 direto dos objetos do Git. Cada um desses diretórios tem alguém pagando. Esta seção percorre os subsistemas que mais mudaram o que o Linux é, sempre com o mesmo roteiro: o problema de uma empresa, o mecanismo que o resolveu, as alternativas que perderam e o caminho até o mainline.

cgroups e namespaces: a base dos contêineres

Em 14 de setembro de 2006, Rohit Seth mandou para o LKML a introdução de um patch chamado containers. A justificativa era de data center: "Commodity HW is becoming more powerful", e rodar cargas diferentes na mesma máquina exigia "a notion of limits for each workload in Linux kernel" [43]. Seth escrevia de um endereço do Google, e o trabalho passou para Paul Menage, que "like Rohit, posts from a google.com address" [44]. Anos depois, o artigo do Google sobre o Borg, o orquestrador interno da empresa, diria que "all Borg tasks run inside a Linux cgroup-based resource container" [45].

No Ottawa Linux Symposium de 2007, Menage, com Balbir Singh e Srivatsa Vaddagiri, do Linux Technology Center da IBM, apresentou um framework genérico construído sobre os cpusets que já existiam [46]. O desenho é barato de propósito: cada tarefa ganha um único ponteiro para um css_group compartilhado, e "the space overhead is one pointer per task, and the time overhead is one reference count operation per fork()/exit()". Das alternativas da época, os ResGroups perderam porque "the additional overheads that it introduces are unnecessary" [46]. O commit de Menage entrou no 2.6.24, lançado em janeiro de 2008 [47].

A primeira versão permitia várias hierarquias independentes. Não funcionou: a documentação da versão 2, escrita por Tejun Heo, diz que essa flexibilidade "wasn't useful in practice" [48]. A hierarquia unificada entrou como experimental no 3.16 [49] e foi considerada estável no 4.5 [50]. A interface continua sendo um sistema de arquivos [48]:

mkdir /sys/fs/cgroup/job
echo "+memory +cpu" > /sys/fs/cgroup/cgroup.subtree_control
echo 512M > /sys/fs/cgroup/job/memory.max
echo $$ > /sys/fs/cgroup/job/cgroup.procs

Em 2018, o Facebook acrescentou o PSI, que mede quanto tempo as tarefas passam travadas esperando CPU, memória ou I/O. O recurso, "developed by Facebook engineer Johannes Weiner" [51], já era "used within Facebook for some time" quando foi proposto [52], e entrou no 4.20 [53].

Os cgroups limitam quanto um processo usa. Os namespaces limitam o que ele vê. A ideia vem do Unix de pesquisa: "The Use of Name Spaces in Plan 9", de Rob Pike, Ken Thompson e colegas da Bell Labs [54]. Eric Biederman citou a inspiração no OLS de 2006 e mirou a alternativa da época: "Hypervisor solutions like Xen are nice but they impose a performance penalty" [55]. Os namespaces entraram aos pedaços ao longo de quase dezoito anos: montagem no 2.4.19, UTS e IPC no 2.6.19, PID no 2.6.24, rede completa por volta do 2.6.29 e usuário no 3.8 [56], cgroup no 4.6 [57] e tempo no 5.6 [58]. Os autores vieram de toda parte: o UTS saiu de um endereço @us.ibm.com [59]; o PID foi "developed by the OpenVZ team with the help of IBM" [60]; o de cgroup foi escrito no Google; o de tempo, numa parceria entre OpenVZ e Arista [57], [58]. No meio desse trabalho estava um brasileiro: os commits de Glauber Costa que estenderam a contabilidade de memória dos cgroups saíram de @parallels.com em 2013 [37]. Os contêineres que viraram padrão na indústria são, no kernel, essas duas peças combinadas.

KVM: da Qumranet à Red Hat

Em 19 de outubro de 2006, Avi Kivity apresentou ao LKML um driver chamado KVM. A ideia era aproveitar as extensões de virtualização que Intel e AMD tinham acabado de pôr nos processadores e deixar todo o resto com o Linux: "Each virtual machine is a process on the host; a virtual cpu is a thread in that process. kill(1), nice(1), top(1) work as expected." O driver acrescenta "a third execution mode", o modo convidado, ao lado dos modos kernel e usuário; qualquer acesso a dispositivo de I/O é interceptado e devolvido ao espaço de usuário, onde um QEMU levemente modificado emula o hardware [61]. O escalonador, o gerenciamento de memória e as ferramentas de processo do Linux passam a valer para máquinas virtuais sem código novo para isso.

O artigo do OLS de 2007, assinado por quatro engenheiros da Qumranet e um da IBM, descreve o resto: uma tabela de ponteiros de função, kvm_arch_ops, separa Intel de AMD; tabelas de páginas sombra mantêm a memória do convidado coerente; um log de páginas sujas permite migrar uma máquina virtual em funcionamento; e "In kvm, I/O virtualization is performed by userspace" [62]. Para quem usa, tudo é ioctl sobre /dev/kvm [63]:

int kvm  = open("/dev/kvm", O_RDWR);
int vm   = ioctl(kvm, KVM_CREATE_VM, 0);
int vcpu = ioctl(vm, KVM_CREATE_VCPU, 0);
struct kvm_run *run = mmap(NULL, ioctl(kvm, KVM_GET_VCPU_MMAP_SIZE, 0),
                           PROT_READ | PROT_WRITE, MAP_SHARED, vcpu, 0);
for (;;) {
        ioctl(vcpu, KVM_RUN, 0);          /* roda o convidado até uma saída */
        if (run->exit_reason == KVM_EXIT_IO || run->exit_reason == KVM_EXIT_MMIO)
                emular_dispositivo(run);  /* o espaço de usuário faz o papel do hardware */
}

Do primeiro e-mail à versão estável foram menos de quatro meses: o commit, de avi@qumranet.com, entrou no 2.6.20, lançado em 4 de fevereiro de 2007 [64]. O concorrente, o Xen, só teve o suporte a dom0 aceito no 3.0, em 2011 [65]. Em setembro de 2008, a Red Hat pagou "approximately $107 million in cash" pela Qumranet [66]. No 3.0, o MAINTAINERS listava dois mantenedores do KVM, Avi Kivity e Marcelo Tosatti, o mesmo do 2.4, ambos com e-mail @redhat.com [67]. Glauber Costa escreveu parte do kvmclock, o relógio paravirtualizado do KVM, também de @redhat.com [37].

Hoje o KVM sustenta as maiores nuvens. A AWS diz que o hypervisor do Nitro "is built on core Linux Kernel-based Virtual Machine (KVM) technology" [68]. O Google Cloud roda KVM com um monitor de máquina virtual próprio, porque "Google does not use QEMU" [69]. No 7.2, o KVM é mantido por Paolo Bonzini, de endereço da Red Hat, e o KVM para x86 também por Sean Christopherson, do Google; as duas entradas são Supported [70].

eBPF e XDP: programas dentro do kernel

O BPF original é de 1992, de Steven McCanne e Van Jacobson, no Lawrence Berkeley Laboratory: uma máquina virtual de registradores para filtrar pacotes dentro do kernel, "10 to 150 times faster than Sun's NIT" [71]. Por duas décadas, serviu ao tcpdump e a pouco mais.

Em março de 2014, Alexei Starovoitov, de @plumgrid.com, reescreveu o interpretador interno com um conjunto de instruções "designed to be JITed with one to one mapping" [72]. Entrou no 3.15. Em setembro do mesmo ano veio a syscall bpf(), com os maps, estruturas de dados compartilhadas entre o programa no kernel e o espaço de usuário, que entrou no 3.18 [73]. Havia um concorrente, o ktap, outra máquina virtual para tracing. A LWN resumiu o impasse: "Putting one virtual machine into the kernel for tracing is a hard sell; adding two of them is not really seen as an option by anybody involved" [74]. Ficou o BPF.

O que torna aceitável rodar código de usuário dentro do kernel é o verifier. Ele percorre o programa como um grafo acíclico, recusa laços e acompanha o estado de todos os registradores e posições da pilha antes de aceitar a carga; só então o JIT traduz para instruções nativas [75].

Em julho de 2016, Brenden Blanco, também de @plumgrid.com, acrescentou o XDP, um tipo de programa que roda no driver de rede antes de o kernel alocar suas estruturas para o pacote [76]. Entrou no 4.8. O artigo do XDP na CoNEXT de 2018, com autores da Red Hat, da Cilium e de outras empresas e universidades, mediu 24 milhões de pacotes por segundo num núcleo, contra 43,5 milhões do DPDK, que tira a placa de rede do kernel [75]. A troca é deliberada: menos velocidade bruta, mas o pacote continua no kernel, com firewall, roteamento e o resto.

Starovoitov foi para o Facebook, de onde commitou entre 2016 e 2018 [37]. Em 2019, a empresa tinha "about 40 BPF programs running on each server, with another 100 that are demand loaded" [77]. Em 2020, KP Singh, do Google, levou o BPF aos hooks de segurança do kernel no 5.7 [78], apesar da objeção de Casey Schaufler: "This effectively exposes the LSM hooks as external APIs. It would mean that we can't change or delete them" [79]. Em outubro de 2024, o conjunto de instruções virou padrão da IETF, o RFC 9669, que avisa que eBPF "is no longer an acronym for anything" [80].

io_uring: Meta escreve, Google desliga

O Linux já tinha uma interface de I/O assíncrono, a AIO, mas ela servia mal a quem usava o page cache: "buffered I/O has always been a bit of a sore spot for Linux AIO" [81]. Em janeiro de 2019, Jens Axboe, mantenedor da camada de blocos, propôs outro caminho [82]. Axboe passou pela SUSE, pela Oracle e pela Fusion-io e commitou de @fb.com entre 2014 e 2017 [37]; o perfil público dele no GitHub ainda declara o Facebook como empresa [83].

O mecanismo cabe numa frase do commit: "The submission queue (SQ) and completion queue (CQ) rings are shared between the application and the kernel. This eliminates the need to copy data back and forth to submit and complete IO" [82]. A aplicação escreve pedidos num array de io_uring_sqe, põe os índices no anel de submissão e chama io_uring_enter() uma vez para o lote inteiro; os resultados aparecem como io_uring_cqe no anel de conclusão, que ela lê sem chamada de sistema.

 aplicação                                 kernel
 ---------                                 ------
 preenche SQEs no array
 escreve índices no SQ ring ---------->    consome o SQ ring, executa o I/O
 io_uring_enter(fd, n, ...) ---------->    (uma syscall para n pedidos)
 lê CQEs do CQ ring         <----------    escreve uma CQE por pedido concluído

 SQ ring, CQ ring e array de SQEs ficam em memória compartilhada (mmap)

Cada conclusão é uma estrutura de 16 bytes, que dobra com a opção IORING_SETUP_CQE32 [37]:

struct io_uring_cqe {
	__u64	user_data;	/* sqe->user_data value passed back */
	__s32	res;		/* result code for this event */
	__u32	flags;
	__u64	big_cqe[];	/* só existe com IORING_SETUP_CQE32 */
};

Entrou no 5.1, em maio de 2019. A conta veio depois. Em junho de 2023, o Google publicou que, no kCTF, seu programa de recompensas por exploits de kernel, "60% of the submissions exploited the io_uring component of the Linux kernel (we paid out around 1 million USD for io_uring alone)". A empresa desligou o io_uring no ChromeOS, bloqueou o acesso de apps no Android e escreveu: "It is disabled on production Google servers" [84]. Dois meses depois, um engenheiro do Google, Matteo Rizzo, mandou o sysctl io_uring_disabled, que entrou no 6.6 [85]. Um subsistema escrito por quem trabalhava numa empresa ganhou o interruptor escrito por outra.

Btrfs e XFS: sistemas de arquivos com crachá

Em 12 de junho de 2007, Chris Mason anunciou um sistema de arquivos novo: "After the last FS summit, I started working on a new filesystem that maintains checksums of all file data and metadata." O código tinha "a sparsely commented 10,547 lines" [86]. O Btrfs organiza tudo em árvores B com cópia na escrita: nada é sobrescrito no lugar, e um snapshot é uma raiz nova que compartilha blocos com a anterior [87]. Entrou no 2.6.29, em março de 2009 [88].

A história do Btrfs acompanha os crachás de Mason: 972 commits dele saíram de @oracle.com, 44 de @fusionio.com e, a partir de dezembro de 2013, 148 de @fb.com e 34 de @meta.com [37]. Josef Bacik fez caminho parecido, de Red Hat a Fusion-io e Facebook [37]. No Facebook, o Btrfs virou a raiz dos contêineres internos: "Containers in this system use Btrfs for the root filesystem" [89]. As distribuições escolheram lados. A Red Hat descontinuou o Btrfs no RHEL 7.4 e avisou que ele "will be removed in a future major release" [90]. O Fedora, com Bacik entre os autores da proposta, adotou o Btrfs como padrão no Fedora 33 [91]. No 7.2, os dois mantenedores do Btrfs são Mason, de @fb.com, e David Sterba, de @suse.com [70].

O XFS veio de outra era. A Silicon Graphics o descreveu na USENIX de 1996: grupos de alocação independentes, árvores B+ para o espaço livre e alocação adiada, em que o sistema "simply reserves blocks in the file system for the data buffered in memory" [92]. O código entrou no Linux no 2.5.36, em setembro de 2002, e o anúncio de Linus resumiu: "Big patch, most of it due to the XFS merge" [93]. Anos depois, a Red Hat o descreveria como sistema "originally designed at Silicon Graphics, Inc." e o tornaria "the default file system for Red Hat Enterprise Linux 7" [94]. A verificação com o sistema montado, o scrub, começou em 2017 com Darrick Wong, de @oracle.com [95].

Schedulers: O(1), CFS, EEVDF e sched_ext

O escalonador é o código mais disputado do kernel, e a disputa conta a tese melhor que qualquer tabela.

Em janeiro de 2002, Ingo Molnar anunciou "a pretty radical rewrite of the Linux scheduler", o O(1), com os patches hospedados em redhat.com/~mingo [96]. Em março de 2007, Con Kolivas propôs o RSDL, um escalonador sem heurísticas de interatividade e com justiça completa [97]. Um mês depois, Molnar respondeu com o Completely Fair Scheduler e foi explícito: "i'd like to give credit to Con Kolivas for the general approach here: he has proven via RSDL/SD that 'fair scheduling' is possible and that it results in better desktop scheduling". O CFS trocou as filas de prioridade por "a time-ordered rbtree to build a 'timeline' of future task execution" [98] e entrou no 2.6.23 [99]. A ideia que ganhou foi a de Kolivas. O código que entrou foi o do engenheiro da Red Hat.

Dezesseis anos depois, Peter Zijlstra substituiu o miolo do CFS pelo EEVDF, um algoritmo publicado em 1995 por Ion Stoica e Hussein Abdel-Wahab, da Old Dominion University [100]. A promessa era apagar "a whole [bunch] of icky heuristics code" com uma política bem definida [101]. Cada tarefa tem um lag, a diferença entre o tempo de CPU que mereceria e o que recebeu; o EEVDF "picks tasks with lag greater or equal to zero and calculates a virtual deadline (VD) for each, selecting the task with the earliest VD to execute next" [102]. Entrou no 6.6, com um commit assinado "Peter Zijlstra (Intel)" [103].

Em 2023, Tejun Heo propôs o contrário de um escalonador melhor: deixar cada um escrever o seu, em BPF. O sched_ext, escrito com David Vernet, Josh Don e Barret Rhoden [104], ouviu do mantenedor do escalonador: "I hate all of this. Linus NAK'ed loadable schedulers a number of times in the past and this is just that again -- with the extra downside of the whole BPF thing on top" [104]. Em junho de 2024, Linus decidiu por cima do mantenedor: "I honestly see no reason to delay this any more" [105]. O commit tem Vernet como coautor, de @meta.com, e três Acked-by de endereços @google.com [106]; o perfil de Heo no GitHub declara o Facebook [107]. Entrou no 6.12. Um escalonador em BPF é uma tabela de funções que o kernel chama nos momentos certos, e qualquer erro o derruba de volta para o escalonador padrão [108]:

/* kernel/sched/ext/internal.h, Linux 7.2 (trecho) */
struct sched_ext_ops {
	s32 (*select_cpu)(struct task_struct *p, s32 prev_cpu, u64 wake_flags);
	void (*enqueue)(struct task_struct *p, u64 enq_flags);
	void (*dequeue)(struct task_struct *p, u64 deq_flags);
	void (*dispatch)(s32 cpu, struct task_struct *prev);
	void (*running)(struct task_struct *p);
	void (*stopping)(struct task_struct *p, bool runnable);
	s32 (*init_task)(struct task_struct *p, struct scx_init_task_args *args);
	/* ... */
	u32 timeout_ms;
	char name[SCX_OPS_NAME_LEN];
};

Os dois lados do debate eram funcionários de empresas: o mantenedor que assina como Intel e os autores ligados à Meta e ao Google. Quem arbitrou foi Linus, que aparece como "Fellow" na folha de pagamento da Linux Foundation [109].

Drivers: o kernel é, sobretudo, suporte a hardware

Em 5 de julho de 2015, Linus abriu o 4.2-rc1 avisando que aquele parecia "the biggest rc we've ever had, with over a million lines added". A explicação vinha em seguida: "just those register descriptor headers alone are about 41% of the entire patch". O resto do driver novo da AMD, o amdgpu, era outros 8%, o que deixava o kernel "in the somewhat odd situation where a single driver is about half of the whole rc1 in number of lines" [110]. O commit central do amdgpu é de Alex Deucher, de @amd.com [111].

Onze anos depois, contei a árvore drivers/gpu/drm/amd no 7.2: 6.343.652 linhas, ou 16,8% de todo o código-fonte do kernel. Só os headers de registradores em include/asic_reg/ somam 4.977.963 linhas, 13,2% do kernel [37]. A árvore de um único driver tem mais linhas que arch/, fs/, net/ e kernel/ somados, que chegam a 6,01 milhões [37]. A maior parte dela descreve os registradores dos chips de uma empresa, e os dois mantenedores, numa entrada Supported, têm e-mail @amd.com [70].

A Intel tem dois drivers gráficos. O i915 soma 418.774 linhas, e o xe, para as GPUs a partir de Tiger Lake, 139.555 [37]. O xe entrou no 6.8, e o commit inicial declara 16 coautores: 12 com endereço da Intel, um da Red Hat e uma da Collabora [112].

A NVIDIA foi o contraexemplo por muito tempo. O nouveau, "a reverse-engineered driver for Nvidia graphic cards", entrou em staging no 2.6.33, em 2010 [113]. Em maio de 2022, a NVIDIA publicou seus próprios módulos de kernel com licença dupla GPL e MIT, mas fora da árvore principal [114]. Em 2025, entrou no 6.15 o nova-core, escrito em Rust e "intended to serve as the successor of Nouveau for all GSP-based GPUs" [115]. O autor, Danilo Krummrich, commitou de @redhat.com de 2022 a 2024 [37], e no 7.2 divide a manutenção com Alexandre Courbot, de @nvidia.com [70].

Na rede, o padrão se repete. O mlx5, driver da Mellanox para as placas Connect-IB, entrou no 3.11, em 2013, escrito por Eli Cohen, de @mellanox.com [116]. Em abril de 2020, a NVIDIA concluiu a compra da Mellanox por US$ 7 bilhões [117]. Os quatro mantenedores do mlx5 no 7.2 têm endereço @nvidia.com [70].

Arquiteturas: cada processador, um patrocinador

A IBM chegou cedo. O porte para mainframe, o s390, apareceu no patch do 2.2.14, publicado em janeiro de 2000, com cabeçalhos que dizem "Copyright (C) 1999 IBM Deutschland Entwicklung GmbH, IBM Corporation" [118]. O ppc64, para os servidores POWER, chegou na série de desenvolvimento no 2.5.5, em fevereiro de 2002, também com código de copyright da IBM [119]. No 7.2, os mantenedores do s390 e do PowerPC têm todos endereço @linux.ibm.com, e as duas entradas são Supported [70].

O ARM foi o caso da bagunça. Em 2010, a LWN contava "nearly 70 different sub-architectures" no diretório ARM, uma por chip ou SoC, e registrava a fundação do Linaro por Arm, Freescale, IBM, Samsung, ST-Ericsson e Texas Instruments, com orçamento de "tens of millions of dollars, much of which will pay for 80 employees" [120]. Em março de 2011, Linus perdeu a paciência: "Gaah. Guys, this whole ARM thing is a f*cking pain in the ass" [121]. O suporte a 64 bits veio da própria Arm, num "36-part patch set" de Catalin Marinas [122], com o commit inicial em endereços @arm.com de Marinas e Will Deacon [123]. Entrou no 3.7, em dezembro de 2012. O suporte à família MSM, da Qualcomm, entrou no 2.6.25 pelas mãos de um engenheiro do Google, Brian Swetland [124]; no 2.6.35, os três mantenedores da plataforma tinham endereço @codeaurora.org [125].

O RISC-V repetiu o roteiro. O commit inicial é de Palmer Dabbelt, de julho de 2017 [126], e o MAINTAINERS do 4.15 o lista, com Albert Ou, em endereços @sifive.com, numa entrada marcada como Supported, o status que o próprio arquivo define como "Someone is actually paid to look after this" [127].

PREEMPT_RT: vinte anos fora da árvore

Em 13 de outubro de 2004, Ingo Molnar publicou o que chamou de "the first correct conversion of the Linux kernel to a fully preemptible (fully mutex-based) preemption model", de novo hospedado em redhat.com/~mingo [128]. A ideia é fácil de dizer e difícil de fazer: num kernel de tempo real, "spinlock_t is mapped to a separate implementation based on rt_mutex", um lock que dorme e herda prioridade, e os tratadores de interrupção rodam em threads. Só o raw_spinlock_t continua girando, "a strict spinning lock implementation in all kernels, including PREEMPT_RT kernels" [129].

Levou vinte anos. O patch viveu fora da árvore principal, e os pedaços entraram aos poucos: interrupções em threads no 2.6.30, por Thomas Gleixner, de @linutronix.de [130], e o símbolo CONFIG_PREEMPT_RT no 5.3 [131]. Em 2015, a Linux Foundation montou um projeto para financiar o trabalho, com o Google como membro Platinum fundador e National Instruments, OSADL e Texas Instruments como membros Gold; Gleixner, que mantinha o ramo "for more than a decade", virou Linux Foundation Fellow [132]. Em 2022, a Intel comprou a Linutronix, que ela mesma descreveu como "the architect of PREEMPT_RT (Real Time)" [133]. O último obstáculo era o printk, reescrito com consoles que não dependem do lock global [134]; o commit que liberou o x86 registra que, "with the recent printk changes, the last known road block has been addressed" [135]. Em setembro de 2024, o pull request de Gleixner dizia: "After twenty years of development we finally reached the point to enable PREEMPT_RT support in the mainline kernel" [136]. A justificativa do commit do x86 começa com uma frase: "It is really time." [135]. Entrou no 6.12. No ano de 2025, a Linutronix aparece entre os 20 empregadores com mais commits no kernel, com 1.149 [38].

Rust for Linux: um experimento com patrocínio

Em abril de 2021, Miguel Ojeda enviou a proposta de Rust no kernel. Linus reclamou de patches específicos, mas disse: "on the whole I don't hate it" [137]. Naquele mesmo abril, o Internet Security Research Group, a organização sem fins lucrativos por trás do Let's Encrypt, deu a Ojeda um contrato de um ano em tempo integral, "made possible through financial support from Google" [138]. O suporte entrou no 6.1, em dezembro de 2022, num pull request que agradecia a 173 pessoas e informava: "Miguel is the primary maintainer" [139].

As empresas vieram atrás. Wedson Almeida Filho, um dos primeiros mantenedores, commitou de @google.com e depois de @microsoft.com [37]. O driver Binder do Android, reescrito em Rust por Alice Ryhl, de @google.com, entrou no 6.18. O commit começa com "We're generally not proponents of rewrites (nasty uncomfortable things that make you late for dinner!)" e explica o porquê: o Binder em C, com cerca de 6 mil linhas, "combines/nests 13 different locks, 7 reference counters, and atomic variables" [140]. O nova-core, da Red Hat com a NVIDIA, é Rust desde o primeiro commit [115].

Em dezembro de 2025, na Maintainers Summit, o experimento foi declarado encerrado. A LWN registrou que o código Rust tinha crescido "by a factor of five over the last year" e que aparelhos com Android 16 e kernel 6.12 já traziam um módulo em Rust, o ashmem: "So there are millions of real devices running kernels with Rust code now" [141]. O commit de Ojeda que tira o rótulo de experimental, no 7.0, termina pedindo exatamente o que este artigo descreve: "I hope this signals commitment from the kernel to companies and other entities to invest more into it, e.g. into giving time to their kernel developers to train themselves in Rust" [142]. No 7.2, o Rust ainda é pouco: 473 arquivos .rs, 182.584 linhas, 0,5% do código-fonte [37]. A briga política em torno dele fica para a seção sobre tensões.

Um patch para jogar no Linux

O padrão vale também em escala pequena. Jogos de Windows esperam vários eventos ao mesmo tempo com WaitForMultipleObjects; o futex() do Linux esperava um endereço por chamada. Em 30 de julho de 2019, Gabriel Krisman Bertazi, de @collabora.com, mandou o FUTEX_WAIT_MULTIPLE, com duas assinaturas de @valvesoftware.com. Com ele, no Proton, "using futexes in our Wine use case reduced the CPU utilization by 4% for the game Beat Saber and by 1.5% for the game Shadow of Tomb Raider" [143]. A interface que entrou foi outra, uma syscall própria escrita por André Almeida, também de @collabora.com [144]: o futex_waitv() chegou no 5.16, em janeiro de 2022, com o caso de uso declarado, emular o WaitForMultipleObjects, "which allows software like Proton to improve the performance of Windows Games" [145]. Dois brasileiros, uma consultoria de código aberto e uma empresa de games: o caminho de um patch até o mainline.

Subsistema	Quem começou (empresa na época)	Entrada no mainline
cgroups	Rohit Seth e Paul Menage (Google)	2.6.24, jan/2008
namespaces	IBM, OpenVZ, Google, Arista e outros	do 2.4.19 (2002) ao 5.6 (2020)
KVM	Avi Kivity (Qumranet, depois Red Hat)	2.6.20, fev/2007
eBPF	Alexei Starovoitov (PLUMgrid)	3.15 e 3.18, 2014
XDP	Brenden Blanco (PLUMgrid)	4.8, out/2016
io_uring	Jens Axboe (ver texto)	5.1, mai/2019
Btrfs	Chris Mason (Oracle)	2.6.29, mar/2009
XFS	Silicon Graphics	2.5.36, set/2002
CFS	Ingo Molnar (Red Hat)	2.6.23, out/2007
EEVDF	Peter Zijlstra (Intel)	6.6, out/2023
sched_ext	Tejun Heo e David Vernet (Meta), com o Google	6.12, nov/2024
amdgpu	Alex Deucher (AMD)	4.2, ago/2015
xe	Intel, com Red Hat e Collabora	6.8, mar/2024
mlx5	Eli Cohen (Mellanox)	3.11, set/2013
arm64	Catalin Marinas e Will Deacon (Arm)	3.7, dez/2012
RISC-V	Palmer Dabbelt e Albert Ou (SiFive)	4.15, jan/2018
s390	IBM Alemanha	2.2.14, jan/2000
PREEMPT_RT	Ingo Molnar (Red Hat) e Thomas Gleixner (Linutronix)	6.12, nov/2024
Rust	Miguel Ojeda (contrato da ISRG pago pelo Google)	6.1, dez/2022
futex_waitv	André Almeida (Collabora), para a Valve	5.16, jan/2022

Quase nenhum desses subsistemas nasceu de alguém resolvendo um problema pessoal no fim de semana. Nasceram de um data center que precisava isolar cargas, de uma startup que queria vender virtualização, de outra que queria programar o caminho dos pacotes, de um fabricante que precisava que seu chip funcionasse. O mainline é onde essas necessidades se encontram e passam a ser mantidas em conjunto.

Quem decide

Um patch leva dois ou três meses para sair da caixa de e-mail de um mantenedor e chegar a um release. O caminho é público e documentado, e quase todas as mãos por onde ele passa estão na folha de pagamento de alguém.

A documentação descreve o ritmo. Um release novo sai "every two or three months" e traz "about 13,000 changesets". Primeiro vem uma merge window que "lasts for approximately two weeks", em que Linus puxa o que os mantenedores acumularam. Depois, um -rc "about once a week", até algo entre o -rc6 e o -rc9 [146]. O 7.2 levou nove semanas, de 14 de junho a 16 de agosto de 2026 [37]. Antes de chegar a Linus, o código passa pela árvore de um subsistema e pela linux-next, "maintained by Mark Brown", que é o retrato do que o mainline deve virar na próxima merge window [146].

 autor --e-mail--> lista do subsistema
                     (revisão pública: Reviewed-by, Acked-by, Tested-by)
                            |
                            v
                   árvore do mantenedor  (+ Signed-off-by de quem aplicou)
                            |
                            v
                       linux-next  (integração das árvores dos subsistemas)
                            |   merge window: cerca de duas semanas
                            v
                  mainline (Linus) --> -rc1 ... -rc7 --> release 7.x
                            |
                            v
          stable e LTS (Greg Kroah-Hartman, Sasha Levin):
          só correções que já estão no mainline, até 100 linhas

Depois do release, as correções descem para as árvores stable e de longo prazo. A regra é dura: o patch precisa "already exist in Linux mainline (upstream)" e "cannot be bigger than 100 lines, with context" [147]. Quanto tempo uma versão de longo prazo vive é, literalmente, decisão de mercado. Cada uma "usually starts with only a 2-year projected EOL that can be extended further if there is enough interest from the industry at large to help support it for a longer period of time" [148]. Em outubro de 2026, há seis séries LTS, do 5.10 ao 6.18, com fim projetado entre dezembro de 2026 e dezembro de 2028 [148]. Desde 13 de fevereiro de 2024, o kernel também emite os próprios CVEs [149], com o critério declarado de "assign CVE numbers to any bugfix that they identify" [150]. Saiu do zero para "number 1 in 2025" entre as autoridades de CVE por volume [151], e a Linux Foundation contou 13 CVEs por dia [152].

Quem é dono de cada pedaço está num arquivo de texto. O MAINTAINERS do 7.2 tem 3.255 entradas, cada uma com mantenedores (M:), revisores (R:), lista de e-mail (L:), árvore (T:) e status (S:) [70]. O status é o dado mais franco do kernel. Supported quer dizer "Someone is actually paid to look after this"; Maintained, "Someone actually looks after it". No 7.2, 795 entradas (24,4%) se declaram pagas, 2.205 (67,7%) se declaram mantidas e 139 (4,3%) estão órfãs [70]. O número é autodeclarado e subestima o pagamento. O CGROUP, mantido por Tejun Heo, Johannes Weiner e um engenheiro da SUSE, está como Maintained; o Btrfs, com Chris Mason, de @fb.com, e David Sterba, de @suse.com, também; o mlx5, com quatro mantenedores de @nvidia.com, idem [70].

Dos 1.998 endereços de mantenedor, 287 são gmail.com e 191 kernel.org, e nenhum dos dois diz nada sobre o empregador. Depois vêm Intel (86, somando linux.intel.com), AMD (56), Red Hat (46), IBM (45), Broadcom (41), NVIDIA (35) e NXP (35) [70]. O domínio engana nos dois sentidos. Mauro Carvalho Chehab aparece no MAINTAINERS como mchehab@kernel.org, mas 2.310 dos seus commits saíram de mchehab+huawei@kernel.org [37]. Peter Zijlstra usa um domínio pessoal e assina "Peter Zijlstra (Intel)" [103]. Para saber quem paga quem, é preciso juntar provas:

Área	Mantenedor	Vínculo, com a prova mais recente encontrada
Tudo o que sobra ("THE REST")	Linus Torvalds	Linux Foundation: "Fellow" no formulário 990 de 2024 [109]
stable e LTS	Greg Kroah-Hartman	Linux Foundation: "Fellow" na página do TAB [153]
escalonador	Peter Zijlstra	Intel: assina "Peter Zijlstra (Intel)" [103]
x86	Borislav Petkov	AMD: assina "Borislav Petkov (AMD)" [37]
x86 e escalonador	Ingo Molnar	e-mail `@redhat.com` no MAINTAINERS [70]
rede	Eric Dumazet	e-mail `@google.com` [70]
rede	Jakub Kicinski	Facebook, na programação da LPC 2025 [154]
rede	Paolo Abeni	e-mail `@redhat.com` [70]
BPF	Daniel Borkmann	"Isovalent at Cisco", na programação da OSS NA 2025 [155]
KVM	Paolo Bonzini	e-mail `@redhat.com` [70]
KVM para x86	Sean Christopherson	e-mail `@google.com` [70]
segurança do kernel	Kees Cook	Google, na página do TAB [153]
AMDGPU	Alex Deucher	e-mail `@amd.com` [70]
PREEMPT_RT	Sebastian Andrzej Siewior	e-mail `@linutronix.de`, empresa da Intel [70], [133]

A sucessão segue o mesmo padrão. Em abril de 2026, Andrew Morton, cujo endereço no MAINTAINERS é @linux-foundation.org [70], anunciou que vai começar a deixar a manutenção do gerenciamento de memória, função que exercia "since before memory management was even seen as its own subsystem". A árvore de integração do subsistema "will be picked up by David Hildenbrand" [156], que a página do TAB lista como funcionário da Arm [153].

Acima de tudo isso está a Linux Foundation, que paga o próprio Linus. No formulário 990 de 2024, ele aparece como "Fellow", com US$ 524.349 na coluna de remuneração e US$ 1.089.627 na coluna "Other". Dez executivos da fundação vêm antes dele na coluna principal, a começar pelo diretor executivo, Jim Zemlin, com US$ 952.166 e US$ 451.018 [109]. O relatório anual de 2025 previa receita de US$ 311,3 milhões, 42,8% dela em "Membership & Donations", e despesas de US$ 284,8 milhões. A linha "Linux Kernel Project" ficou em US$ 8,4 milhões, 2,95% do gasto. É menos que "Training", com US$ 21,6 milhões, e que "Event Services", com US$ 16,8 milhões. A maior fatia, US$ 181,9 milhões, foi para "Project Support", os outros projetos que a fundação hospeda [152]. Em 2024, o kernel tinha ficado com US$ 6,8 milhões, 2,27% [157]. Os números do relatório anual são previsões e não batem com os do formulário 990, que registrou US$ 220,7 milhões de receita em 2024 [109]. Por qualquer das duas contas, a Linux Foundation de hoje é uma fundação de muitos projetos que carrega o nome de um.

A ponte formal entre a comunidade e a fundação é o Technical Advisory Board. Ele "exists to provide advice from the kernel community to the Linux Foundation and holds a seat on the LF's board of directors" [158], e o estatuto da fundação reserva ao TAB uma das cadeiras de diretor at-large [159]. Na eleição de dezembro de 2025, havia 1.054 eleitores registrados, e 265 votaram [160]. Dos dez membros listados hoje, dois são do Google, dois da Intel, um da Arm e um do Inria; dois são Fellows da própria fundação, um declara a Qube-RT e Miguel Ojeda não declara empresa [153]. A LWN descreve o TAB como "a sort of governing board in a community that has no governing boards" [161].

O Brasil na folha de pagamento

Os brasileiros que já apareceram nos meus posts sobre o kernel também têm crachá. O domínio dos e-mails nos commits conta a carreira de cada um [37]:

Desenvolvedor	Onde aparece no MAINTAINERS do 7.2	Domínios nos commits (anos)
Marcelo Tosatti	(mantenedor do 2.4 em 2001; do KVM em 2011)	`conectiva.com.br` no LKML em 2001; `redhat.com` (2007–2024)
Arnaldo Carvalho de Melo	Performance Events	`mandriva.com` (2005–2006); `redhat.com` (2007–2026), 4.392 de 4.726 commits
Mauro Carvalho Chehab	Media (V4L/DVB) e drivers HiSilicon	`redhat.com` (2007–2013); `samsung.com` e `osg.samsung.com` (2013–2018); `mchehab+huawei@kernel.org` (2.310 commits)
Glauber Costa	(kvmclock; memória nos cgroups)	`redhat.com` (2008–2011); `parallels.com` (2011–2013)
Lucas De Marchi	(coautor do driver xe)	`profusion.mobi` (2011–2013); `intel.com` (2014–2025, 871 commits); `nvidia.com` (2026)
Gabriel Krisman Bertazi	Unicode	`linux.vnet.ibm.com` (2015–2016); Collabora (2016–2024); `suse.de` (2022–2026)
André Almeida	Futex (revisor)	`collabora.com` (2019–2022); `igalia.com` (2022–2026)
Luiz Augusto von Dentz	Bluetooth	`nokia.com` (2010–2011); `intel.com` (2011–2026, 503 commits)
Henrique de Moraes Holschuh	ThinkPad ACPI	`hmh.eng.br`, domínio próprio (2006–2021, 342 commits)

As fontes são o git log do kernel, para os domínios, e o MAINTAINERS do 7.2 e do 3.0, para as funções [37], [70], [67]. O e-mail de 2001 de Tosatti está no LKML [7]. A régua da LKML é aberta, e eles passaram nela. Mas passaram, em quase todos os casos, com alguém pagando as horas. A exceção da tabela, Henrique de Moraes Holschuh, manteve um driver por quinze anos com domínio próprio, e é exatamente o tipo de contribuição que os 4,5% de "(None)" medem.

O processo é aberto: qualquer pessoa pode mandar um patch, e as regras valem para todos. Mas quem aplica, quem integra, quem decide quanto tempo uma versão vive e quem paga o árbitro final é, quase sempre, alguém com crachá.

Por que concorrentes dividem o mesmo código

Num post sobre licenças, escrevi que a GPL é legalismo e a BSD é confiança: uma obriga a devolver, a outra espera que a colaboração apareça sozinha. Olhando o kernel de perto, a frase pede uma correção. O que faz uma empresa devolver código não é só a licença. É o custo de não devolver.

O Linux não promete estabilidade a quem fica fora da árvore. O documento de Greg Kroah-Hartman sobre o assunto começa dizendo que o Linux "does not have a binary kernel interface, nor does it have a stable kernel interface". Em troca, oferece um acordo: "If your driver is in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change in the first place". Das vantagens listadas, a primeira é econômica: "The quality of the driver will rise as the maintenance costs (to the original developer) will decrease" [162]. Quem fica fora paga o rebase a cada versão, e sai uma "every nine or ten weeks" [39]. Quem entra divide a conta com todo mundo, inclusive com os concorrentes.

O Google mediu essa conta por dentro. O Prodkernel, o kernel dos servidores da empresa, "consists of around 9000 patches on top of an older upstream Linux kernel", e o rebase desses patches para uma versão nova, feito a cada dois anos mais ou menos, é "extremely costly". O projeto Icebreaker nasceu "to provide a near-mainline kernel for development and testing within Google" [163]. O Facebook chegou lá antes. Em 2015, a empresa contou que o seu branch interno do 4.0 tinha 101 commits de 12 engenheiros, enquanto o mainline tinha recebido 238 commits de nove deles: "This is our upstream-first philosophy at work" [164]. Num congresso em 2016, um engenheiro da empresa foi direto: "Running old kernels with internal-only patches is painful" [165]. A AWS seguiu o modelo das distribuições: o Amazon Linux 2023 lança um kernel de longo prazo por ano, "based on the upstream Linux community's annual LTS kernel" [166].

O Android mostra o custo de fazer o contrário. Em 2010, Greg Kroah-Hartman contou que tinha posto os drivers do Android em staging e que o Google prometera ajudar a levá-los ao mainline, "but they didn't"; ele teve de removê-los [167]. O nó eram os wakelocks, o mecanismo de economia de energia que o Android espalhava pelos drivers. O código voltou ao staging no fim de 2011 [168], e o autosleep, uma versão do mecanismo aceitável para o mainline, entrou no 3.5, em 2012 [169], [170]. Mesmo assim, em 2017 os aparelhos ainda saíam com kernels que traziam "large amounts (often millions of lines) of out-of-tree code" [171].

O Google mudou de estratégia. Em 2018, o Android Common Kernel precisava de "only about 30 patches", com cerca de 6.500 linhas, para dar boot [172]; em 2020, ainda carregava 485 patches sobre o 5.9-rc [173]. A documentação do Android explica o porquê: antes do Generic Kernel Image, a customização de fabricantes de chip e de aparelhos "could result in as much as 50% of kernel code being out-of-tree code". Desde o Android 12, aparelhos com kernel 5.10 ou mais novo "must ship with the GKI kernel" [174], e a orientação para quem desenvolve é: "Upstream development is strongly encouraged" [175].

A Microsoft é o caso mais simbólico. Em 20 de julho de 2009, a empresa liberou "20,000 lines of device driver code to the Linux community under the popular General Public Licence v2", os drivers do Hyper-V [176]. Greg Kroah-Hartman anunciou no LKML que eles iriam para drivers/staging/ com "a whole bunch of cleanups" [177]. A limpeza foi tanta que, no 3.0, em 2011, a Microsoft respondia por 4,0% das mudanças, e a LWN comentou: "one assumes that presence will not be permanent: even the HV drivers can only need so much cleaning up" [33]. A presença ficou. Em novembro de 2016, a Microsoft virou membro Platinum da Linux Foundation [178]. Hoje mantém em público o kernel do WSL2 [179] e, no 6.19, respondia por 3,3% das assinaturas de mantenedor [40].

E a BSD? O FreeBSD prova o ponto pelo avesso. A Sony lista o "FreeBSD Kernel" entre os componentes do PlayStation 4 [180], e o XNU da Apple é "a hybrid kernel combining the Mach kernel developed at Carnegie Mellon University with components from FreeBSD", publicado pela empresa numa organização do GitHub chamada apple-oss-distributions [181]. A licença permite fechar, e muita empresa fecha. Mas a Netflix, que roda FreeBSD na sua rede de distribuição de vídeo, acompanha o branch de desenvolvimento: "a commit to the upstream FreeBSD development branch will usually be fully deployed across Netflix's CDN within 4-12 weeks" [182]. Faz isso pelo mesmo motivo de Google e Facebook no Linux: manter um fork longe do upstream é caro. A GPL obriga a publicar o código que se distribui, mas não obriga ninguém a mandar patch para o mainline. O que leva o patch até lá é a conta.

O contraexemplo vem do Solaris. Um funcionário da própria Oracle resumiu, em 2010, o que aconteceu depois da compra da Sun: a Oracle "stopped publishing binaries for recent OpenSolaris releases and stopped talking to the community at the same time". Em 3 de agosto de 2010, a Nexenta anunciou o Illumos para continuar o sistema por fora [183]. Projeto com um dono só morre quando o dono decide, e a conclusão deste artigo volta a esse ponto.

A literatura econômica tem nome para tudo isso. Lerner e Tirole, em 2002, explicaram boa parte da participação individual pela economia do trabalho, em especial pela "literature on career concerns" [184]: contribuir é currículo. O relatório da Linux Foundation de 2017 mostra o efeito no kernel, onde quem põe código no mainline arranja emprego [31]. West e Gallagher descreveram as estratégias das empresas em open source, entre elas "pooled R&D/product development" e "selling complements" [185]. É o caso do kernel: Intel, AMD e NVIDIA dividem o custo do sistema operacional e competem no hardware que roda nele. Joachim Henkel estudou empresas de Linux embarcado e mostrou que a revelação é seletiva: elas publicam parte do que desenvolvem e protegem o resto [186]. Em 2024, um estudo da Harvard Business School estimou em US$ 4,15 bilhões o custo de reescrever o software de código aberto mais usado e em US$ 8,8 trilhões o valor que ele gera para quem o usa, e mostrou que "96% of the demand-side value is created by only 5% of OSS developers" [187]. Os autores agradecem o "financial and administrative support from the Linux Foundation" [187].

Nadia Eghbal, num relatório de 2016 para a Ford Foundation, tratou o kernel como exceção. Escreveu que "The Linux Foundation is one of the most successful outliers, due to the fundamental value of the Linux kernel to nearly every corporate entity", e trouxe um dado brasileiro: um estudo da UFMG com 133 projetos populares do GitHub mostrou que 64% "relied upon just one or two developers to survive" [188]. O kernel escapou desse destino porque virou infraestrutura de quem paga.

Concorrentes dividem o mesmo código porque não dividir custa mais do que o que se ganha escondendo. A licença ajuda. Quem decide é a conta.

Os robôs que testam o kernel

Já repeti por aí que, na prática, quase ninguém lê os milhares de patches que entram no kernel. A resposta da indústria não foi contratar mais leitores. Foi pôr máquinas para ler e executar o código o tempo todo, e quase todas elas têm dono.

O syzkaller, do Google, é "an unsupervised coverage-guided kernel fuzzer", e o repositório existe desde outubro de 2015 [189]. O syzbot é o robô que o roda sem parar: "syzbot system continuously fuzzes main Linux kernel branches and automatically reports found bugs to kernel mailing lists" [190]. Em 2019, Dmitry Vyukov, que commita de @google.com [37], contou cerca de 2.300 bugs encontrados no upstream em dois anos, três por dia, e outros 2.500 em Android, ChromeOS, árvores stable e kernels internos [191]. Em 2 de outubro de 2026, o painel do syzbot mostrava 7.518 bugs corrigidos no upstream e 1.591 ainda abertos [192].

A Intel roda o 0-day, que assina os relatos como "kernel test robot". Em 2012, ele já testava a árvore de Linus, a linux-next e "more than 180 trees owned by individual kernel maintainers and developers" [193]; o código está no repositório lkp-tests [194]. No 5.5, a LWN contou de onde vinham os créditos de Reported-by: o Hulk Robot ficou com 15,7%, o syzbot com 12,0% e o robô da Intel com 9,8%, e a conclusão foi que "over 1/3 of the bug reports for the kernel (of which 934 were credited in 5.5) are now coming from automated testing systems" [195]. No git log do 5.5, os 164 créditos do Hulk Robot saem de hulkci@huawei.com, e os do robô da Intel, de lkp@intel.com [37].

O KernelCI começou do outro jeito. Ele foi "originally started in 2014 as a side project by a few engineers who were doing the testing at home and in their spare time". Em outubro de 2019, virou projeto da Linux Foundation "underwritten by BayLibre, Civil Infrastructure Platform, Collabora, Foundries.io, Google, Microsoft, Red Hat" [196]. Hoje a lista de membros inclui Arm, Google, Linaro, Microsoft, Qualcomm, Red Hat e Texas Instruments [197]. O projeto de fim de semana virou infraestrutura com patrocinadores.

As ferramentas de diagnóstico dentro do kernel têm a mesma origem. O KASAN, que detecta acesso inválido à memória, entrou no 4.0 por Andrey Ryabinin, de @samsung.com, e o próprio commit cita a família de ferramentas que o Google criou para espaço de usuário: "We've developed the set of tools, AddressSanitizer (Asan), ThreadSanitizer and MemorySanitizer" [198]. O KCSAN, para condições de corrida, é de Marco Elver, de @google.com, e entrou no 5.8 [199], [200]. O KMSAN, para memória não inicializada, é de Alexander Potapenko, também do Google, e entrou no 6.1; no pull request, Andrew Morton escreveu: "KMSAN keeps finding bugs. New ones, as well as the legacy ones" [201], [202]. O KUnit, de testes unitários, veio de Brendan Higgins, de @google.com, no 5.5 [203]. O kselftest, a suíte de testes que roda num kernel instalado, foi organizado a partir de 2014 por Shuah Khan, que commitava de @samsung.com [37], [204].

Ferramenta	Quem paga ou começou	Entrada	O que faz
syzkaller e syzbot	Google	repositório desde out/2015	fuzzing contínuo; 7.518 bugs corrigidos e 1.591 abertos em 2/10/2026
kernel test robot (0-day)	Intel	mais de 180 árvores testadas em 2012	compila, dá boot e testa cada árvore; 9,8% dos relatos de bug no 5.5
Hulk Robot	Huawei (`hulkci@huawei.com`)	ativo no 5.5	15,7% dos relatos de bug no 5.5
KernelCI	Linux Foundation, com Google, Microsoft, Red Hat e outros	2014; na LF desde 2019	testes em hardware real de vários laboratórios
KASAN	Andrey Ryabinin (Samsung), a partir das ferramentas do Google	4.0, abr/2015	acesso inválido à memória
KCSAN	Marco Elver (Google)	5.8, ago/2020	condições de corrida
KMSAN	Alexander Potapenko (Google)	6.1, dez/2022	uso de memória não inicializada
KUnit	Brendan Higgins (Google)	5.5, jan/2020	testes unitários dentro do kernel
kselftest	Shuah Khan (Samsung, na época)	2014	testes de um kernel instalado

Até a caça a exploits é paga. O kCTF, programa de recompensas do Google para falhas no kernel, "has rewarded researchers with a total of 1.8 million USD" desde que começou [84].

Auditar o kernel é possível, e quem audita em escala está na folha de pagamento de alguém: Google, Intel, Huawei, Samsung. A fila de 1.591 bugs abertos no syzbot lembra a outra metade da frase que eu costumo repetir: ter review, teste e mantenedor não significa que a falha não existe.

O que não fecha

Um modelo bancado por empresas resolve muita coisa e cria outros problemas. Alguns aparecem nos números; outros, nas listas de e-mail.

Mantenedores no limite

Na Maintainers Summit de 2023, Ted Ts'o abriu uma sessão sobre burnout dizendo, segundo a LWN, que os mantenedores acabam fazendo "all of the tasks that nobody else working on a given subsystem wants to take on" [205]. Um ano antes, numa sessão conduzida por Josef Bacik, a frase sobre os sistemas de arquivos tinha sido: "we simply do not have enough people on some of the filesystem teams" [206]. A pesquisa acadêmica confirma o desenho. Um estudo de 2017 concluiu que "the distribution of work among maintainers is highly unbalanced" e que pôr mais de um mantenedor num arquivo rende "only a power of 1/2 increase in productivity" [207]. As empresas contratam gente para escrever código. A revisão do código dos outros cai sobre poucas pessoas, e os 41,4% de commits do 7.2 sem nenhuma etiqueta de revisão são o retrato disso [37].

O preço apareceu fora do kernel. Em junho de 2022, o mantenedor do xz, Lasse Collin, respondeu a cobranças por mais atividade: "I haven't lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues but also due to some other things. Recently I've worked off-list a bit with Jia Tan on XZ Utils" [208]. Em março de 2024, Andres Freund descobriu que "the upstream xz repository and the xz tarballs have been backdoored" e escreveu que quem fez os commits suspeitos "is either directly involved or there was some quite severe compromise of their system" [209]. Um dos commits que ele apontou é assinado por Jia Tan [210]. O kernel não é o xz, mas a lição vale para ele: mantenedor cansado é superfície de ataque.

A GPL e o driver que não quer abrir

O kernel tenta separar o que é público do que é interno pela licença. Os símbolos exportados com EXPORT_SYMBOL_GPL() "can only be seen by modules with a MODULE_LICENSE() that specifies a GPLv2 compatible license" [211]. Fabricantes de driver fechado contornavam isso com módulos-ponte de licença aberta. Em 2020, o 5.9 fechou essa porta: um módulo que importa símbolos de um módulo proprietário passa a ser tratado como proprietário [212]. O commit traz um comentário de Greg Kroah-Hartman: "Ah, the proven-to-be-illegal "GPL Condom" defense :)". Em 2023, a LWN resumiu a regra: um módulo assim "immediately loses its ability to access GPL-only symbols" [213].

A NVIDIA era o alvo de sempre. Em 2012, numa palestra na Universidade Aalto, Linus chamou a empresa de "the single worst company we have ever dealt with", segundo a Phoronix [214]. Em maio de 2022, a NVIDIA abriu os módulos de kernel dos seus drivers, mas fora da árvore principal [114]. O driver que deve entrar no mainline, o nova-core, foi iniciado por um desenvolvedor que commitava da Red Hat e hoje tem um engenheiro da NVIDIA entre os mantenedores [115], [70]. A empresa entrou no kernel quando o custo de ficar fora ficou maior que o de entrar.

Hardware com embargo

Falhas de hardware criam um conflito que o kernel não tinha como evitar: quem descobre e quem conserta são empresas que concorrem entre si. Em janeiro de 2018, no meio da correção do Spectre, Linus avaliou assim uma série de patches que implementava a interface IBRS definida pela Intel: "As it is, the patches are COMPLETE AND UTTER GARBAGE". Na mesma conversa, tinha pedido: "Please, any Intel engineers here - talk to your managers" [215]. O processo que saiu dali está documentado. Falhas como "Meltdown, Spectre, L1TF etc. must be treated differently because they usually affect all Operating Systems", e a equipe do kernel, por "not a formal body", é "unable to enter into any non-disclosure agreements", oferecendo em troca um memorando de entendimento [216]. O kernel trata com fabricantes de chip como uma comunidade, não como um fornecedor que assina contrato.

Poucas empresas, muito poder

A concentração já apareceu nos números. Desde 2017, mais da metade dos patches passa pelas mãos de mantenedores de cinco empresas [31], [39]. A lista dessas empresas muda: a Red Hat tinha 42,4% das assinaturas de mantenedor em 2009 e 4,9% no 6.19, e a Meta, que não aparecia em 2009, lidera hoje [32], [40]. O kernel sobreviveu a essa troca de guarda sem crise visível. O risco não é uma empresa sair. É o interesse comum das que ficam decidir, sozinho, o que vale a pena manter.

Sanções

Em 18 de outubro de 2024, um commit de Greg Kroah-Hartman tirou do MAINTAINERS várias entradas "due to various compliance requirements", com a promessa de que poderiam voltar "if sufficient documentation is provided" [217]. O patch foi enviado só para uma lista de patches e entrou no 6.12-rc4 dentro de um pull request de drivers, sem destaque; a LWN observou que os desenvolvedores removidos "all appear to be of Russian origin" [218]. Paul Moore pediu o mínimo: "can we at least explicitly list those requirements in the commit description?" [219]. A explicação veio de James Bottomley: "If your company is on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company on the list, our ability to collaborate with you will be subject to restrictions, and you cannot be in the MAINTAINERS file" [220]. Linus apoiou a mudança em público e disse que ela não seria revertida [218]. Um projeto mantido por empresas, sob a guarda de uma fundação americana, segue a lei americana. Isso não é uma falha de caráter da comunidade. É uma consequência do modelo.

Rust e o poder do mantenedor

A disputa mais longa dos últimos anos foi sobre Rust, e foi menos sobre a linguagem do que sobre quem manda em quê. Em agosto de 2024, Wedson Almeida Filho, que commitava de @microsoft.com [37], deixou o projeto: "I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense" [221]. Em janeiro de 2025, Christoph Hellwig vetou uma abstração de DMA em Rust com um Nacked-by, escreveu que não queria outro mantenedor no subsistema e mandou quem quisesse uma base de código em duas linguagens fazer isso no próprio driver, "instead of spreading this cancer to core subsystems". Na mesma mensagem, esclareceu que o câncer era "a cross-language codebase" [222]. Dias depois, completou: "I will do everything I can do to stop this. This is NOT because I hate Rust" [223].

Hector Martin, do Asahi Linux, escreveu na lista: "If shaming on social media does not work, then tell me what does, because I'm out of ideas." Linus respondeu: "How about you accept the fact that maybe the problem is you" [224]. Martin saiu do MAINTAINERS dizendo que não tinha mais "any faith left in the kernel development process or community management approach" [225]. Duas semanas depois, Linus escreveu a Hellwig que o pull request contestado "DID NOT TOUCH THE DMA LAYER AT ALL" e fixou a regra: "if you as a maintainer feel that you control who or what can use your code, YOU ARE WRONG" [226]. A política oficial do projeto admite o meio-termo: "Some subsystems may decide they do not want to have Rust code for the time being, typically for bandwidth reasons. This is fine and expected" [227]. Um experimento financiado por empresas esbarrou no limite de tempo de quem mantém o núcleo. Quem resolveu foi o árbitro pago pela fundação.

O sistema de arquivos sem patrão

O bcachefs, o projeto que Kent Overstreet tocava "on his own, supported by interested users on Patreon" e que inflou o "(None)" do 6.7 [36], foi marcado como "externally maintained" no 6.17-rc4, num commit de Linus com uma linha de justificativa: "As per many long discussion threads, public and private" [228]. No 6.18, o código saiu, porque o sistema já era "a DKMS module" [229]. O commit não fala em dinheiro; fala em discussões longas. Mas o resultado ilustra a tese pelo avesso: o caso mais visível de grande subsistema sem empresa por trás terminou fora da árvore.

A IA chegou à fila

No 7.2, 1.111 mudanças, "under 7% of the total", declararam ajuda de ferramentas de IA com a etiqueta Assisted-by, contra 301 no ciclo anterior [2]. O painel do syzbot já tem um filtro para correções propostas por IA aguardando revisão [192]. Na minha experiência, a IA não diminuiu o trabalho; aumentou. Mais patches, de mais gente desconhecida, para os mesmos mantenedores revisarem.

O kernel tem backdoor?

Já escrevi que o kernel tem backdoor e que código da NSA ficou anos nele. Fui atrás do que está documentado. Em 2003, uma tentativa de backdoor em wait4() foi barrada antes de chegar à árvore principal, como a seção histórica mostrou [22]. Em 2021, pesquisadores da Universidade de Minnesota mandaram patches propositalmente defeituosos para estudar o review; o TAB reexaminou 435 commits da universidade, e "These 39 commits are going to be reverted" [230]. E a NSA? O SELinux foi escrito pela NSA e entrou no kernel como código público, revisado na lista. As "referências à NSA" que sumiram saíram no commit "selinux: de-brand SELinux", de Stephen Smalley, um dos mantenedores do SELinux [70], que trocou "NSA SELinux" por "SELinux" no texto de ajuda e nos comentários [231]. O pull request do 6.6 explica: "We've come a long way from the original NSA submission and I would consider SELinux a true community project at this point so removing the NSA branding just makes sense" [232]. Foi uma troca de marca, não a retirada de código malicioso. A frase que eu repetia estava errada. O risco real é mais chato: quatro em cada dez commits entram sem etiqueta de revisão, e o mantenedor que os aplica está cansado.

Nenhuma dessas tensões indica que o modelo vai quebrar. São o preço de um modelo em que quem paga decide onde gastar, e em que o que ninguém quer pagar, como review, manutenção de código antigo e paciência com o processo, sobra para poucas pessoas.

Conclusão: um bem comum com donos demais

Em 1991, o kernel era de uma pessoa. Em 2026, ele é de ninguém e de todo mundo que paga.

Os números deste artigo apontam para o mesmo lugar. De cada cinco commits do 7.2, quatro vêm de quem tem vínculo identificado, e só 4,5% de quem declaradamente trabalha por conta própria [2]. Quem aceita o código é ainda mais corporativo: 1,6% das assinaturas de mantenedor do 6.19 vêm de gente sem empregador [40]. Os subsistemas que definem o Linux moderno, de cgroups a io_uring, de KVM a sched_ext, nasceram de necessidades de empresas e chegaram ao mainline escritos por funcionários delas. Os robôs que testam o kernel também têm dono. Até o tempo de vida de uma versão de longo prazo depende de "enough interest from the industry at large" [148].

Isso não faz do Linux um produto de uma empresa, e é aí que o contraste com os outros Unix ajuda. O OpenSolaris tinha um dono, e a comunidade precisou criar o Illumos quando o dono parou de publicar [183]. O XNU é de uma empresa e aparece no GitHub como distribuição de releases [181]. O kernel Linux recebeu commits de 249 empregadores identificados num único ciclo, e nenhuma empresa sozinha passou de 10% dos commits do 7.2 nem de 12% das assinaturas de mantenedor do 6.19 [2], [40]. O árbitro final é pago por uma fundação que as empresas sustentam, e no conselho dessa fundação cada membro Platinum indica um único diretor [159]. A robustez do Linux não vem da ausência de empresas. Vem de haver empresas demais para que uma só mande.

O modelo funciona sob três condições, e o kernel mostra as três. Ficar fora precisa custar caro: sem ABI interna estável, quem não manda o código para o mainline paga o rebase para sempre [162]. Nenhum participante pode ser grande o bastante para fechar o projeto. E o processo precisa ser público, com regras que valem para o estagiário e para o vice-presidente: a mesma lista, o mesmo Signed-off-by, a mesma merge window.

O modelo também tem pontos cegos, e eles estão onde ninguém tem incentivo para pagar. Revisão, manutenção de código antigo e paciência com o processo sobram para poucas pessoas. A Linux Foundation destinou ao kernel 2,95% das despesas previstas para 2025 [152]. Dois em cada cinco commits entram sem etiqueta de revisão [37]. E quando a geopolítica chega, o projeto obedece à lei do país onde estão a fundação e as maiores empresas [218].

Quem usa Linux todo dia, como eu, não precisa romantizar nada disso. O Linux não é seguro por ser aberto, nem livre de interesse comercial. É uma infraestrutura crítica que dezenas de concorrentes mantêm juntos porque sai mais barato do que manter sozinhos, e que continua aberta porque nenhum deles conseguiria fechá-la.

Software livre não é software sem dono. É software com donos demais para um só mandar.

Referências

[1]L. Torvalds, “What would you like to see most in minix?,” mensagem em comp.os.minix, 25 ago. 1991. Cópia arquivada pela Carnegie Mellon University. [Online]. Disponível em: https://www.cs.cmu.edu/~awb/linux.history.html ↩
[2]J. Corbet, “Development statistics for the 7.2 kernel,” LWN.net, 17 ago. 2026. [Online]. Disponível em: https://lwn.net/Articles/1088776/ ↩
[3]The FreeBSD Documentation Project, “Introduction: About the FreeBSD Project,” em FreeBSD Handbook. [Online]. Disponível em: https://docs.freebsd.org/en/books/handbook/introduction/ ↩
[4]M. Linksvayer, “The Choice of a GNU Generation: An Interview With Linus Torvalds,” Meta, nov. 1993. [Online]. Disponível em: https://gondwanaland.com/meta/history/interview.html ↩
[5]Red Hat, Inc., “Prospectus: 6,000,000 Shares, Common Stock (Form 424B1),” U.S. Securities and Exchange Commission, 11 ago. 1999. [Online]. Disponível em: https://www.sec.gov/Archives/edgar/data/0001087423/000104746999031070/0001047469-99-031070.txt ↩
[6]A. Leonard, “Red Hot,” Salon, 12 ago. 1999. [Online]. Disponível em: https://www.salon.com/1999/08/12/redhat_ipo/ ↩
[7]M. Tosatti, “Re: Linux 2.4.16-pre1,” mensagem na linux-kernel mailing list, 24 nov. 2001. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/0111.3/0103.html ↩
[8]LWN.net, “Linux in the News,” LWN.net Weekly Edition, 14 dez. 2000. [Online]. Disponível em: https://lwn.net/2000/1214/press.php3 ↩
[9]LWN.net, “Commerce,” LWN.net Weekly Edition, 14 dez. 2000. [Online]. Disponível em: https://lwn.net/2000/1214/commerce.php3 ↩
[10]J. Barr, “Inside IBM's Linux Technology Center,” Computerworld, 20 mar. 2001. [Online]. Disponível em: https://www.computerworld.com/article/1447992/inside-ibm-s-linux-technology-center.html ↩
[11]“Industry Leader Forming Development Lab For Linux,” comunicado de imprensa reproduzido por Scoop, 31 ago. 2000. [Online]. Disponível em: https://www.scoop.co.nz/stories/BU0008/S00241.htm ↩
[12]OSDL e Transmeta, “Linux Creator Linus Torvalds joins OSDL,” comunicado reproduzido no LWN.net, 17 jun. 2003. [Online]. Disponível em: https://lwn.net/Articles/36635/ ↩
[13]A. Updegrove, “Joining Forces: OSDL and the Free Standards Group will become The Linux Foundation,” ConsortiumInfo.org, 21 jan. 2007. [Online]. Disponível em: https://www.consortiuminfo.org/open-source-open-standards/joining-forces-osdl-and-the-free-standards-group-will-become-the-linux-foundation ↩
[14]Novell, Inc., “Novell Announces Agreement to Acquire Leading Enterprise Linux Technology Company SUSE LINUX,” Exhibit 99, Form 8-K, U.S. Securities and Exchange Commission, 4 nov. 2003. [Online]. Disponível em: https://www.sec.gov/Archives/edgar/data/0000758004/000075800403000018/nov4_99.htm ↩
[15]Caldera International, Inc. (The SCO Group), “Form 8-K,” U.S. Securities and Exchange Commission, 7 mar. 2003. [Online]. Disponível em: https://www.sec.gov/Archives/edgar/data/1102542/000104746903008083/a2105216z8-k.txt ↩
[16]The SCO Group, Inc., “Form 8-K,” U.S. Securities and Exchange Commission, 10 ago. 2007. [Online]. Disponível em: https://www.sec.gov/Archives/edgar/data/1102542/000095013407018100/v33019e8vk.htm ↩
[17]S. Sharwood, “SCO v. IBM settlement deal is done, but zombie case shuffles on elsewhere,” The Register, 30 ago. 2021. [Online]. Disponível em: https://www.theregister.com/2021/08/30/sco_tsg_vs_ibm_settlement/ ↩
[18]L. Torvalds, “[RFD] Explicitly documenting patch submission,” mensagem na linux-kernel mailing list, 23 maio 2004. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/0405.2/1301.html ↩
[19]The Linux Foundation, “Developer Certificate of Origin, Version 1.1,” 2004–2006. [Online]. Disponível em: https://developercertificate.org/ ↩
[20]The kernel development community, “Submitting patches: the essential guide to getting your code into the kernel,” The Linux Kernel documentation. [Online]. Disponível em: https://docs.kernel.org/process/submitting-patches.html ↩
[21]J. Corbet, “The kernel and BitKeeper part ways,” LWN.net, 6 abr. 2005. [Online]. Disponível em: https://lwn.net/Articles/130746/ ↩
[22]J. Corbet, “An attempt to backdoor the kernel,” LWN.net, 6 nov. 2003. [Online]. Disponível em: https://lwn.net/Articles/57135/ ↩
[23]L. Torvalds, “Kernel SCM saga..,” mensagem na linux-kernel mailing list, 6 abr. 2005. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/0504.0/1540.html ↩
[24]L. Torvalds, “Initial revision of "git", the information manager from hell,” commit e83c5163316f, repositório git/git, 7 abr. 2005. [Online]. Disponível em: https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 ↩
[25]L. Torvalds, “Linux-2.6.12-rc2,” commit 1da177e4c3f4, repositório torvalds/linux, 16 abr. 2005. [Online]. Disponível em: https://github.com/torvalds/linux/commit/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ↩
[26]J. Corbet, “Kernel Summit: Development process,” LWN.net, 21 jul. 2004. [Online]. Disponível em: https://lwn.net/Articles/94386/ ↩
[27]J. Corbet, “Who wrote 2.6.20?,” LWN.net, 21 fev. 2007. [Online]. Disponível em: https://lwn.net/Articles/222773/ ↩
[28]The Linux Foundation, “Linux Foundation Publishes Study on Linux Development Statistics: Who Writes Linux and Who Supports It,” comunicado de imprensa, 1 abr. 2008. [Online]. Disponível em: https://www.linuxfoundation.org/press/press-release/linux-foundation-publishes-study-on-linux-development-statistics-who-writes-linux-and-who-supports-it ↩
[29]The Linux Foundation, “The Linux Foundation Releases Annual Linux Development Report,” comunicado de imprensa, 3 abr. 2012. [Online]. Disponível em: https://www.linuxfoundation.org/press/press-release/the-linux-foundation-releases-annual-linux-development-report ↩
[30]The Linux Foundation, “The Linux Foundation Releases Linux Development Report,” comunicado de imprensa, 18 fev. 2015. [Online]. Disponível em: https://www.linuxfoundation.org/press/press-release/the-linux-foundation-releases-linux-development-report ↩
[31]J. Corbet e G. Kroah-Hartman, 2017 Linux Kernel Development Report. The Linux Foundation, 2017. [Online]. Disponível em: https://www.linuxfoundation.org/hubfs/Reports/LinuxKernelReport_2017.pdf ↩
[32]J. Corbet, “Developer statistics for 2.6.30,” LWN.net, 27 maio 2009. [Online]. Disponível em: https://lwn.net/Articles/334721/ ↩
[33]J. Corbet, “Who wrote 3.0 - from two points of view,” LWN.net, 13 jul. 2011. [Online]. Disponível em: https://lwn.net/Articles/451243/ ↩
[34]J. Corbet, “Statistics from the 4.0 development cycle,” LWN.net, 1 abr. 2015. [Online]. Disponível em: https://lwn.net/Articles/637909/ ↩
[35]J. Corbet, “Some 6.0 development statistics,” LWN.net, 3 out. 2022. [Online]. Disponível em: https://lwn.net/Articles/909625/ ↩
[36]J. Corbet, “Some 6.7 development statistics,” LWN.net, 8 jan. 2024. [Online]. Disponível em: https://lwn.net/Articles/956765/ ↩
[37]L. Torvalds et al., “Linux kernel source tree (torvalds/linux),” repositório Git, clone consultado em 2 out. 2026. [Online]. Disponível em: https://github.com/torvalds/linux ↩
[38]J. Corbet, “Some 6.18 development statistics,” LWN.net, 1 dez. 2025. [Online]. Disponível em: https://lwn.net/Articles/1046966/ ↩
[39]J. Corbet, “Some 6.6 development statistics,” LWN.net, 30 out. 2023. [Online]. Disponível em: https://lwn.net/Articles/948970/ ↩
[40]J. Corbet, “Development statistics for 6.19,” LWN.net, 9 fev. 2026. [Online]. Disponível em: https://lwn.net/Articles/1057302/ ↩
[41]U. Lerch, “Kommerzielle Entwicklung von Open-Source-Software: Idealismus, Pragmatismus oder Strategie? Eine Fallstudie über Entwickler des Linux-Kernels in großen Firmen der Informationstechnologie,” tese de doutorado, Technische Universität Berlin, 2010. [Online]. Disponível em: https://depositonce.tu-berlin.de/items/0f44ee1e-66a6-4161-b9bf-ed7a937be1d5/full ↩
[42]D. Riehle, P. Riemer, C. Kolassa e M. Schmidt, “Paid vs. Volunteer Work in Open Source,” em Proc. 47th Hawaii International Conference on System Sciences (HICSS), 2014, pp. 3286–3295, doi: 10.1109/HICSS.2014.407. [Online]. Disponível em: https://dirkriehle.com/2013/08/22/paid-vs-volunteer-work-in-open-source/ ↩
[43]R. Seth, “[patch 0/5]-Containers: Introduction,” mensagem na linux-kernel mailing list, 14 set. 2006. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/0609.1/2068.html ↩
[44]J. Corbet, “Process containers,” LWN.net, 29 maio 2007. [Online]. Disponível em: https://lwn.net/Articles/236038/ ↩
[45]A. Verma, L. Pedrosa, M. Korupolu, D. Oppenheimer, E. Tune e J. Wilkes, “Large-scale cluster management at Google with Borg,” em Proc. EuroSys 2015, 2015. [Online]. Disponível em: https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/ ↩
[46]P. B. Menage, “Adding Generic Process Containers to the Linux Kernel,” em Proc. Ottawa Linux Symposium, vol. 2, 2007, pp. 45–58. [Online]. Disponível em: https://www.kernel.org/doc/ols/2007/ols2007v2-pages-45-58.pdf ↩
[47]P. Menage, “Task Control Groups: basic task cgroup framework,” commit ddbcc7e8e50a, 18 out. 2007. [Online]. Disponível em: https://github.com/torvalds/linux/commit/ddbcc7e8e50aefe467c01cac3dec71f118cd8ac2 ↩
[48]T. Heo, “Control Group v2,” The Linux Kernel documentation. [Online]. Disponível em: https://docs.kernel.org/admin-guide/cgroup-v2.html ↩
[49]J. Corbet, “The unified control group hierarchy in 3.16,” LWN.net, 11 jun. 2014. [Online]. Disponível em: https://lwn.net/Articles/601840/ ↩
[50]Kernelnewbies, “Linux 4.5,” 13 mar. 2016. [Online]. Disponível em: https://kernelnewbies.org/Linux_4.5 ↩
[51]D. Xu, “Open-sourcing oomd, a new approach to handling OOMs,” Engineering at Meta, 19 jul. 2018. [Online]. Disponível em: https://engineering.fb.com/2018/07/19/production-engineering/oomd/ ↩
[52]J. Corbet, “Tracking pressure-stall information,” LWN.net, 13 jul. 2018. [Online]. Disponível em: https://lwn.net/Articles/759781/ ↩
[53]J. Weiner, “psi: pressure stall information for CPU, memory, and IO,” commit eb414681d5a0, 26 out. 2018. [Online]. Disponível em: https://github.com/torvalds/linux/commit/eb414681d5a07d28d2ff90dc05f69ec6b232ebd2 ↩
[54]R. Pike, D. Presotto, K. Thompson, H. Trickey e P. Winterbottom, “The Use of Name Spaces in Plan 9,” Bell Laboratories. [Online]. Disponível em: https://9p.io/sys/doc/names.html ↩
[55]E. W. Biederman, “Multiple Instances of the Global Linux Namespaces,” em Proc. Ottawa Linux Symposium, vol. 1, 2006, pp. 101–112. [Online]. Disponível em: https://www.kernel.org/doc/ols/2006/ols2006v1-pages-101-112.pdf ↩
[56]M. Kerrisk, “Namespaces in operation, part 1: namespaces overview,” LWN.net, 4 jan. 2013. [Online]. Disponível em: https://lwn.net/Articles/531114/ ↩
[57]A. Kali, “cgroup: introduce cgroup namespaces,” commit a79a908fd2b0, 29 jan. 2016. [Online]. Disponível em: https://github.com/torvalds/linux/commit/a79a908fd2b080977b45bf103184b81c9d11ad07 ↩
[58]A. Vagin e D. Safonov, “ns: Introduce Time Namespace,” commit 769071ac9f20, 12 nov. 2019. [Online]. Disponível em: https://github.com/torvalds/linux/commit/769071ac9f20b6a447410c7eaa55d1a5233ef40c ↩
[59]S. E. Hallyn, “uts namespaces: Introduction,” patch reproduzido no LWN.net, abr. 2006. [Online]. Disponível em: https://lwn.net/Articles/179345/ ↩
[60]P. Emelyanov e K. Kolyshkin, “PID namespaces in the 2.6.24 kernel,” LWN.net, 19 nov. 2007. [Online]. Disponível em: https://lwn.net/Articles/259217/ ↩
[61]A. Kivity, “[PATCH 0/7] KVM: Kernel-based Virtual Machine,” mensagem na linux-kernel mailing list, 19 out. 2006. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/0610.2/1369.html ↩
[62]A. Kivity, Y. Kamay, D. Laor, U. Lublin e A. Liguori, “kvm: the Linux Virtual Machine Monitor,” em Proc. Ottawa Linux Symposium, vol. 1, 2007, pp. 225–230. [Online]. Disponível em: https://www.kernel.org/doc/ols/2007/ols2007v1-pages-225-230.pdf ↩
[63]“The Definitive KVM (Kernel-based Virtual Machine) API Documentation,” The Linux Kernel documentation. [Online]. Disponível em: https://docs.kernel.org/virt/kvm/api.html ↩
[64]A. Kivity, “[PATCH] kvm: userspace interface,” commit 6aa8b732ca01, 10 dez. 2006. [Online]. Disponível em: https://github.com/torvalds/linux/commit/6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 ↩
[65]Kernelnewbies, “Linux 3.0,” 21 jul. 2011. [Online]. Disponível em: https://kernelnewbies.org/Linux_3.0 ↩
[66]Red Hat, “Red Hat Advances Virtualization Leadership with Qumranet, Inc. Acquisition,” comunicado de imprensa, 4 set. 2008. [Online]. Disponível em: https://www.redhat.com/en/about/press-releases/qumranet ↩
[67]“MAINTAINERS,” Linux 3.0, repositório torvalds/linux. [Online]. Disponível em: https://github.com/torvalds/linux/blob/v3.0/MAINTAINERS ↩
[68]Amazon Web Services, “Amazon EC2 FAQs,” consultado em 2 out. 2026. [Online]. Disponível em: https://aws.amazon.com/ec2/faqs/ ↩
[69]A. Honig e N. Porter, “7 ways we harden our KVM hypervisor at Google Cloud: security in plaintext,” Google Cloud Blog, 25 jan. 2017. [Online]. Disponível em: https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext ↩
[70]“MAINTAINERS,” Linux 7.2, repositório torvalds/linux. [Online]. Disponível em: https://github.com/torvalds/linux/blob/v7.2/MAINTAINERS ↩
[71]S. McCanne e V. Jacobson, “The BSD Packet Filter: A New Architecture for User-level Packet Capture,” Lawrence Berkeley Laboratory, 19 dez. 1992. [Online]. Disponível em: https://www.tcpdump.org/papers/bpf-usenix93.pdf ↩
[72]A. Starovoitov, “net: filter: rework/optimize internal BPF interpreter's instruction set,” commit bd4cf0ed331a, 28 mar. 2014. [Online]. Disponível em: https://github.com/torvalds/linux/commit/bd4cf0ed331a275e9bf5a49e6d0fd55dffc551b8 ↩
[73]A. Starovoitov, “bpf: introduce BPF syscall and maps,” commit 99c55f7d47c0, 26 set. 2014. [Online]. Disponível em: https://github.com/torvalds/linux/commit/99c55f7d47c0dc6fc64729f37bf435abf43f4c60 ↩
[74]J. Corbet, “Ktap or BPF?,” LWN.net, 23 abr. 2014. [Online]. Disponível em: https://lwn.net/Articles/595565/ ↩
[75]T. Høiland-Jørgensen, J. D. Brouer, D. Borkmann, J. Fastabend, T. Herbert, D. Ahern e D. Miller, “The eXpress Data Path: Fast Programmable Packet Processing in the Operating System Kernel,” em Proc. CoNEXT '18, 2018, doi: 10.1145/3281411.3281443. [Online]. Disponível em: https://github.com/tohojo/xdp-paper ↩
[76]B. Blanco, “bpf: add XDP prog type for early driver filter,” commit 6a773a15a1e8, 19 jul. 2016. [Online]. Disponível em: https://github.com/torvalds/linux/commit/6a773a15a1e8874e5eccd2f29190c31085912c95 ↩
[77]J. Corbet, “BPF at Facebook (and beyond),” LWN.net, 10 out. 2019. [Online]. Disponível em: https://lwn.net/Articles/801871/ ↩
[78]K. P. Singh, “bpf: Introduce BPF_PROG_TYPE_LSM,” commit fc611f47f218, 29 mar. 2020. [Online]. Disponível em: https://github.com/torvalds/linux/commit/fc611f47f2188ade2b48ff6902d5cce8baac0c58 ↩
[79]J. Corbet, “KRSI — the other BPF security module,” LWN.net, 27 dez. 2019. [Online]. Disponível em: https://lwn.net/Articles/808048/ ↩
[80]D. Thaler, Ed., “BPF Instruction Set Architecture (ISA),” RFC 9669, Internet Engineering Task Force, out. 2024. [Online]. Disponível em: https://www.rfc-editor.org/rfc/rfc9669.html ↩
[81]J. Corbet, “Ringing in a new asynchronous I/O API,” LWN.net, 15 jan. 2019. [Online]. Disponível em: https://lwn.net/Articles/776703/ ↩
[82]J. Axboe, “Add io_uring IO interface,” commit 2b188cc1bb85, 7 jan. 2019. [Online]. Disponível em: https://github.com/torvalds/linux/commit/2b188cc1bb857a9d4701ae59aa7768b5124e262e ↩
[83]J. Axboe, perfil público no GitHub (empresa declarada), consultado em 2 out. 2026. [Online]. Disponível em: https://github.com/axboe ↩
[84]T. Koczka, “Learnings from kCTF VRP's 42 Linux kernel exploits submissions,” Google Online Security Blog, 14 jun. 2023. [Online]. Disponível em: https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html ↩
[85]M. Rizzo, “io_uring: add a sysctl to disable io_uring system-wide,” commit 76d3ccecfa18, 21 ago. 2023. [Online]. Disponível em: https://github.com/torvalds/linux/commit/76d3ccecfa186af3120e206d62f03db1a94a535f ↩
[86]C. Mason, “[ANNOUNCE] Btrfs: a copy on write, snapshotting FS,” mensagem na linux-kernel mailing list, 12 jun. 2007. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/0706.1/1732.html ↩
[87]O. Rodeh, J. Bacik e C. Mason, “BTRFS: The Linux B-Tree Filesystem,” ACM Transactions on Storage, vol. 9, n. 3, 2013, doi: 10.1145/2501620.2501623. [Online]. Disponível em: https://doi.org/10.1145/2501620.2501623 ↩
[88]Kernelnewbies, “Linux 2.6.29,” 23 mar. 2009. [Online]. Disponível em: https://kernelnewbies.org/Linux_2_6_29 ↩
[89]J. Corbet, “Btrfs at Facebook,” LWN.net, 2 jul. 2020. [Online]. Disponível em: https://lwn.net/Articles/824855/ ↩
[90]Red Hat, “Btrfs (Technology Preview),” em Red Hat Enterprise Linux 7 Storage Administration Guide. [Online]. Disponível em: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-btrfs ↩
[91]Fedora Project, “Changes/BtrfsByDefault,” Fedora Project Wiki. [Online]. Disponível em: https://fedoraproject.org/wiki/Changes/BtrfsByDefault ↩
[92]A. Sweeney, D. Doucette, W. Hu, C. Anderson, M. Nishimoto e G. Peck, “Scalability in the XFS File System,” em Proc. USENIX 1996 Annual Technical Conference, 1996. [Online]. Disponível em: https://www.usenix.org/legacy/publications/library/proceedings/sd96/sweeney.html ↩
[93]L. Torvalds, “Linux 2.5.36,” mensagem na linux-kernel mailing list, 17 set. 2002. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/0209.2/0514.html ↩
[94]Red Hat, “The XFS File System,” em Red Hat Enterprise Linux 7 Storage Administration Guide. [Online]. Disponível em: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-xfs ↩
[95]D. J. Wong, “xfs: create an ioctl to scrub AG metadata,” commit 36fd6e863cb7, 17 out. 2017. [Online]. Disponível em: https://github.com/torvalds/linux/commit/36fd6e863cb7329ab2e5687fdae4e4626b840adc ↩
[96]I. Molnar, “[announce] [patch] ultra-scalable O(1) SMP and UP scheduler,” mensagem na linux-kernel mailing list, 3 jan. 2002. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/0201.0/0810.html ↩
[97]J. Corbet, “The Rotating Staircase Deadline Scheduler,” LWN.net, 6 mar. 2007. [Online]. Disponível em: https://lwn.net/Articles/224865/ ↩
[98]I. Molnar, “[Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS],” mensagem na linux-kernel mailing list, 13 abr. 2007. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/0704.1/2138.html ↩
[99]I. Molnar, “sched: cfs core code,” commit dd41f596cda0, 9 jul. 2007. [Online]. Disponível em: https://github.com/torvalds/linux/commit/dd41f596cda0d7d6e4a8b139ffdfabcefdd46528 ↩
[100]I. Stoica e H. Abdel-Wahab, “Earliest Eligible Virtual Deadline First: A Flexible and Accurate Mechanism for Proportional Share Resource Allocation,” Old Dominion University, relatório técnico TR-95-22, 1995. [Online]. Disponível em: https://people.eecs.berkeley.edu/~istoica/papers/eevdf-tr-95.pdf ↩
[101]J. Corbet, “An EEVDF CPU scheduler for Linux,” LWN.net, 9 mar. 2023. [Online]. Disponível em: https://lwn.net/Articles/925371/ ↩
[102]“EEVDF Scheduler,” The Linux Kernel documentation. [Online]. Disponível em: https://docs.kernel.org/scheduler/sched-eevdf.html ↩
[103]P. Zijlstra, “sched/fair: Implement an EEVDF-like scheduling policy,” commit 147f3efaa241, 31 maio 2023. [Online]. Disponível em: https://github.com/torvalds/linux/commit/147f3efaa24182a21706bca15eab2f3f4630b5fe ↩
[104]J. Corbet, “The extensible scheduler class,” LWN.net, 10 fev. 2023. [Online]. Disponível em: https://lwn.net/Articles/922405/ ↩
[105]J. Corbet, “Extensible scheduler class to be merged for 6.11,” LWN.net, 11 jun. 2024. [Online]. Disponível em: https://lwn.net/Articles/978007/ ↩
[106]T. Heo, “sched_ext: Implement BPF extensible scheduler class,” commit f0e1a0643a59, 18 jun. 2024. [Online]. Disponível em: https://github.com/torvalds/linux/commit/f0e1a0643a59bf1f922fa209cec86a170b784f3f ↩
[107]T. Heo, perfil público no GitHub (empresa declarada), consultado em 2 out. 2026. [Online]. Disponível em: https://github.com/htejun ↩
[108]“Extensible Scheduler Class,” The Linux Kernel documentation. [Online]. Disponível em: https://docs.kernel.org/scheduler/sched-ext.html ↩
[109]ProPublica, “The Linux Foundation (EIN 46-0503801),” Nonprofit Explorer, dados dos formulários IRS 990, consultado em 2 out. 2026. [Online]. Disponível em: https://projects.propublica.org/nonprofits/organizations/460503801 ↩
[110]L. Torvalds, “Linux 4.2-rc1,” mensagem na linux-kernel mailing list, 5 jul. 2015. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/1507.0/02156.html ↩
[111]A. Deucher, “drm/amdgpu: add core driver (v4),” commit d38ceaf99ed0, 20 abr. 2015. [Online]. Disponível em: https://github.com/torvalds/linux/commit/d38ceaf99ed015f2a0b9af3499791bd3a3daae21 ↩
[112]M. Brost et al., “drm/xe: Introduce a new DRM driver for Intel GPUs,” commit dd08ebf6c352, 30 mar. 2023. [Online]. Disponível em: https://github.com/torvalds/linux/commit/dd08ebf6c3525a7ea2186e636df064ea47281987 ↩
[113]Kernelnewbies, “Linux 2.6.33,” 24 fev. 2010. [Online]. Disponível em: https://kernelnewbies.org/Linux_2_6_33 ↩
[114]NVIDIA, “NVIDIA Releases Open-Source GPU Kernel Modules,” NVIDIA Technical Blog, maio 2022. [Online]. Disponível em: https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ ↩
[115]D. Krummrich, “gpu: nova-core: add initial driver stub,” commit 54e6baf123fd, 6 mar. 2025. [Online]. Disponível em: https://github.com/torvalds/linux/commit/54e6baf123fde089cfa9f609b0b39b40abe41e94 ↩
[116]E. Cohen, “mlx5: Add driver for Mellanox Connect-IB adapters,” commit e126ba97dba9, 7 jul. 2013. [Online]. Disponível em: https://github.com/torvalds/linux/commit/e126ba97dba9edeb6fafa3665b5f8497fc9cdf8c ↩
[117]NVIDIA, “NVIDIA Completes Acquisition of Mellanox, Creating Major Force Driving Next-Gen Data Centers,” comunicado de imprensa, 27 abr. 2020. [Online]. Disponível em: https://nvidianews.nvidia.com/news/nvidia-completes-acquisition-of-mellanox-creating-major-force-driving-next-gen-data-centers ↩
[118]“patch-2.2.14.gz,” arquivo de kernel.org, 4 jan. 2000. [Online]. Disponível em: https://cdn.kernel.org/pub/linux/kernel/v2.2/patch-2.2.14.gz ↩
[119]“patch-2.5.5.gz,” arquivo de kernel.org, 20 fev. 2002. [Online]. Disponível em: https://cdn.kernel.org/pub/linux/kernel/v2.5/patch-2.5.5.gz ↩
[120]J. Edge, “Linaro seeks to simplify ARM Linux landscape,” LWN.net, 9 jun. 2010. [Online]. Disponível em: https://lwn.net/Articles/391189/ ↩
[121]L. Torvalds, “Re: [GIT PULL] omap changes for v2.6.39 merge window,” mensagem na linux-kernel mailing list, 17 mar. 2011. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/1103.2/01004.html ↩
[122]J. Corbet, “Supporting 64-bit ARM systems,” LWN.net, 10 jul. 2012. [Online]. Disponível em: https://lwn.net/Articles/506148/ ↩
[123]C. Marinas, “arm64: Kernel booting and initialisation,” commit 9703d9d7f77c, 5 mar. 2012. [Online]. Disponível em: https://github.com/torvalds/linux/commit/9703d9d7f77ce129621f7d80a844822e2daa7008 ↩
[124]B. Swetland, “[ARM] msm: board file for MACH_HALIBUT (QCT MSM7200A),” commit 9e73c84c89b7, 26 nov. 2007. [Online]. Disponível em: https://github.com/torvalds/linux/commit/9e73c84c89b7c91ad5d6a141c58efbbe139f6b6c ↩
[125]“MAINTAINERS,” Linux 2.6.35, repositório torvalds/linux. [Online]. Disponível em: https://github.com/torvalds/linux/blob/v2.6.35/MAINTAINERS ↩
[126]P. Dabbelt, “RISC-V: Init and Halt Code,” commit 76d2a0493a17, 10 jul. 2017. [Online]. Disponível em: https://github.com/torvalds/linux/commit/76d2a0493a17d4c8ecc781366850c3c4f8e1a446 ↩
[127]“MAINTAINERS,” Linux 4.15, repositório torvalds/linux. [Online]. Disponível em: https://github.com/torvalds/linux/blob/v4.15/MAINTAINERS ↩
[128]I. Molnar, “[patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0,” mensagem na linux-kernel mailing list, 13 out. 2004. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/0410.1/1577.html ↩
[129]“Lock types and their rules,” The Linux Kernel documentation. [Online]. Disponível em: https://docs.kernel.org/locking/locktypes.html ↩
[130]T. Gleixner, “genirq: add threaded interrupt handler support,” commit 3aa551c9b4c4, 23 mar. 2009. [Online]. Disponível em: https://github.com/torvalds/linux/commit/3aa551c9b4c40018f0e261a178e3d25478dc04a9 ↩
[131]T. Gleixner, “sched/rt, Kconfig: Introduce CONFIG_PREEMPT_RT,” commit a50a3f4b6a31, 17 jul. 2019. [Online]. Disponível em: https://github.com/torvalds/linux/commit/a50a3f4b6a313dc76912bd4ad3b8b4f4b479c801 ↩
[132]The Linux Foundation, “The Linux Foundation Announces Project to Advance Real-Time Linux,” comunicado de imprensa reproduzido por Firmenpresse, out. 2015. [Online]. Disponível em: https://www.firmenpresse.de/pressrelease424560/the-linux-foundation-announces-project-to-advance-real-time-linux.html ↩
[133]J. Corbet, “Intel acquires Linutronix,” LWN.net, 23 fev. 2022. [Online]. Disponível em: https://lwn.net/Articles/885903/ ↩
[134]L. Torvalds, “Merge tag 'printk-for-6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux,” commit c903327d3295, 17 set. 2024. [Online]. Disponível em: https://github.com/torvalds/linux/commit/c903327d3295b135eb8c81ebe0b68c1837718eb8 ↩
[135]S. A. Siewior, “x86: Allow to enable PREEMPT_RT.,” commit d2d6422f8bd1, 6 set. 2024. [Online]. Disponível em: https://github.com/torvalds/linux/commit/d2d6422f8bd17c6bb205133e290625a564194496 ↩
[136]L. Torvalds, “Merge tag 'sched-rt-2024-09-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip,” commit baeb9a7d8b60, 20 set. 2024. [Online]. Disponível em: https://github.com/torvalds/linux/commit/baeb9a7d8b60b021d907127509c44507539c15e5 ↩
[137]J. Edge, “Rust heads into the kernel?,” LWN.net, 21 abr. 2021. [Online]. Disponível em: https://lwn.net/Articles/853423/ ↩
[138]J. Aas, “Supporting Miguel Ojeda's Work on Rust in the Linux Kernel,” Prossimo (ISRG), 17 jun. 2021. [Online]. Disponível em: https://www.memorysafety.org/blog/supporting-miguel-ojeda-rust-in-linux/ ↩
[139]L. Torvalds, “Merge tag 'rust-v6.1-rc1' of https://github.com/Rust-for-Linux/linux,” commit 8aebac82933f, 3 out. 2022. [Online]. Disponível em: https://github.com/torvalds/linux/commit/8aebac82933ff1a7c8eede18cab11e1115e2062b ↩
[140]A. Ryhl, “rust_binder: add Rust Binder driver,” commit eafedbc7c050, 19 set. 2025. [Online]. Disponível em: https://github.com/torvalds/linux/commit/eafedbc7c050c44744fbdf80bdf3315e860b7513 ↩
[141]J. Corbet, “The state of the kernel Rust experiment,” LWN.net, 13 dez. 2025. [Online]. Disponível em: https://lwn.net/Articles/1050174/ ↩
[142]M. Ojeda, “rust: conclude the Rust experiment,” commit 9fa7153c31a3, 13 dez. 2025. [Online]. Disponível em: https://github.com/torvalds/linux/commit/9fa7153c31a3e5fe578b83d23bc9f185fde115da ↩
[143]G. Krisman Bertazi, “futex: Implement mechanism to wait on any of several futexes,” patch reproduzido no LWN.net, 30 jul. 2019. [Online]. Disponível em: https://lwn.net/Articles/794969/ ↩
[144]A. Almeida, “futex: Implement sys_futex_waitv(),” commit bf69bad38cf6, 23 set. 2021. [Online]. Disponível em: https://github.com/torvalds/linux/commit/bf69bad38cf63d980e8a603f8d1bd1f85b5ed3d9 ↩
[145]Kernelnewbies, “Linux 5.16,” 9 jan. 2022. [Online]. Disponível em: https://kernelnewbies.org/Linux_5.16 ↩
[146]The kernel development community, “2. How the development process works,” em A guide to the Kernel Development Process, The Linux Kernel documentation. [Online]. Disponível em: https://docs.kernel.org/process/2.Process.html ↩
[147]The kernel development community, “Everything you ever wanted to know about Linux -stable releases,” The Linux Kernel documentation. [Online]. Disponível em: https://docs.kernel.org/process/stable-kernel-rules.html ↩
[148]kernel.org, “Releases,” consultado em 2 out. 2026. [Online]. Disponível em: https://www.kernel.org/category/releases.html ↩
[149]J. Corbet, “A turning point for CVE numbers,” LWN.net, 14 fev. 2024. [Online]. Disponível em: https://lwn.net/Articles/961332/ ↩
[150]The kernel development community, “CVEs,” The Linux Kernel documentation. [Online]. Disponível em: https://docs.kernel.org/process/cve.html ↩
[151]LWN.net, “Kroah-Hartman: Linux CVEs, more than you ever wanted to know,” LWN.net, 10 dez. 2025. [Online]. Disponível em: https://lwn.net/Articles/1049963/ ↩
[152]The Linux Foundation, Annual Report 2025. The Linux Foundation, dez. 2025. [Online]. Disponível em: https://www.linuxfoundation.org/hubfs/Publications/2025%20Linux%20Foundation%20Annual%20Report_122225a_lr.pdf ↩
[153]The Linux Foundation, “Technical Advisory Board,” consultado em 2 out. 2026. [Online]. Disponível em: https://www.linuxfoundation.org/about/technical-advisory-board ↩
[154]Linux Plumbers Conference, página da contribuição de J. Kicinski, LPC 2025. [Online]. Disponível em: https://lpc.events/event/19/contributions/2289/ ↩
[155]Open Source Summit North America 2025, página da palestra de D. Borkmann. [Online]. Disponível em: https://ossna2025.sched.com/event/d3d6bc22578712b8eca7f0c202b195f5 ↩
[156]J. Corbet, “A new era for memory-management maintainership,” LWN.net, 7 maio 2026. [Online]. Disponível em: https://lwn.net/Articles/1070994/ ↩
[157]The Linux Foundation, Annual Report 2024. The Linux Foundation, dez. 2024. [Online]. Disponível em: https://linuxfoundation.org/hubfs/Reports/lf_ar24_121524a.pdf ↩
[158]M. Ojeda, “2025 LF Technical Advisory Board election - update,” mensagem na linux-kernel mailing list, 5 dez. 2025. [Online]. Disponível em: https://lkml.iu.edu/2512.0/05847.html ↩
[159]The Linux Foundation, “Bylaws,” consultado em 2 out. 2026. [Online]. Disponível em: https://www.linuxfoundation.org/legal/bylaws ↩
[160]M. Ojeda, “2025 LF Technical Advisory Board election - results,” mensagem na linux-kernel mailing list, 21 dez. 2025. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/2512.2/07130.html ↩
[161]J. Corbet, “An open seat on the TAB,” LWN.net, 8 dez. 2025. [Online]. Disponível em: https://lwn.net/Articles/1049035/ ↩
[162]G. Kroah-Hartman, “The Linux Kernel Driver Interface (all of your questions answered and then some),” The Linux Kernel documentation. [Online]. Disponível em: https://docs.kernel.org/process/stable-api-nonsense.html ↩
[163]J. Edge, “Moving Google toward the mainline,” LWN.net, 5 out. 2021. [Online]. Disponível em: https://lwn.net/Articles/871195/ ↩
[164]B. Matheny e C. Mason, “Improving the Linux kernel with upstream contributions,” Engineering at Meta, 5 out. 2015. [Online]. Disponível em: https://engineering.fb.com/2015/10/05/open-source/improving-the-linux-kernel-with-upstream-contributions/ ↩
[165]Y. Brosseau, “Upstream kernels @ Facebook,” palestra no SCALE 14x, jan. 2016. [Online]. Disponível em: https://www.socallinuxexpo.org/scale/14x/presentations/upstream-kernels-facebook ↩
[166]Amazon Web Services, “Amazon Linux 2023 kernel lifecycle,” Amazon Linux 2023 User Guide, consultado em 2 out. 2026. [Online]. Disponível em: https://docs.aws.amazon.com/linux/al2023/ug/kernel-lifecycle.html ↩
[167]J. Edge, “ELC: Android and the community,” LWN.net, 14 abr. 2010. [Online]. Disponível em: https://lwn.net/Articles/383276/ ↩
[168]J. Corbet, “Bringing Android closer to the mainline,” LWN.net, 20 dez. 2011. [Online]. Disponível em: https://lwn.net/Articles/472984/ ↩
[169]J. Corbet, “Autosleep and wake locks,” LWN.net, 7 fev. 2012. [Online]. Disponível em: https://lwn.net/Articles/479841/ ↩
[170]Kernelnewbies, “Linux 3.5,” 21 jul. 2012. [Online]. Disponível em: https://kernelnewbies.org/Linux_3.5 ↩
[171]J. Corbet, “An update on the Android problem,” LWN.net, 7 nov. 2017. [Online]. Disponível em: https://lwn.net/Articles/738225/ ↩
[172]J. Corbet, “Bringing the Android kernel back to the mainline,” LWN.net, 15 nov. 2018. [Online]. Disponível em: https://lwn.net/Articles/771974/ ↩
[173]J. Corbet, “Android kernel notes from LPC 2020,” LWN.net, 10 set. 2020. [Online]. Disponível em: https://lwn.net/Articles/830979/ ↩
[174]Android Open Source Project, “Generic Kernel Image (GKI) project,” source.android.com, consultado em 2 out. 2026. [Online]. Disponível em: https://source.android.com/docs/core/architecture/kernel/generic-kernel-image ↩
[175]Android Open Source Project, “Android common kernels,” source.android.com, consultado em 2 out. 2026. [Online]. Disponível em: https://source.android.com/docs/core/architecture/kernel/android-common ↩
[176]P. Galli, “Microsoft Releases Device Driver Code to the Linux Community,” Port25 (Microsoft), 20 jul. 2009. [Online]. Disponível em: https://learn.microsoft.com/en-us/archive/blogs/port25/microsoft-releases-device-driver-code-to-the-linux-community ↩
[177]G. Kroah-Hartman, “[patch 00/54] [Announce] Microsoft Hyper-V drivers for Linux,” mensagem na linux-kernel mailing list, 20 jul. 2009. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/0907.2/01249.html ↩
[178]The Linux Foundation, “Microsoft Fortifies Commitment to Open Source, Becomes Linux Foundation Platinum Member,” comunicado de imprensa, 16 nov. 2016. [Online]. Disponível em: https://www.linuxfoundation.org/press/press-release/microsoft-fortifies-commitment-to-open-source-becomes-linux-foundation-platinum-member ↩
[179]Microsoft, “WSL2-Linux-Kernel: The source for the Linux kernel used in Windows Subsystem for Linux 2 (WSL2),” repositório no GitHub. [Online]. Disponível em: https://github.com/microsoft/WSL2-Linux-Kernel ↩
[180]Sony Interactive Entertainment, “Open Source Software used in PlayStation®4,” consultado em 2 out. 2026. [Online]. Disponível em: https://www.playstation.com/en-us/oss/ps4/ ↩
[181]Apple, “xnu,” repositório apple-oss-distributions no GitHub. [Online]. Disponível em: https://github.com/apple-oss-distributions/xnu ↩
[182]J. Looney, “Netflix and FreeBSD: Reflections on Running FreeBSD Head in Production,” BSDCan 2019, 2019. [Online]. Disponível em: https://papers.freebsd.org/2019/bsdcan/looney-netflix_and_freebsd/ ↩
[183]K. Vervloesem, “Illumos: new hope for the OpenSolaris community?,” LWN.net, 11 ago. 2010. [Online]. Disponível em: https://lwn.net/Articles/399533/ ↩
[184]J. Lerner e J. Tirole, “Some Simple Economics of Open Source,” The Journal of Industrial Economics, vol. 50, n. 2, pp. 197–234, 2002, doi: 10.1111/1467-6451.00174. Versão de trabalho: NBER Working Paper 7600, 2000. [Online]. Disponível em: https://www.nber.org/papers/w7600 ↩
[185]J. West e S. Gallagher, “Challenges of open innovation: the paradox of firm investment in open-source software,” R&D Management, vol. 36, n. 3, pp. 319–331, 2006, doi: 10.1111/j.1467-9310.2006.00436.x. [Online]. Disponível em: https://scholarworks.sjsu.edu/org_mgmt_pub/3 ↩
[186]J. Henkel, “Selective revealing in open innovation processes: The case of embedded Linux,” Research Policy, vol. 35, n. 7, pp. 953–969, 2006, doi: 10.1016/j.respol.2006.04.010. [Online]. Disponível em: https://doi.org/10.1016/j.respol.2006.04.010 ↩
[187]M. Hoffmann, F. Nagle e Y. Zhou, “The Value of Open Source Software,” Harvard Business School, Working Paper 24-038, 2024. [Online]. Disponível em: https://www.hbs.edu/ris/Publication%20Files/24-038_51f8444f-502c-4139-8bf2-56eb4b65c58a.pdf ↩
[188]N. Eghbal, Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure. Ford Foundation, 2016. [Online]. Disponível em: https://www.fordfoundation.org/wp-content/uploads/2016/07/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure.pdf ↩
[189]Google, “syzkaller: an unsupervised coverage-guided kernel fuzzer,” repositório no GitHub (criado em 12 out. 2015). [Online]. Disponível em: https://github.com/google/syzkaller ↩
[190]Google, “syzbot,” documentação do syzkaller. [Online]. Disponível em: https://github.com/google/syzkaller/blob/master/docs/syzbot.md ↩
[191]D. Vyukov, “Reflections on kernel development process, quality and testing,” apresentação no Linux Kernel Maintainers Summit, 2019. [Online]. Disponível em: https://lpc.events/event/4/contributions/554/attachments/353/584/Reflections__Kernel_Summit_2019.pdf ↩
[192]syzbot, “Linux upstream,” painel consultado em 2 out. 2026. [Online]. Disponível em: https://syzkaller.appspot.com/upstream ↩
[193]M. Kerrisk, “KS2012: Kernel build/boot testing,” LWN.net, 5 set. 2012. [Online]. Disponível em: https://lwn.net/Articles/514278/ ↩
[194]Intel, “lkp-tests: Linux Kernel Performance tests,” repositório no GitHub. [Online]. Disponível em: https://github.com/intel/lkp-tests ↩
[195]J. Corbet, “Some 5.5 kernel development statistics,” LWN.net, 28 jan. 2020. [Online]. Disponível em: https://lwn.net/Articles/810639/ ↩
[196]The Linux Foundation, “Distributed Linux Testing Platform KernelCI Secures Funding and Long-Term Sustainability as New Linux Foundation Project,” comunicado reproduzido em kernelci.org, 28 out. 2019. [Online]. Disponível em: https://kernelci.org/?p=56 ↩
[197]KernelCI, página inicial e lista de membros, consultada em 2 out. 2026. [Online]. Disponível em: https://kernelci.org/ ↩
[198]A. Ryabinin, “kasan: add kernel address sanitizer infrastructure,” commit 0b24becc810d, 13 fev. 2015. [Online]. Disponível em: https://github.com/torvalds/linux/commit/0b24becc810dc3be6e3f94103a866f214c282394 ↩
[199]M. Elver, “kcsan: Add Kernel Concurrency Sanitizer infrastructure,” commit dfd402a4c4ba, 14 nov. 2019. [Online]. Disponível em: https://github.com/torvalds/linux/commit/dfd402a4c4baae42398ce9180ff424d589b8bffc ↩
[200]J. Corbet, “5.8 Merge window, part 2,” LWN.net, 14 jun. 2020. [Online]. Disponível em: https://lwn.net/Articles/822527/ ↩
[201]A. Potapenko, “kmsan: add KMSAN runtime core,” commit f80be4571b19, 15 set. 2022. [Online]. Disponível em: https://github.com/torvalds/linux/commit/f80be4571b19b9fd8dd1528cd2a2f123aff51f70 ↩
[202]A. Morton, “[GIT PULL] MM updates for 6.1-rc1,” mensagem na linux-kernel mailing list, 8 out. 2022. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/2210.1/00272.html ↩
[203]B. Higgins, “kunit: test: add KUnit test runner core,” commit 914cc63eea6f, 23 set. 2019. [Online]. Disponível em: https://github.com/torvalds/linux/commit/914cc63eea6fbe11ed46dba5e4438d81b0cd42d2 ↩
[204]The kernel development community, “Linux Kernel Selftests,” The Linux Kernel documentation. [Online]. Disponível em: https://docs.kernel.org/dev-tools/kselftest.html ↩
[205]J. Corbet, “Reducing kernel-maintainer burnout,” LWN.net, 24 nov. 2023. [Online]. Disponível em: https://lwn.net/Articles/952034/ ↩
[206]J. Edge, “Maintainers don't scale,” LWN.net, 6 jun. 2022. [Online]. Disponível em: https://lwn.net/Articles/896918/ ↩
[207]M. Zhou, Q. Chen, A. Mockus e F. Wu, “On the scalability of Linux kernel maintainers' work,” em Proc. ESEC/FSE 2017, 2017, doi: 10.1145/3106237.3106287. [Online]. Disponível em: https://par.nsf.gov/biblio/10063576 ↩
[208]L. Collin, “Re: [xz-devel] XZ for Java,” mensagem na lista xz-devel, 8 jun. 2022. [Online]. Disponível em: https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html ↩
[209]A. Freund, “backdoor in upstream xz/liblzma leading to ssh server compromise,” mensagem na lista oss-security, 29 mar. 2024. [Online]. Disponível em: https://www.openwall.com/lists/oss-security/2024/03/29/4 ↩
[210]J. Tan, “Tests: Update two test files.,” commit 6e636819e8f0, repositório tukaani-project/xz, 9 mar. 2024. [Online]. Disponível em: https://github.com/tukaani-project/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89 ↩
[211]R. Russell et al., “Unreliable Guide To Hacking The Linux Kernel,” The Linux Kernel documentation. [Online]. Disponível em: https://docs.kernel.org/kernel-hacking/hacking.html ↩
[212]C. Hellwig, “modules: inherit TAINT_PROPRIETARY_MODULE,” commit 262e6ae7081d, 28 jul. 2020. [Online]. Disponível em: https://github.com/torvalds/linux/commit/262e6ae7081df304fc625cf368d5c2cbba2bb991 ↩
[213]J. Corbet, “Making life (even) harder for proprietary modules,” LWN.net, 3 ago. 2023. [Online]. Disponível em: https://lwn.net/Articles/939842/ ↩
[214]M. Larabel, “Linus Torvalds Calls NVIDIA The Worst Company,” Phoronix, 17 jun. 2012 (fonte secundária). [Online]. Disponível em: https://www.phoronix.com/news/MTEyMTc ↩
[215]L. Torvalds, “Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation,” mensagem na linux-kernel mailing list, 21 jan. 2018. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html ↩
[216]The kernel development community, “Embargoed hardware issues,” The Linux Kernel documentation. [Online]. Disponível em: https://docs.kernel.org/process/embargoed-hardware-issues.html ↩
[217]G. Kroah-Hartman, “MAINTAINERS: Remove some entries due to various compliance requirements.,” commit 6e90b675cf94, 18 out. 2024. [Online]. Disponível em: https://github.com/torvalds/linux/commit/6e90b675cf942e50c70e8394dfb5862975c3b3b2 ↩
[218]J. Corbet, “Several Russian developers lose kernel maintainership status,” LWN.net, 22 out. 2024, com atualizações. [Online]. Disponível em: https://lwn.net/Articles/995186/ ↩
[219]P. Moore, “Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.,” mensagem na linux-kernel mailing list, out. 2024. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/2410.2/09875.html ↩
[220]J. Bottomley, “Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.,” mensagem na linux-kernel mailing list, 24 out. 2024. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/2410.3/01081.html ↩
[221]W. Almeida Filho, “[PATCH 0/1] Retiring from the Rust for Linux project,” mensagem nas listas do kernel, 28 ago. 2024. [Online]. Disponível em: https://patchew.org/linux/20240828211117.9422-1-wedsonaf@gmail.com ↩
[222]C. Hellwig, “Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.,” mensagem na linux-kernel mailing list, 28 jan. 2025. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/2501.3/03615.html ↩
[223]C. Hellwig, “Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.,” mensagem na linux-kernel mailing list, 31 jan. 2025. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/2501.3/06788.html ↩
[224]L. Torvalds, resposta a H. Martin na discussão sobre a abstração de DMA em Rust, linux-kernel mailing list, 6 fev. 2025. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/2502.0/07186.html ↩
[225]H. Martin, “[PATCH] MAINTAINERS: Remove myself,” mensagem na linux-kernel mailing list, fev. 2025. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/2502.0/07276.html ↩
[226]L. Torvalds, “Re: Rust kernel policy,” mensagem na linux-kernel mailing list, 20 fev. 2025. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/2502.2/08504.html ↩
[227]Rust for Linux, “Rust kernel policy,” consultado em 2 out. 2026. [Online]. Disponível em: https://rust-for-linux.com/rust-kernel-policy ↩
[228]L. Torvalds, “MAINTAINERS: mark bcachefs externally maintained,” commit ebf2bfec412a, 28 ago. 2025. [Online]. Disponível em: https://github.com/torvalds/linux/commit/ebf2bfec412ad293a0b118fb1a20a551088ebc9b ↩
[229]L. Torvalds, “Remove bcachefs core code,” commit f2c61db29f27, 29 set. 2025. [Online]. Disponível em: https://github.com/torvalds/linux/commit/f2c61db29f277b9c80de92102fc532cc247495cd ↩
[230]Linux Foundation Technical Advisory Board, “Report on University of Minnesota Breach-of-Trust Incident,” mensagem na linux-kernel mailing list, 5 maio 2021. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/2105.0/04009.html ↩
[231]S. Smalley, “selinux: de-brand SELinux,” commit 90aa4f5e92f2, 18 jul. 2023. [Online]. Disponível em: https://github.com/torvalds/linux/commit/90aa4f5e92f2797c3c86e05f588ab277b0e0ba39 ↩
[232]P. Moore, “[GIT PULL] SELinux patches for v6.6,” mensagem na linux-kernel mailing list, 29 ago. 2023. [Online]. Disponível em: https://lkml.iu.edu/hypermail/linux/kernel/2308.3/05977.html ↩

Abstract

Linux started in 1991 as a student's hobby, and that is how many people still picture it. The numbers tell a different story. In kernel 7.2, released in August 2026, 78.8% of the 16,418 commits came from people with an affiliation LWN could identify, whether a company, a consultancy or an institution. Only 4.5% came from people working on their own, against 16.8% in 2009. Those who accept the patches are even more corporate: in 6.19, only 1.6% of maintainer sign-offs came from people without an employer. Cgroups, KVM, eBPF, io_uring, Btrfs, sched_ext, PREEMPT_RT and ARM64 support were born out of corporate needs and reached mainline written by corporate employees. The robots that test the kernel have owners too. This article rebuilds that story from the git log, the MAINTAINERS file, LWN's statistics and the reports of the Linux Foundation, which set aside 2.95% of its forecast 2025 spending for the kernel. It shows what this model explains and what it leaves unsolved: scarce review, overloaded maintainers, concentration, sanctions and the fight over Rust. The origin was personal. The infrastructure is industrial.

From a hobby to a budget line (1991–2005)

On August 25, 1991, a student at the University of Helsinki posted a short poll to the comp.os.minix newsgroup about an operating system he had been writing since April: "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones" [1]. In a postscript, Linus Torvalds warned that the code was not portable and would probably never support anything but AT disks, "as that's all I have".

Thirty-five years later, the same project closed version 7.2 with 16,418 commits made in nine weeks by 2,652 people, and LWN identified 249 companies paying for part of them [2]. The hobby did not become big and professional by accident. It did because someone started paying.

There was an obvious competitor. Berkeley's BSD already had a PC port, 386BSD, but it was caught in a long lawsuit over the legal status of the Net/2 tape, between the University of California and the owner of the Unix code, AT&T and later Novell. The settlement only came in 1994 and required the removal of three files deemed "encumbered" [3]. In November 1993, Linus told Meta magazine he had never tried 386BSD: "If 386BSD had been available when I started on Linux, Linux would probably never had happened" [4]. Linux grew through a window opened by litigation between a university and a company. It would not be the last lawsuit in this story.

The first salaries came from those who sold the system. Red Hat went public on August 11, 1999, offering 6 million shares at US$14 [5]; on the first trading day the stock opened at US$48.50 [6]. In November 2001, the messages in which Marcelo Tosatti ran the 2.4 stable series, the one that ran on the servers of the time, came from marcelo@conectiva.com.br [7]. Conectiva was a distribution based in Curitiba, Brazil. The maintainer of the kernel's stable tree was on the payroll of a Brazilian company.

In December 2000, IBM announced it would spend US$1 billion on Linux in 2001, according to the News.com and ZDNet coverage collected by LWN [8]. I could not find IBM's original press release. Vice president of technology Irving Wladawsky-Berger said the company had already invested about 1 billion and that the figure would grow, and LWN remarked in the same issue: "IBM is not a philanthropic organization. What they invest now they expect to get back" [9]. Since August 1999, IBM had run a Linux Technology Center, which had about 185 employees in 2001 [10].

On August 31, 2000, HP, Intel, IBM and NEC founded the Open Source Development Lab, OSDL, with Caldera, Dell, Red Hat, SuSE, SGI and others as sponsors [11]. On June 17, 2003, Linus left Transmeta, a processor maker where he had worked for more than six years, and became the first "OSDL Fellow". The announcement said he would work "exclusively on leading the development of Linux" [12]. For the first time, the kernel's creator was paid to look after it alone, and the payer was a consortium of manufacturers. In January 2007, OSDL merged with the Free Standards Group and became the Linux Foundation [13].

Money also changed hands through acquisitions. On November 4, 2003, Novell announced it would buy SUSE: "Novell will pay $210 million in cash". In the same announcement, IBM committed to investing US$50 million in Novell preferred stock [14].

Three months before Linus moved to OSDL, in March 2003, the SCO Group sued IBM in a Utah court for misappropriation of trade secrets, tortious interference, unfair competition and breach of contract, seeking damages of "no less than $1 billion" [15]. The underlying accusation was that Unix code had reached Linux through IBM. In August 2007, SCO itself reported to the SEC the adverse ruling on ownership of the UNIX copyrights, in its case against Novell [16]. The case against IBM only ended in 2021, with a US$14.25 million settlement between IBM and SCO's bankruptcy trustee [17].

The kernel's answer was not legal; it was procedural. On May 23, 2004, Linus proposed that every patch carry a Signed-off-by: line [18]. The message opens with "this crazy company called SCO", which supposedly had a hard time believing that open source works better "than their five engineers do". Whoever signs certifies, under the Developer's Certificate of Origin, that they wrote the contribution or have the right to pass it on under an open license [19], [20]. The sign-off was born as a defense against a lawsuit. Twenty years later, it is what makes it possible to count, patch by patch, who works for whom. It is the raw material for almost every statistic in the next section.

Version control also came from a company. During the 2.5 series, Linus adopted BitKeeper, from BitMover. It was proprietary software, shipped only in binary form, with a free license for open source projects that imposed restrictions [21]. In November 2003, someone inserted two lines into the wait4() function in the kernel's CVS mirror [22]:

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
        retval = -EINVAL;

It is a = instead of ==. Instead of checking whether the user was root, the line made the caller root. Anyone calling wait4() with those two flags would gain full privileges. The change was caught because every legitimate CVS commit pointed to a BitKeeper changeset, and this one did not. The person who noticed was Larry McVoy, BitMover's owner [22].

In April 2005, the free version ended. LWN recorded that the last straw was "a certain high-profile developer who refused to stop reverse engineering work while simultaneously doing some work for OSDL" [21]. On April 6, Linus wrote that "the kernel team is looking at alternatives" and asked people not to blame BitMover [23]. The next day he made the first commit of a new tool: "Initial revision of "git", the information manager from hell" [24]. On April 16, the kernel moved to Git with commit 1da177e4, "Linux-2.6.12-rc2", without the earlier history, which would have added up to "about 3.2GB" [25].

The development model changed in the same period. At the July 2004 Kernel Summit, Andrew Morton argued for a 2.6 series that kept changing and let "the distributors do the final stabilization work" [26]. The odd-numbered development series ended. Stabilization moved to those who sell support.

Date	Event	Who paid or prompted it
Aug 1991	Post on comp.os.minix	nobody: a hobby
Nov 1993	Linus says 386BSD was not available when he started	the Net/2 lawsuit
Aug 1999	Red Hat IPO; Linux Technology Center	Red Hat; IBM
Aug 2000	OSDL founded	HP, Intel, IBM and NEC
Dec 2000	US$1 billion for Linux in 2001	IBM
Nov 2001	2.4 series run from a Conectiva address	Conectiva
Mar 2003	SCO sues IBM	SCO
Jun 2003	Linus becomes the first OSDL Fellow	OSDL, that is, its member companies
Nov 2003	Novell buys SUSE; attempted backdoor in `wait4()`	Novell and IBM; BitKeeper catches it
May 2004	Developer's Certificate of Origin and `Signed-off-by`	response to the SCO lawsuit
Apr 2005	End of free BitKeeper; Git is born	BitMover

By 2005, the kernel had a creator paid by a consortium of manufacturers, a sign-off rule created against a corporate lawsuit and a version control tool born out of a license dispute. The origin was personal. The infrastructure that let the project grow was not.

Who writes the kernel

I have written that something like 80% of the kernel is made by big tech. I went to check. The number is almost right. The word is not.

In February 2007, Jonathan Corbet, editor of LWN, hacked up some scripts to find out where the code in 2.6.20 came from. The method was simple and admittedly imperfect, because "very few developers say 'I wrote this on behalf of my employer.'" Every patch whose email address pointed to a company was counted as that company's work [27]. LWN has repeated the analysis for every release since, and two rows of its tables matter more than the rest. "(None)" are developers LWN knows to be working on their own time. "(Unknown)" are those it could not identify, a mix of volunteers and employees who use personal addresses. As early as 2007, the conclusion was that "at least 65% of the code which went into 2.6.20 was created by people working for companies". The "at least" came from 25.0% of the commits sitting in "(Unknown)", and the hypothesis that all of them were volunteers was treated as "an unlikely result" [27].

The Linux Foundation's annual reports, written by the same Corbet with Greg Kroah-Hartman, arrived at the same place. In 2008, they estimated that between 70% and 95% of developers were paid, which would dispel the "'hobbyist' myth present from the start of open source development" [28]. In 2012, it was 75% of development [29]. In 2015, more than 80% [30]. The 2017 report is the most direct: even assuming that all of the "unknown" contributors worked for free, "well over 85 percent of all kernel development is demonstrably done by developers who are being paid for their work". The unpaid share had fallen from 14.6% in the 2012 report to 8.2%, and the explanation given is about the job market: "kernel developers are in short supply, so anybody who demonstrates an ability to get code into the mainline tends not to have trouble finding job offers" [31]. The volunteer who succeeds becomes an employee.

LWN's series shows the peak of employer-free work in 2009, with 16.8% of the commits in 2.6.30 [32]. After that, the share falls almost without pause: 12.0% in 3.0 [33], 8.6% in 4.0 [34], 3.1% in 6.0 [35]. There was one large and instructive exception. In 6.7, from January 2024, "(None)" jumped to 18.1%. It was not a return of the volunteers. It was bcachefs, a filesystem Kent Overstreet developed "on his own, supported by interested users on Patreon", whose entire history landed at once [36]. One person moved the average for the whole kernel, and the same bcachefs would leave mainline less than two years later, as the section on tensions explains.

Release	Released	Commits (LWN)	No employer, "(None)"	Unidentified, "(Unknown)"
2.6.20	2007-02-04	4,983	7.7%	25.0%
2.6.30	2009-06-09	11,733 through rc7	16.8%	10.1%
3.0	2011-07-21	9,007 through rc7	12.0%	6.3%
4.0	2015-04-12	just over 10,000	8.6%	7.1%
6.0	2022-10-02	15,402	3.1%	6.6%
6.7	2024-01-07	17,284	18.1% (bcachefs)	6.7%
6.18	2025-11-30	13,710	4.6%	9.5%
7.2	2026-08-16	16,418	4.5%	16.7%

Dates are those of the tags in the kernel repository [37]; percentages count commits, and the sources are LWN's articles for each release [27], [32], [33], [34], [35], [36], [38], [2]. For the whole of 2025, from 6.13 to 6.18, LWN counted 5.3% with no employer and 8.5% unidentified [38].

The 16.7% "(Unknown)" in 7.2 is the highest figure in the recent series, and LWN itself attributes it "partially, at least" to the "ongoing flood of new developers entering the kernel community". There were 613 first-time contributors, a record. In the same cycle, 1,111 changes, "under 7% of the total", carried the Assisted-by tag, which declares the use of AI tools, against 301 in 7.1 [2]. The unknown is growing, and part of it arrives with a language model at its side.

These are the companies in 7.2, by commits [2]:

Employer	Commits	Share
(Unknown)	2,743	16.7%
Intel	1,512	9.2%
Google	1,191	7.3%
Red Hat	873	5.3%
AMD	813	5.0%
Qualcomm	767	4.7%
(None)	743	4.5%
NVIDIA	535	3.3%
Meta	441	2.7%
(Consultant)	429	2.6%
SUSE	358	2.2%
Renesas Electronics	328	2.0%
IBM	307	1.9%
Kylin	278	1.7%
NXP Semiconductors	264	1.6%

Back to my sentence. Taking out "(Unknown)" and "(None)", 12,932 of the 16,418 commits in 7.2 remain, or 78.8%, from people with an identified affiliation: companies, consultancies, universities [2]. "Something like 80%" holds. "Big tech" does not. The five largest named companies, Intel, Google, Red Hat, AMD and Qualcomm, add up to 5,156 commits, 31.4%. The ten largest, 43.4%. The rest is spread across 249 employers: chipmakers such as Renesas and NXP, consultancies such as BayLibre and Bootlin, distributions such as SUSE and Kylin. By lines changed, the order shifts: AMD leads, with 22.4% [2]. The kernel is not written by half a dozen companies. It is written by a whole industry.

Writing is half the power. The other half is accepting. When a maintainer applies a patch to their tree, they add their own Signed-off-by; counting those sign-offs from people other than the author shows who controls what goes in. In 2009, 42.4% of them came from Red Hat employees [32]. In 2017, "over half of the patches going into the kernel pass through the hands of developers employed by just five companies" [31]. In 2023, LWN ran the numbers again and reached the same point: "over 50% of the changes going into the kernel pass through the hands of maintainers working for just five companies" [39]. In 6.19, from February 2026, Meta leads, and maintainer sign-offs from people without an employer are 1.6% [40].

Employer	2.6.30 (2009)	4.8 to 4.13 (2017)	6.19 (2026)
Red Hat	42.4%	20.6%	4.9%
Intel	9.5%	9.7%	9.5%
Google	6.6%	7.4%	9.9%
Linux Foundation	2.2%	9.1%	3.4%
Novell, later SUSE	13.8% (Novell)	2.4% (SUSE)	3.2% (SUSE)
Linaro	not listed	7.9%	6.0%
Meta (formerly Facebook)	not listed	2.0%	11.8%
Arm	not listed	1.3%	8.9%
AMD	not listed	2.4%	6.5%
No employer	4.1%	3.9%	1.6%

The table shows Signed-off-by tags from people other than the patch author, that is, from those who accepted the code [32], [31], [40]. "Not listed" means the company does not appear among those published for that period.

And who reads what goes in? Commit tags tell part of the story. I counted in the git log the share of commits with at least one Reviewed-by, Acked-by or Tested-by [37]:

Release	Non-merge commits	Reviewed-by	Acked-by	Tested-by	At least one of the three
2.6.20	4,768	0.0%	10.2%	0.1%	10.3%
3.0	9,153	7.5%	13.6%	3.8%	22.4%
4.0	10,346	16.8%	15.5%	5.6%	34.1%
5.0	12,808	31.6%	16.6%	5.7%	46.2%
6.0	15,402	39.2%	16.2%	9.0%	52.9%
7.0	14,251	53.8%	13.3%	9.4%	64.1%
7.2	16,418	48.2%	13.6%	8.0%	58.6%

The method: git log --no-merges between each release's tags, in a clone of the torvalds/linux repository taken on October 2, 2026, counting commits whose message has a line starting with one of the three tags. For older releases, the git log counts differ slightly from LWN's, which used a different cut. For 6.18, LWN recorded 53.6% with Reviewed-by and called the number "typical" [38]. So, in 2026, two out of every five commits go in with no review tag at all, only the sign-offs of whoever wrote it and whoever applied it. In 7.2, that was 6,794 commits. This does not mean nobody read them: a lot of review happens on the list without becoming a tag, and the maintainer applying a patch reads what they apply. But "anyone can audit the kernel" needs an asterisk. Anyone can. A record that someone other than the author and the maintainer looked exists for just over half of what goes in.

Academic work reaches similar numbers by other routes. Urs Lerch's thesis at TU Berlin analyzed all of the kernel's logs for 2007 and concluded that "commercial companies contribute 75 percent to the kernel development" [41]. A 2014 study of open source in general estimated that about half of the work is paid [42]. The kernel sits well above that average.

By commits, four out of five come from someone on somebody's payroll. By the power to accept, it is more than 95%. The volunteer exists, can be measured and lives at the edges: 4.5% of the code in 7.2 and 1.6% of the keys in 6.19.

Made to order: subsystems of corporate origin

The 1991 post said the system "is NOT protable (uses 386 task switching etc)" and would probably never support anything but AT disks [1]. In 7.2, the kernel has 37.7 million lines of source code in C, Rust and assembly; 69.0% of them sit in drivers/, and the arch/ directory has 21 subdirectories [37]. I counted the .c, .h, .rs and .S files of the v7.2 tag straight from the Git objects. Each of those directories has someone paying for it. This section walks through the subsystems that most changed what Linux is, always following the same script: a company's problem, the mechanism that solved it, the alternatives that lost and the path to mainline.

cgroups and namespaces: the foundation of containers

On September 14, 2006, Rohit Seth sent LKML the introduction to a patch called containers. The rationale came from the data center: "Commodity HW is becoming more powerful", and running different workloads on the same machine required "a notion of limits for each workload in Linux kernel" [43]. Seth was writing from a Google address, and the work passed to Paul Menage, who, "like Rohit, posts from a google.com address" [44]. Years later, Google's paper on Borg, the company's internal orchestrator, would say that "all Borg tasks run inside a Linux cgroup-based resource container" [45].

At the 2007 Ottawa Linux Symposium, Menage, with Balbir Singh and Srivatsa Vaddagiri of IBM's Linux Technology Center, presented a generic framework built on the existing cpusets [46]. The design is deliberately cheap: each task gets a single pointer to a shared css_group, and "the space overhead is one pointer per task, and the time overhead is one reference count operation per fork()/exit()". Of the alternatives of the time, ResGroups lost because "the additional overheads that it introduces are unnecessary" [46]. Menage's commit went into 2.6.24, released in January 2008 [47].

The first version allowed several independent hierarchies. It did not work: the version 2 documentation, written by Tejun Heo, says that flexibility "wasn't useful in practice" [48]. The unified hierarchy came in as experimental in 3.16 [49] and was considered stable in 4.5 [50]. The interface is still a filesystem [48]:

mkdir /sys/fs/cgroup/job
echo "+memory +cpu" > /sys/fs/cgroup/cgroup.subtree_control
echo 512M > /sys/fs/cgroup/job/memory.max
echo $$ > /sys/fs/cgroup/job/cgroup.procs

In 2018, Facebook added PSI, which measures how long tasks spend stalled waiting for CPU, memory or I/O. The feature, "developed by Facebook engineer Johannes Weiner" [51], had already been "used within Facebook for some time" when it was proposed [52], and went into 4.20 [53].

Cgroups limit how much a process uses. Namespaces limit what it sees. The idea comes from research Unix: "The Use of Name Spaces in Plan 9", by Rob Pike, Ken Thompson and colleagues at Bell Labs [54]. Eric Biederman cited the inspiration at OLS 2006 and took aim at the alternative of the time: "Hypervisor solutions like Xen are nice but they impose a performance penalty" [55]. Namespaces arrived piece by piece over almost eighteen years: mount in 2.4.19, UTS and IPC in 2.6.19, PID in 2.6.24, network roughly complete by 2.6.29 and user in 3.8 [56], cgroup in 4.6 [57] and time in 5.6 [58]. The authors came from everywhere: UTS came from a @us.ibm.com address [59]; PID was "developed by the OpenVZ team with the help of IBM" [60]; the cgroup namespace was written at Google; the time namespace, in a partnership between OpenVZ and Arista [57], [58]. A Brazilian was in the middle of this work: Glauber Costa's commits extending memory accounting in cgroups came from @parallels.com in 2013 [37]. The containers that became an industry standard are, inside the kernel, these two pieces combined.

KVM: from Qumranet to Red Hat

On October 19, 2006, Avi Kivity presented LKML with a driver called KVM. The idea was to use the virtualization extensions Intel and AMD had just added to their processors and leave everything else to Linux: "Each virtual machine is a process on the host; a virtual cpu is a thread in that process. kill(1), nice(1), top(1) work as expected." The driver adds "a third execution mode", guest mode, alongside kernel and user modes; any access to an I/O device is intercepted and handed back to user space, where a slightly modified QEMU emulates the hardware [61]. Linux's scheduler, memory management and process tools apply to virtual machines with no new code for that.

The 2007 OLS paper, signed by four Qumranet engineers and one from IBM, describes the rest: a table of function pointers, kvm_arch_ops, separates Intel from AMD; shadow page tables keep guest memory coherent; a dirty page log allows a running virtual machine to be migrated; and "In kvm, I/O virtualization is performed by userspace" [62]. For the user, everything is an ioctl on /dev/kvm [63]:

int kvm  = open("/dev/kvm", O_RDWR);
int vm   = ioctl(kvm, KVM_CREATE_VM, 0);
int vcpu = ioctl(vm, KVM_CREATE_VCPU, 0);
struct kvm_run *run = mmap(NULL, ioctl(kvm, KVM_GET_VCPU_MMAP_SIZE, 0),
                           PROT_READ | PROT_WRITE, MAP_SHARED, vcpu, 0);
for (;;) {
        ioctl(vcpu, KVM_RUN, 0);          /* run the guest until it exits */
        if (run->exit_reason == KVM_EXIT_IO || run->exit_reason == KVM_EXIT_MMIO)
                emulate_device(run);      /* user space plays the hardware */
}

From the first email to a stable release took less than four months: the commit, from avi@qumranet.com, went into 2.6.20, released on February 4, 2007 [64]. The competitor, Xen, only had dom0 support accepted in 3.0, in 2011 [65]. In September 2008, Red Hat paid "approximately $107 million in cash" for Qumranet [66]. In 3.0, MAINTAINERS listed two KVM maintainers, Avi Kivity and Marcelo Tosatti, the same man from the 2.4 series, both with @redhat.com addresses [67]. Glauber Costa wrote part of kvmclock, KVM's paravirtualized clock, also from @redhat.com [37].

Today KVM underpins the largest clouds. AWS says the Nitro hypervisor "is built on core Linux Kernel-based Virtual Machine (KVM) technology" [68]. Google Cloud runs KVM with its own virtual machine monitor, because "Google does not use QEMU" [69]. In 7.2, KVM is maintained by Paolo Bonzini, with a Red Hat address, and KVM for x86 also by Sean Christopherson, from Google; both entries are Supported [70].

eBPF and XDP: programs inside the kernel

The original BPF dates from 1992, by Steven McCanne and Van Jacobson at Lawrence Berkeley Laboratory: a register-based virtual machine for filtering packets inside the kernel, "10 to 150 times faster than Sun's NIT" [71]. For two decades, it served tcpdump and little else.

In March 2014, Alexei Starovoitov, from @plumgrid.com, rewrote the internal interpreter with an instruction set "designed to be JITed with one to one mapping" [72]. It went into 3.15. In September of the same year came the bpf() syscall, with maps, data structures shared between the program in the kernel and user space, which went into 3.18 [73]. There was a competitor, ktap, another virtual machine for tracing. LWN summed up the standoff: "Putting one virtual machine into the kernel for tracing is a hard sell; adding two of them is not really seen as an option by anybody involved" [74]. BPF stayed.

What makes it acceptable to run user code inside the kernel is the verifier. It walks the program as an acyclic graph, rejects loops and tracks the state of every register and stack slot before accepting the load; only then does the JIT translate it to native instructions [75].

In July 2016, Brenden Blanco, also from @plumgrid.com, added XDP, a program type that runs in the network driver before the kernel allocates its structures for the packet [76]. It went into 4.8. The XDP paper at CoNEXT 2018, with authors from Red Hat, Cilium and other companies and universities, measured 24 million packets per second on one core, against 43.5 million for DPDK, which takes the network card away from the kernel [75]. The trade-off is deliberate: less raw speed, but the packet stays in the kernel, with the firewall, routing and the rest.

Starovoitov moved to Facebook, from where he committed between 2016 and 2018 [37]. In 2019, the company had "about 40 BPF programs running on each server, with another 100 that are demand loaded" [77]. In 2020, KP Singh, from Google, brought BPF to the kernel's security hooks in 5.7 [78], despite Casey Schaufler's objection: "This effectively exposes the LSM hooks as external APIs. It would mean that we can't change or delete them" [79]. In October 2024, the instruction set became an IETF standard, RFC 9669, which notes that eBPF "is no longer an acronym for anything" [80].

io_uring: Meta writes it, Google switches it off

Linux already had an asynchronous I/O interface, AIO, but it served poorly anyone using the page cache: "buffered I/O has always been a bit of a sore spot for Linux AIO" [81]. In January 2019, Jens Axboe, maintainer of the block layer, proposed another way [82]. Axboe had worked at SUSE, Oracle and Fusion-io and committed from @fb.com between 2014 and 2017 [37]; his public GitHub profile still lists Facebook as his company [83].

The mechanism fits in one sentence of the commit: "The submission queue (SQ) and completion queue (CQ) rings are shared between the application and the kernel. This eliminates the need to copy data back and forth to submit and complete IO" [82]. The application writes requests into an array of io_uring_sqe, puts their indices in the submission ring and calls io_uring_enter() once for the whole batch; results show up as io_uring_cqe entries in the completion ring, which it reads without a system call.

 application                               kernel
 -----------                               ------
 fills SQEs in the array
 writes indices to the SQ ring ------->    consumes the SQ ring, runs the I/O
 io_uring_enter(fd, n, ...) ---------->    (one syscall for n requests)
 reads CQEs from the CQ ring <---------    writes one CQE per completed request

 SQ ring, CQ ring and the SQE array live in shared memory (mmap)

Each completion is a 16-byte structure, which doubles with the IORING_SETUP_CQE32 option [37]:

struct io_uring_cqe {
	__u64	user_data;	/* sqe->user_data value passed back */
	__s32	res;		/* result code for this event */
	__u32	flags;
	__u64	big_cqe[];	/* only present with IORING_SETUP_CQE32 */
};

It went into 5.1, in May 2019. The bill came later. In June 2023, Google reported that in kCTF, its reward program for kernel exploits, "60% of the submissions exploited the io_uring component of the Linux kernel (we paid out around 1 million USD for io_uring alone)". The company disabled io_uring on ChromeOS, blocked app access on Android and wrote: "It is disabled on production Google servers" [84]. Two months later, a Google engineer, Matteo Rizzo, sent the io_uring_disabled sysctl, which went into 6.6 [85]. A subsystem written by someone working at one company got its off switch written by another.

Btrfs and XFS: filesystems with a badge

On June 12, 2007, Chris Mason announced a new filesystem: "After the last FS summit, I started working on a new filesystem that maintains checksums of all file data and metadata." The code was "a sparsely commented 10,547 lines" [86]. Btrfs organizes everything in copy-on-write B-trees: nothing is overwritten in place, and a snapshot is a new root that shares blocks with the previous one [87]. It went into 2.6.29, in March 2009 [88].

The history of Btrfs follows Mason's badges: 972 of his commits came from @oracle.com, 44 from @fusionio.com and, starting in December 2013, 148 from @fb.com and 34 from @meta.com [37]. Josef Bacik took a similar path, from Red Hat to Fusion-io and Facebook [37]. At Facebook, Btrfs became the root of the internal containers: "Containers in this system use Btrfs for the root filesystem" [89]. The distributions picked sides. Red Hat deprecated Btrfs in RHEL 7.4 and warned that it "will be removed in a future major release" [90]. Fedora, with Bacik among the authors of the proposal, made Btrfs the default in Fedora 33 [91]. In 7.2, the two Btrfs maintainers are Mason, from @fb.com, and David Sterba, from @suse.com [70].

XFS came from another era. Silicon Graphics described it at USENIX in 1996: independent allocation groups, B+ trees for free space and delayed allocation, in which the system "simply reserves blocks in the file system for the data buffered in memory" [92]. The code entered Linux in 2.5.36, in September 2002, and Linus's announcement summed it up: "Big patch, most of it due to the XFS merge" [93]. Years later, Red Hat would describe it as a filesystem "originally designed at Silicon Graphics, Inc." and make it "the default file system for Red Hat Enterprise Linux 7" [94]. Online checking of a mounted filesystem, scrub, began in 2017 with Darrick Wong, from @oracle.com [95].

Schedulers: O(1), CFS, EEVDF and sched_ext

The scheduler is the most contested code in the kernel, and the contest tells the thesis better than any table.

In January 2002, Ingo Molnar announced "a pretty radical rewrite of the Linux scheduler", the O(1) scheduler, with the patches hosted at redhat.com/~mingo [96]. In March 2007, Con Kolivas proposed RSDL, a scheduler without interactivity heuristics and with complete fairness [97]. A month later, Molnar answered with the Completely Fair Scheduler and was explicit: "i'd like to give credit to Con Kolivas for the general approach here: he has proven via RSDL/SD that 'fair scheduling' is possible and that it results in better desktop scheduling". CFS replaced the priority queues with "a time-ordered rbtree to build a 'timeline' of future task execution" [98] and went into 2.6.23 [99]. The idea that won was Kolivas's. The code that went in was the Red Hat engineer's.

Sixteen years later, Peter Zijlstra replaced the core of CFS with EEVDF, an algorithm published in 1995 by Ion Stoica and Hussein Abdel-Wahab of Old Dominion University [100]. The promise was to delete "a whole [bunch] of icky heuristics code" in favor of a well-defined policy [101]. Each task has a lag, the difference between the CPU time it deserves and what it got; EEVDF "picks tasks with lag greater or equal to zero and calculates a virtual deadline (VD) for each, selecting the task with the earliest VD to execute next" [102]. It went into 6.6, in a commit signed "Peter Zijlstra (Intel)" [103].

In 2023, Tejun Heo proposed the opposite of a better scheduler: letting everyone write their own, in BPF. sched_ext, written with David Vernet, Josh Don and Barret Rhoden [104], heard from the scheduler maintainer: "I hate all of this. Linus NAK'ed loadable schedulers a number of times in the past and this is just that again -- with the extra downside of the whole BPF thing on top" [104]. In June 2024, Linus overrode the maintainer: "I honestly see no reason to delay this any more" [105]. The commit has Vernet as co-author, from @meta.com, and three Acked-by tags from @google.com addresses [106]; Heo's GitHub profile lists Facebook [107]. It went into 6.12. A BPF scheduler is a table of functions the kernel calls at the right moments, and any error drops it back to the default scheduler [108]:

/* kernel/sched/ext/internal.h, Linux 7.2 (excerpt) */
struct sched_ext_ops {
	s32 (*select_cpu)(struct task_struct *p, s32 prev_cpu, u64 wake_flags);
	void (*enqueue)(struct task_struct *p, u64 enq_flags);
	void (*dequeue)(struct task_struct *p, u64 deq_flags);
	void (*dispatch)(s32 cpu, struct task_struct *prev);
	void (*running)(struct task_struct *p);
	void (*stopping)(struct task_struct *p, bool runnable);
	s32 (*init_task)(struct task_struct *p, struct scx_init_task_args *args);
	/* ... */
	u32 timeout_ms;
	char name[SCX_OPS_NAME_LEN];
};

Both sides of the debate were company employees: the maintainer who signs as Intel and the authors tied to Meta and Google. The referee was Linus, who appears as a "Fellow" on the Linux Foundation's payroll [109].

Drivers: the kernel is, above all, hardware support

On July 5, 2015, Linus opened 4.2-rc1 warning that it looked like "the biggest rc we've ever had, with over a million lines added". The explanation followed: "just those register descriptor headers alone are about 41% of the entire patch". The rest of AMD's new driver, amdgpu, was another 8%, which left the kernel "in the somewhat odd situation where a single driver is about half of the whole rc1 in number of lines" [110]. The core amdgpu commit is by Alex Deucher, from @amd.com [111].

Eleven years later, I counted the drivers/gpu/drm/amd tree in 7.2: 6,343,652 lines, or 16.8% of all the kernel's source code. The register headers in include/asic_reg/ alone add up to 4,977,963 lines, 13.2% of the kernel [37]. The tree of a single driver has more lines than arch/, fs/, net/ and kernel/ combined, which come to 6.01 million [37]. Most of it describes the registers of one company's chips, and its two maintainers, in a Supported entry, have @amd.com addresses [70].

Intel has two graphics drivers. i915 has 418,774 lines, and xe, for GPUs from Tiger Lake onward, 139,555 [37]. xe went into 6.8, and its first commit declares 16 co-developers: 12 with Intel addresses, one from Red Hat and one from Collabora [112].

NVIDIA was the counterexample for a long time. nouveau, "a reverse-engineered driver for Nvidia graphic cards", entered staging in 2.6.33, in 2010 [113]. In May 2022, NVIDIA released its own kernel modules under a dual GPL and MIT license, but outside the main tree [114]. In 2025, nova-core went into 6.15, written in Rust and "intended to serve as the successor of Nouveau for all GSP-based GPUs" [115]. Its author, Danilo Krummrich, committed from @redhat.com from 2022 to 2024 [37], and in 7.2 shares maintenance with Alexandre Courbot, from @nvidia.com [70].

In networking, the pattern repeats. mlx5, Mellanox's driver for Connect-IB adapters, went into 3.11, in 2013, written by Eli Cohen, from @mellanox.com [116]. In April 2020, NVIDIA completed its purchase of Mellanox for US$7 billion [117]. The four mlx5 maintainers in 7.2 have @nvidia.com addresses [70].

Architectures: one sponsor per processor

IBM arrived early. The mainframe port, s390, showed up in the 2.2.14 patch, published in January 2000, with headers reading "Copyright (C) 1999 IBM Deutschland Entwicklung GmbH, IBM Corporation" [118]. ppc64, for POWER servers, reached the development series in 2.5.5, in February 2002, also with IBM-copyrighted code [119]. In 7.2, the s390 and PowerPC maintainers all have @linux.ibm.com addresses, and both entries are Supported [70].

ARM was the messy case. In 2010, LWN counted "nearly 70 different sub-architectures" in the ARM directory, one per chip or SoC, and reported the founding of Linaro by Arm, Freescale, IBM, Samsung, ST-Ericsson and Texas Instruments, with a budget of "tens of millions of dollars, much of which will pay for 80 employees" [120]. In March 2011, Linus lost patience: "Gaah. Guys, this whole ARM thing is a f*cking pain in the ass" [121]. 64-bit support came from Arm itself, in a "36-part patch set" by Catalin Marinas [122], with the first commit from the @arm.com addresses of Marinas and Will Deacon [123]. It went into 3.7, in December 2012. Support for Qualcomm's MSM family went into 2.6.25 at the hands of a Google engineer, Brian Swetland [124]; by 2.6.35, the platform's three maintainers had @codeaurora.org addresses [125].

RISC-V followed the same script. The first commit is by Palmer Dabbelt, from July 2017 [126], and the 4.15 MAINTAINERS file lists him, with Albert Ou, at @sifive.com addresses, in an entry marked Supported, the status the file itself defines as "Someone is actually paid to look after this" [127].

PREEMPT_RT: twenty years out of tree

On October 13, 2004, Ingo Molnar published what he called "the first correct conversion of the Linux kernel to a fully preemptible (fully mutex-based) preemption model", once again hosted at redhat.com/~mingo [128]. The idea is easy to state and hard to do: in a real-time kernel, "spinlock_t is mapped to a separate implementation based on rt_mutex", a lock that sleeps and inherits priority, and interrupt handlers run in threads. Only raw_spinlock_t keeps spinning, "a strict spinning lock implementation in all kernels, including PREEMPT_RT kernels" [129].

It took twenty years. The patch lived outside the main tree, and the pieces went in gradually: threaded interrupts in 2.6.30, by Thomas Gleixner, from @linutronix.de [130], and the CONFIG_PREEMPT_RT symbol in 5.3 [131]. In 2015, the Linux Foundation set up a project to fund the work, with Google as founding Platinum member and National Instruments, OSADL and Texas Instruments as Gold members; Gleixner, who had maintained the branch "for more than a decade", became a Linux Foundation Fellow [132]. In 2022, Intel bought Linutronix, which Intel itself described as "the architect of PREEMPT_RT (Real Time)" [133]. The last obstacle was printk, rewritten with consoles that do not depend on the global lock [134]; the commit that enabled x86 records that, "with the recent printk changes, the last known road block has been addressed" [135]. In September 2024, Gleixner's pull request said: "After twenty years of development we finally reached the point to enable PREEMPT_RT support in the mainline kernel" [136]. The rationale of the x86 commit opens with a single sentence: "It is really time." [135]. It went into 6.12. For 2025 as a whole, Linutronix appears among the 20 employers with the most kernel commits, with 1,149 [38].

Rust for Linux: an experiment with sponsorship

In April 2021, Miguel Ojeda sent the proposal for Rust in the kernel. Linus complained about specific patches but said: "on the whole I don't hate it" [137]. That same April, the Internet Security Research Group, the nonprofit behind Let's Encrypt, gave Ojeda a one-year full-time contract, "made possible through financial support from Google" [138]. Support went into 6.1, in December 2022, in a pull request that thanked 173 people and stated: "Miguel is the primary maintainer" [139].

Companies followed. Wedson Almeida Filho, one of the first maintainers, committed from @google.com and later from @microsoft.com [37]. Android's Binder driver, rewritten in Rust by Alice Ryhl, from @google.com, went into 6.18. The commit opens with "We're generally not proponents of rewrites (nasty uncomfortable things that make you late for dinner!)" and explains why: Binder in C, at about 6,000 lines, "combines/nests 13 different locks, 7 reference counters, and atomic variables" [140]. nova-core, from Red Hat with NVIDIA, has been Rust since its first commit [115].

In December 2025, at the Maintainers Summit, the experiment was declared over. LWN recorded that Rust code had grown "by a factor of five over the last year" and that devices running Android 16 with kernel 6.12 already shipped a Rust module, ashmem: "So there are millions of real devices running kernels with Rust code now" [141]. Ojeda's commit removing the experimental label, in 7.0, ends by asking for exactly what this article describes: "I hope this signals commitment from the kernel to companies and other entities to invest more into it, e.g. into giving time to their kernel developers to train themselves in Rust" [142]. In 7.2, Rust is still small: 473 .rs files, 182,584 lines, 0.5% of the source code [37]. The political fight around it is left for the section on tensions.

A patch for gaming on Linux

The pattern also holds at small scale. Windows games wait on several events at once with WaitForMultipleObjects; Linux's futex() waited on one address per call. On July 30, 2019, Gabriel Krisman Bertazi, from @collabora.com, sent FUTEX_WAIT_MULTIPLE, with two sign-offs from @valvesoftware.com. With it, in Proton, "using futexes in our Wine use case reduced the CPU utilization by 4% for the game Beat Saber and by 1.5% for the game Shadow of Tomb Raider" [143]. The interface that went in was a different one, a dedicated syscall written by André Almeida, also from @collabora.com [144]: futex_waitv() arrived in 5.16, in January 2022, with its use case stated, emulating WaitForMultipleObjects, "which allows software like Proton to improve the performance of Windows Games" [145]. Two Brazilians, an open source consultancy and a game company: the path of one patch to mainline.

Subsystem	Who started it (employer at the time)	Mainline entry
cgroups	Rohit Seth and Paul Menage (Google)	2.6.24, Jan 2008
namespaces	IBM, OpenVZ, Google, Arista and others	from 2.4.19 (2002) to 5.6 (2020)
KVM	Avi Kivity (Qumranet, later Red Hat)	2.6.20, Feb 2007
eBPF	Alexei Starovoitov (PLUMgrid)	3.15 and 3.18, 2014
XDP	Brenden Blanco (PLUMgrid)	4.8, Oct 2016
io_uring	Jens Axboe (see text)	5.1, May 2019
Btrfs	Chris Mason (Oracle)	2.6.29, Mar 2009
XFS	Silicon Graphics	2.5.36, Sep 2002
CFS	Ingo Molnar (Red Hat)	2.6.23, Oct 2007
EEVDF	Peter Zijlstra (Intel)	6.6, Oct 2023
sched_ext	Tejun Heo and David Vernet (Meta), with Google	6.12, Nov 2024
amdgpu	Alex Deucher (AMD)	4.2, Aug 2015
xe	Intel, with Red Hat and Collabora	6.8, Mar 2024
mlx5	Eli Cohen (Mellanox)	3.11, Sep 2013
arm64	Catalin Marinas and Will Deacon (Arm)	3.7, Dec 2012
RISC-V	Palmer Dabbelt and Albert Ou (SiFive)	4.15, Jan 2018
s390	IBM Germany	2.2.14, Jan 2000
PREEMPT_RT	Ingo Molnar (Red Hat) and Thomas Gleixner (Linutronix)	6.12, Nov 2024
Rust	Miguel Ojeda (ISRG contract funded by Google)	6.1, Dec 2022
futex_waitv	André Almeida (Collabora), for Valve	5.16, Jan 2022

Almost none of these subsystems were born from someone solving a personal problem on a weekend. They were born from a data center that needed to isolate workloads, a startup that wanted to sell virtualization, another that wanted to program the packet path, a manufacturer that needed its chip to work. Mainline is where those needs meet and start being maintained together.

Who decides

A patch takes two or three months to get from a maintainer's inbox into a release. The path is public and documented, and nearly every hand it passes through is on someone's payroll.

The documentation describes the rhythm. A new release comes out "every two or three months" and carries "about 13,000 changesets". First comes a merge window that "lasts for approximately two weeks", in which Linus pulls what the maintainers have accumulated. Then an -rc "about once a week", until somewhere between -rc6 and -rc9 [146]. 7.2 took nine weeks, from June 14 to August 16, 2026 [37]. Before reaching Linus, code goes through a subsystem tree and through linux-next, "maintained by Mark Brown", which is a snapshot of what mainline should become in the next merge window [146].

 author --email--> subsystem list
                     (public review: Reviewed-by, Acked-by, Tested-by)
                            |
                            v
                   maintainer's tree  (+ Signed-off-by from whoever applied it)
                            |
                            v
                       linux-next  (integration of the subsystem trees)
                            |   merge window: about two weeks
                            v
                  mainline (Linus) --> -rc1 ... -rc7 --> release 7.x
                            |
                            v
          stable and LTS (Greg Kroah-Hartman, Sasha Levin):
          only fixes already in mainline, up to 100 lines

After the release, fixes flow down to the stable and long-term trees. The rule is strict: the patch must "already exist in Linux mainline (upstream)" and "cannot be bigger than 100 lines, with context" [147]. How long a long-term version lives is, literally, a market decision. Each one "usually starts with only a 2-year projected EOL that can be extended further if there is enough interest from the industry at large to help support it for a longer period of time" [148]. In October 2026, there are six LTS series, from 5.10 to 6.18, with projected end of life between December 2026 and December 2028 [148]. Since February 13, 2024, the kernel has also issued its own CVEs [149], with the stated policy to "assign CVE numbers to any bugfix that they identify" [150]. It went from nothing to "number 1 in 2025" among CVE authorities by volume [151], and the Linux Foundation counted 13 CVEs a day [152].

Who owns each piece is recorded in a text file. The 7.2 MAINTAINERS file has 3,255 entries, each with maintainers (M:), reviewers (R:), mailing list (L:), tree (T:) and status (S:) [70]. The status is the most candid data point in the kernel. Supported means "Someone is actually paid to look after this"; Maintained, "Someone actually looks after it". In 7.2, 795 entries (24.4%) declare themselves paid, 2,205 (67.7%) declare themselves maintained and 139 (4.3%) are orphaned [70]. The number is self-declared and understates payment. CGROUP, maintained by Tejun Heo, Johannes Weiner and a SUSE engineer, is listed as Maintained; so is Btrfs, with Chris Mason from @fb.com and David Sterba from @suse.com; so is mlx5, with four maintainers from @nvidia.com [70].

Of the 1,998 maintainer addresses, 287 are gmail.com and 191 kernel.org, and neither says anything about the employer. Then come Intel (86, counting linux.intel.com), AMD (56), Red Hat (46), IBM (45), Broadcom (41), NVIDIA (35) and NXP (35) [70]. The domain misleads in both directions. Mauro Carvalho Chehab appears in MAINTAINERS as mchehab@kernel.org, but 2,310 of his commits came from mchehab+huawei@kernel.org [37]. Peter Zijlstra uses a personal domain and signs as "Peter Zijlstra (Intel)" [103]. To know who pays whom, you have to piece the evidence together:

Area	Maintainer	Affiliation, with the most recent evidence found
Everything else ("THE REST")	Linus Torvalds	Linux Foundation: "Fellow" on the 2024 Form 990 [109]
stable and LTS	Greg Kroah-Hartman	Linux Foundation: "Fellow" on the TAB page [153]
scheduler	Peter Zijlstra	Intel: signs as "Peter Zijlstra (Intel)" [103]
x86	Borislav Petkov	AMD: signs as "Borislav Petkov (AMD)" [37]
x86 and scheduler	Ingo Molnar	`@redhat.com` address in MAINTAINERS [70]
networking	Eric Dumazet	`@google.com` address [70]
networking	Jakub Kicinski	Facebook, in the LPC 2025 program [154]
networking	Paolo Abeni	`@redhat.com` address [70]
BPF	Daniel Borkmann	"Isovalent at Cisco", in the OSS NA 2025 program [155]
KVM	Paolo Bonzini	`@redhat.com` address [70]
KVM for x86	Sean Christopherson	`@google.com` address [70]
kernel security	Kees Cook	Google, on the TAB page [153]
AMDGPU	Alex Deucher	`@amd.com` address [70]
PREEMPT_RT	Sebastian Andrzej Siewior	`@linutronix.de` address, an Intel company [70], [133]

Succession follows the same pattern. In April 2026, Andrew Morton, whose MAINTAINERS address is @linux-foundation.org [70], announced he would begin stepping away from maintaining memory management, a role he had held "since before memory management was even seen as its own subsystem". The subsystem's integration tree "will be picked up by David Hildenbrand" [156], whom the TAB page lists as an Arm employee [153].

Above all of this sits the Linux Foundation, which pays Linus himself. On the 2024 Form 990, he appears as "Fellow", with US$524,349 in the compensation column and US$1,089,627 in the "Other" column. Ten foundation executives come before him in the main column, starting with the executive director, Jim Zemlin, at US$952,166 and US$451,018 [109]. The 2025 annual report forecast revenue of US$311.3 million, 42.8% of it from "Membership & Donations", and expenses of US$284.8 million. The "Linux Kernel Project" line came to US$8.4 million, 2.95% of spending. That is less than "Training", at US$21.6 million, and "Event Services", at US$16.8 million. The largest share, US$181.9 million, went to "Project Support", the other projects the foundation hosts [152]. In 2024, the kernel had received US$6.8 million, 2.27% [157]. The annual report figures are forecasts and do not match the Form 990, which recorded US$220.7 million in revenue for 2024 [109]. By either count, today's Linux Foundation is a foundation of many projects that carries the name of one.

The formal bridge between the community and the foundation is the Technical Advisory Board. It "exists to provide advice from the kernel community to the Linux Foundation and holds a seat on the LF's board of directors" [158], and the foundation's bylaws reserve one of the at-large director seats for the TAB [159]. In the December 2025 election, there were 1,054 registered voters, and 265 voted [160]. Of the ten members listed today, two are from Google, two from Intel, one from Arm and one from Inria; two are the foundation's own Fellows, one lists Qube-RT and Miguel Ojeda lists no company [153]. LWN describes the TAB as "a sort of governing board in a community that has no governing boards" [161].

Brazil on the payroll

The Brazilians who have appeared in my posts about the kernel also wear a badge. The email domains in their commits tell each one's career [37]:

Developer	Role in the 7.2 MAINTAINERS file	Domains in commits (years)
Marcelo Tosatti	(2.4 maintainer in 2001; KVM in 2011)	`conectiva.com.br` on LKML in 2001; `redhat.com` (2007–2024)
Arnaldo Carvalho de Melo	Performance Events	`mandriva.com` (2005–2006); `redhat.com` (2007–2026), 4,392 of 4,726 commits
Mauro Carvalho Chehab	Media (V4L/DVB) and HiSilicon drivers	`redhat.com` (2007–2013); `samsung.com` and `osg.samsung.com` (2013–2018); `mchehab+huawei@kernel.org` (2,310 commits)
Glauber Costa	(kvmclock; memory in cgroups)	`redhat.com` (2008–2011); `parallels.com` (2011–2013)
Lucas De Marchi	(co-developer of the xe driver)	`profusion.mobi` (2011–2013); `intel.com` (2014–2025, 871 commits); `nvidia.com` (2026)
Gabriel Krisman Bertazi	Unicode	`linux.vnet.ibm.com` (2015–2016); Collabora (2016–2024); `suse.de` (2022–2026)
André Almeida	Futex (reviewer)	`collabora.com` (2019–2022); `igalia.com` (2022–2026)
Luiz Augusto von Dentz	Bluetooth	`nokia.com` (2010–2011); `intel.com` (2011–2026, 503 commits)
Henrique de Moraes Holschuh	ThinkPad ACPI	`hmh.eng.br`, his own domain (2006–2021, 342 commits)

The sources are the kernel's git log, for the domains, and the 7.2 and 3.0 MAINTAINERS files, for the roles [37], [70], [67]. Tosatti's 2001 email is on LKML [7]. The LKML bar is open to anyone, and they cleared it. But they cleared it, in almost every case, with someone paying for the hours. The exception in the table, Henrique de Moraes Holschuh, maintained a driver for fifteen years from his own domain, which is exactly the kind of contribution that the 4.5% "(None)" measures.

The process is open: anyone can send a patch, and the rules apply to everyone. But who applies it, who integrates it, who decides how long a version lives and who pays the final referee is, almost always, someone with a badge.

Why competitors share the same code

In a post about licenses, I wrote that the GPL is legalism and BSD is trust: one forces you to give back, the other expects collaboration to appear on its own. Looking closely at the kernel, that sentence needs a correction. What makes a company give code back is not only the license. It is the cost of not giving it back.

Linux promises no stability to anyone who stays outside the tree. Greg Kroah-Hartman's document on the subject opens by saying that Linux "does not have a binary kernel interface, nor does it have a stable kernel interface". In exchange, it offers a deal: "If your driver is in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change in the first place". The first advantage it lists is economic: "The quality of the driver will rise as the maintenance costs (to the original developer) will decrease" [162]. Whoever stays outside pays the rebase on every release, and one comes out "every nine or ten weeks" [39]. Whoever goes in splits the bill with everyone, competitors included.

Google measured that bill from the inside. Prodkernel, the kernel on the company's servers, "consists of around 9000 patches on top of an older upstream Linux kernel", and rebasing those patches onto a newer version, done every two years or so, is "extremely costly". Project Icebreaker was created "to provide a near-mainline kernel for development and testing within Google" [163]. Facebook got there earlier. In 2015, the company reported that its internal 4.0 branch had 101 commits from 12 engineers, while mainline had received 238 commits from nine of them: "This is our upstream-first philosophy at work" [164]. At a conference in 2016, one of the company's engineers put it bluntly: "Running old kernels with internal-only patches is painful" [165]. AWS followed the distributions' model: Amazon Linux 2023 ships one long-term kernel a year, "based on the upstream Linux community's annual LTS kernel" [166].

Android shows the cost of doing the opposite. In 2010, Greg Kroah-Hartman recounted that he had put the Android drivers in staging and that Google had promised to help get them into mainline shape, "but they didn't"; he had to remove them [167]. The sticking point was wakelocks, the power-saving mechanism Android spread throughout its drivers. The code returned to staging at the end of 2011 [168], and autosleep, a version of the mechanism acceptable for mainline, went into 3.5, in 2012 [169], [170]. Even so, in 2017 devices still shipped kernels carrying "large amounts (often millions of lines) of out-of-tree code" [171].

Google changed strategy. In 2018, the Android Common Kernel needed "only about 30 patches", about 6,500 lines, to boot [172]; in 2020, it still carried 485 patches on top of 5.9-rc [173]. Android's documentation explains why: before the Generic Kernel Image, customization by chip and device makers "could result in as much as 50% of kernel code being out-of-tree code". Since Android 12, devices with kernel 5.10 or newer "must ship with the GKI kernel" [174], and the guidance for developers is: "Upstream development is strongly encouraged" [175].

Microsoft is the most symbolic case. On July 20, 2009, the company released "20,000 lines of device driver code to the Linux community under the popular General Public Licence v2", the Hyper-V drivers [176]. Greg Kroah-Hartman announced on LKML that they would go into drivers/staging/ with "a whole bunch of cleanups" [177]. The cleanup was so extensive that, in 3.0, in 2011, Microsoft accounted for 4.0% of the changes, and LWN remarked: "one assumes that presence will not be permanent: even the HV drivers can only need so much cleaning up" [33]. The presence stayed. In November 2016, Microsoft became a Platinum member of the Linux Foundation [178]. Today it maintains the WSL2 kernel in public [179] and, in 6.19, accounted for 3.3% of maintainer sign-offs [40].

And BSD? FreeBSD proves the point in reverse. Sony lists the "FreeBSD Kernel" among the components of the PlayStation 4 [180], and Apple's XNU is "a hybrid kernel combining the Mach kernel developed at Carnegie Mellon University with components from FreeBSD", published by the company under a GitHub organization called apple-oss-distributions [181]. The license allows closing the code, and many companies do. But Netflix, which runs FreeBSD across its video delivery network, tracks the development branch: "a commit to the upstream FreeBSD development branch will usually be fully deployed across Netflix's CDN within 4-12 weeks" [182]. It does so for the same reason Google and Facebook do on Linux: keeping a fork far from upstream is expensive. The GPL requires publishing the code you distribute, but it does not require anyone to send patches to mainline. What takes the patch there is the math.

The counterexample comes from Solaris. An Oracle employee summed up, in 2010, what happened after the Sun acquisition: Oracle "stopped publishing binaries for recent OpenSolaris releases and stopped talking to the community at the same time". On August 3, 2010, Nexenta announced Illumos to carry the system forward outside Oracle [183]. A project with a single owner dies when the owner decides it does, and the conclusion of this article comes back to that point.

The economics literature has a name for all of this. Lerner and Tirole, in 2002, explained much of individual participation through labor economics, especially the "literature on career concerns" [184]: contributing is a résumé. The Linux Foundation's 2017 report shows the effect in the kernel, where anyone who gets code into mainline finds a job [31]. West and Gallagher described the strategies companies use in open source, among them "pooled R&D/product development" and "selling complements" [185]. That is the kernel's case: Intel, AMD and NVIDIA split the cost of the operating system and compete on the hardware that runs it. Joachim Henkel studied embedded Linux companies and showed that revealing is selective: they publish part of what they develop and protect the rest [186]. In 2024, a Harvard Business School study estimated at US$4.15 billion the cost of rewriting the most widely used open source software and at US$8.8 trillion the value it generates for those who use it, and showed that "96% of the demand-side value is created by only 5% of OSS developers" [187]. The authors acknowledge "financial and administrative support from the Linux Foundation" [187].

Nadia Eghbal, in a 2016 report for the Ford Foundation, treated the kernel as an exception. She wrote that "The Linux Foundation is one of the most successful outliers, due to the fundamental value of the Linux kernel to nearly every corporate entity", and brought a Brazilian data point: a study by UFMG of 133 popular GitHub projects showed that 64% "relied upon just one or two developers to survive" [188]. The kernel escaped that fate because it became infrastructure for those who pay.

Competitors share the same code because not sharing costs more than what hiding gains. The license helps. The math decides.

The robots that test the kernel

I have repeated that, in practice, almost nobody reads the thousands of patches that go into the kernel. The industry's answer was not to hire more readers. It was to put machines to read and run the code all the time, and almost all of them have an owner.

syzkaller, from Google, is "an unsupervised coverage-guided kernel fuzzer", and its repository dates back to October 2015 [189]. syzbot is the robot that runs it nonstop: "syzbot system continuously fuzzes main Linux kernel branches and automatically reports found bugs to kernel mailing lists" [190]. In 2019, Dmitry Vyukov, who commits from @google.com [37], counted about 2,300 bugs found upstream in two years, three a day, and another 2,500 in Android, ChromeOS, stable trees and internal kernels [191]. On October 2, 2026, the syzbot dashboard showed 7,518 upstream bugs fixed and 1,591 still open [192].

Intel runs 0-day, which signs its reports as "kernel test robot". In 2012, it was already testing Linus's tree, linux-next and "more than 180 trees owned by individual kernel maintainers and developers" [193]; the code lives in the lkp-tests repository [194]. In 5.5, LWN counted where Reported-by credits came from: Hulk Robot took 15.7%, syzbot 12.0% and Intel's robot 9.8%, and the conclusion was that "over 1/3 of the bug reports for the kernel (of which 934 were credited in 5.5) are now coming from automated testing systems" [195]. In the 5.5 git log, Hulk Robot's 164 credits come from hulkci@huawei.com, and those of Intel's robot from lkp@intel.com [37].

KernelCI started the other way around. It was "originally started in 2014 as a side project by a few engineers who were doing the testing at home and in their spare time". In October 2019, it became a Linux Foundation project "underwritten by BayLibre, Civil Infrastructure Platform, Collabora, Foundries.io, Google, Microsoft, Red Hat" [196]. Today its member list includes Arm, Google, Linaro, Microsoft, Qualcomm, Red Hat and Texas Instruments [197]. The weekend project became infrastructure with sponsors.

The diagnostic tools inside the kernel have the same origin. KASAN, which detects invalid memory access, went into 4.0 by Andrey Ryabinin, from @samsung.com, and the commit itself cites the family of tools Google created for user space: "We've developed the set of tools, AddressSanitizer (Asan), ThreadSanitizer and MemorySanitizer" [198]. KCSAN, for data races, is by Marco Elver, from @google.com, and went into 5.8 [199], [200]. KMSAN, for uninitialized memory, is by Alexander Potapenko, also from Google, and went into 6.1; in the pull request, Andrew Morton wrote: "KMSAN keeps finding bugs. New ones, as well as the legacy ones" [201], [202]. KUnit, for unit tests, came from Brendan Higgins, from @google.com, in 5.5 [203]. kselftest, the test suite that runs on an installed kernel, was organized starting in 2014 by Shuah Khan, who committed from @samsung.com [37], [204].

Tool	Who pays or started it	Entry	What it does
syzkaller and syzbot	Google	repository since Oct 2015	continuous fuzzing; 7,518 bugs fixed and 1,591 open on 2026-10-02
kernel test robot (0-day)	Intel	more than 180 trees tested in 2012	builds, boots and tests each tree; 9.8% of bug reports in 5.5
Hulk Robot	Huawei (`hulkci@huawei.com`)	active in 5.5	15.7% of bug reports in 5.5
KernelCI	Linux Foundation, with Google, Microsoft, Red Hat and others	2014; at the LF since 2019	tests on real hardware from several labs
KASAN	Andrey Ryabinin (Samsung), building on Google's tools	4.0, Apr 2015	invalid memory access
KCSAN	Marco Elver (Google)	5.8, Aug 2020	data races
KMSAN	Alexander Potapenko (Google)	6.1, Dec 2022	use of uninitialized memory
KUnit	Brendan Higgins (Google)	5.5, Jan 2020	unit tests inside the kernel
kselftest	Shuah Khan (Samsung, at the time)	2014	tests of an installed kernel

Even exploit hunting is paid. kCTF, Google's reward program for kernel bugs, "has rewarded researchers with a total of 1.8 million USD" since it began [84].

Auditing the kernel is possible, and those who audit at scale are on someone's payroll: Google, Intel, Huawei, Samsung. The queue of 1,591 open bugs on syzbot is a reminder of the other half of the sentence I keep repeating: having review, tests and maintainers does not mean flaws do not exist.

What does not add up

A model funded by companies solves a lot and creates other problems. Some show up in the numbers; others, on the mailing lists.

Maintainers at the limit

At the 2023 Maintainers Summit, Ted Ts'o opened a session on burnout by saying, according to LWN, that maintainers end up doing "all of the tasks that nobody else working on a given subsystem wants to take on" [205]. A year earlier, in a session led by Josef Bacik, the line about filesystems had been: "we simply do not have enough people on some of the filesystem teams" [206]. Academic research confirms the picture. A 2017 study concluded that "the distribution of work among maintainers is highly unbalanced" and that adding more than one maintainer to a file yields "only a power of 1/2 increase in productivity" [207]. Companies hire people to write code. Reviewing other people's code falls on a few, and the 41.4% of 7.2 commits without any review tag are the picture of that [37].

The price showed up outside the kernel. In June 2022, the xz maintainer, Lasse Collin, answered demands for more activity: "I haven't lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues but also due to some other things. Recently I've worked off-list a bit with Jia Tan on XZ Utils" [208]. In March 2024, Andres Freund found that "the upstream xz repository and the xz tarballs have been backdoored" and wrote that whoever made the suspicious commits "is either directly involved or there was some quite severe compromise of their system" [209]. One of the commits he pointed to is signed by Jia Tan [210]. The kernel is not xz, but the lesson applies: a tired maintainer is an attack surface.

The GPL and the driver that will not open up

The kernel tries to separate what is public from what is internal through the license. Symbols exported with EXPORT_SYMBOL_GPL() "can only be seen by modules with a MODULE_LICENSE() that specifies a GPLv2 compatible license" [211]. Makers of closed drivers worked around this with open-licensed bridge modules. In 2020, 5.9 closed that door: a module that imports symbols from a proprietary module is now treated as proprietary [212]. The commit carries a comment from Greg Kroah-Hartman: "Ah, the proven-to-be-illegal "GPL Condom" defense :)". In 2023, LWN summed up the rule: such a module "immediately loses its ability to access GPL-only symbols" [213].

NVIDIA was the usual target. In 2012, in a talk at Aalto University, Linus called the company "the single worst company we have ever dealt with", according to Phoronix [214]. In May 2022, NVIDIA opened the kernel modules of its drivers, but outside the main tree [114]. The driver meant to enter mainline, nova-core, was started by a developer committing from Red Hat and today has an NVIDIA engineer among its maintainers [115], [70]. The company came into the kernel when the cost of staying out grew larger than the cost of coming in.

Hardware under embargo

Hardware flaws create a conflict the kernel had no way to avoid: those who find and those who fix are companies competing with each other. In January 2018, in the middle of the Spectre fixes, Linus assessed a series of patches implementing the IBRS interface defined by Intel this way: "As it is, the patches are COMPLETE AND UTTER GARBAGE". In the same exchange, he had asked: "Please, any Intel engineers here - talk to your managers" [215]. The process that came out of it is documented. Flaws like "Meltdown, Spectre, L1TF etc. must be treated differently because they usually affect all Operating Systems", and the kernel team, being "not a formal body", is "unable to enter into any non-disclosure agreements", offering a memorandum of understanding instead [216]. The kernel deals with chipmakers as a community, not as a vendor that signs contracts.

Few companies, a lot of power

Concentration already showed up in the numbers. Since 2017, more than half of the patches pass through the hands of maintainers from five companies [31], [39]. The list of those companies changes: Red Hat had 42.4% of maintainer sign-offs in 2009 and 4.9% in 6.19, and Meta, absent in 2009, leads today [32], [40]. The kernel survived that changing of the guard without visible crisis. The risk is not one company leaving. It is the common interest of those who remain deciding, alone, what is worth maintaining.

Sanctions

On October 18, 2024, a commit by Greg Kroah-Hartman removed several entries from MAINTAINERS "due to various compliance requirements", with the promise that they could come back "if sufficient documentation is provided" [217]. The patch was sent only to a patches list and went into 6.12-rc4 inside a drivers pull request, without fanfare; LWN noted that the developers removed "all appear to be of Russian origin" [218]. Paul Moore asked for the minimum: "can we at least explicitly list those requirements in the commit description?" [219]. The explanation came from James Bottomley: "If your company is on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company on the list, our ability to collaborate with you will be subject to restrictions, and you cannot be in the MAINTAINERS file" [220]. Linus publicly supported the change and said it would not be reverted [218]. A project maintained by companies, under the stewardship of an American foundation, follows American law. That is not a character flaw of the community. It is a consequence of the model.

Rust and the power of the maintainer

The longest dispute of recent years was over Rust, and it was less about the language than about who controls what. In August 2024, Wedson Almeida Filho, who was committing from @microsoft.com [37], left the project: "I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense" [221]. In January 2025, Christoph Hellwig vetoed a Rust DMA abstraction with a Nacked-by, wrote that he did not want another maintainer in the subsystem and told anyone wanting a two-language codebase to do it in their own driver, "instead of spreading this cancer to core subsystems". In the same message, he clarified that the cancer was "a cross-language codebase" [222]. Days later, he added: "I will do everything I can do to stop this. This is NOT because I hate Rust" [223].

Hector Martin, of Asahi Linux, wrote on the list: "If shaming on social media does not work, then tell me what does, because I'm out of ideas." Linus replied: "How about you accept the fact that maybe the problem is you" [224]. Martin left MAINTAINERS saying he no longer had "any faith left in the kernel development process or community management approach" [225]. Two weeks later, Linus wrote to Hellwig that the contested pull request "DID NOT TOUCH THE DMA LAYER AT ALL" and laid down the rule: "if you as a maintainer feel that you control who or what can use your code, YOU ARE WRONG" [226]. The project's official policy allows a middle ground: "Some subsystems may decide they do not want to have Rust code for the time being, typically for bandwidth reasons. This is fine and expected" [227]. An experiment funded by companies ran into the time limits of those who maintain the core. The one who settled it was the referee paid by the foundation.

The filesystem without a boss

bcachefs, the project Kent Overstreet ran "on his own, supported by interested users on Patreon" and that inflated the "(None)" of 6.7 [36], was marked "externally maintained" in 6.17-rc4, in a commit by Linus with a one-line rationale: "As per many long discussion threads, public and private" [228]. In 6.18, the code was removed, because the filesystem was already "a DKMS module" [229]. The commit does not mention money; it mentions long discussions. But the outcome illustrates the thesis in reverse: the most visible case of a large subsystem with no company behind it ended up outside the tree.

AI joins the queue

In 7.2, 1,111 changes, "under 7% of the total", declared help from AI tools with the Assisted-by tag, against 301 in the previous cycle [2]. The syzbot dashboard already has a filter for AI-proposed fixes awaiting review [192]. In my experience, AI has not reduced the work; it has increased it. More patches, from more unknown people, for the same maintainers to review.

Does the kernel have a backdoor?

I have written that the kernel has a backdoor and that NSA code sat in it for years. I went after what is documented. In 2003, an attempted backdoor in wait4() was stopped before it reached the main tree, as the history section showed [22]. In 2021, researchers at the University of Minnesota sent deliberately flawed patches to study review; the TAB re-examined 435 commits from the university, and "These 39 commits are going to be reverted" [230]. And the NSA? SELinux was written by the NSA and entered the kernel as public code, reviewed on the list. The "NSA references" that disappeared were removed in the commit "selinux: de-brand SELinux", by Stephen Smalley, one of the SELinux maintainers [70], which changed "NSA SELinux" to "SELinux" in the help text and comments [231]. The 6.6 pull request explains: "We've come a long way from the original NSA submission and I would consider SELinux a true community project at this point so removing the NSA branding just makes sense" [232]. It was a rebranding, not the removal of malicious code. The sentence I used to repeat was wrong. The real risk is more boring: four in ten commits go in without a review tag, and the maintainer applying them is tired.

None of these tensions means the model is about to break. They are the price of a model in which whoever pays decides where to spend, and in which what nobody wants to pay for, such as review, maintenance of old code and patience with the process, falls on a few people.

Conclusion: a commons with too many owners

In 1991, the kernel belonged to one person. In 2026, it belongs to no one and to everyone who pays.

The numbers in this article point to the same place. Of every five commits in 7.2, four come from people with an identified affiliation, and only 4.5% from people declaredly working on their own [2]. Those who accept the code are even more corporate: 1.6% of maintainer sign-offs in 6.19 come from people without an employer [40]. The subsystems that define modern Linux, from cgroups to io_uring, from KVM to sched_ext, were born from corporate needs and reached mainline written by corporate employees. The robots that test the kernel have owners too. Even the lifetime of a long-term version depends on "enough interest from the industry at large" [148].

That does not make Linux one company's product, and this is where the contrast with the other Unixes helps. OpenSolaris had an owner, and the community had to create Illumos when the owner stopped publishing [183]. XNU belongs to a company and appears on GitHub as a release distribution [181]. The Linux kernel received commits from 249 identified employers in a single cycle, and no single company exceeded 10% of the commits in 7.2 or 12% of the maintainer sign-offs in 6.19 [2], [40]. The final referee is paid by a foundation the companies fund, and on that foundation's board each Platinum member appoints a single director [159]. Linux's robustness does not come from the absence of companies. It comes from there being too many companies for any one of them to be in charge.

The model works under three conditions, and the kernel shows all three. Staying outside has to be expensive: with no stable internal ABI, whoever does not send code to mainline pays the rebase forever [162]. No participant can be big enough to close the project. And the process has to be public, with rules that apply to the intern and the vice president alike: the same list, the same Signed-off-by, the same merge window.

The model also has blind spots, and they are where nobody has an incentive to pay. Review, maintenance of old code and patience with the process fall on a few people. The Linux Foundation set aside 2.95% of its forecast 2025 spending for the kernel [152]. Two in five commits go in without a review tag [37]. And when geopolitics arrives, the project obeys the law of the country where the foundation and the largest companies are based [218].

Anyone who uses Linux every day, as I do, does not need to romanticize any of this. Linux is not secure because it is open, nor free of commercial interest. It is critical infrastructure that dozens of competitors maintain together because it is cheaper than maintaining it alone, and it stays open because none of them could close it.

Free software is not software without owners. It is software with too many owners for any one of them to be in charge.

References

[1]L. Torvalds, “What would you like to see most in minix?,” message on comp.os.minix, Aug. 25, 1991. Archived copy at Carnegie Mellon University. [Online]. Available: https://www.cs.cmu.edu/~awb/linux.history.html ↩
[2]J. Corbet, “Development statistics for the 7.2 kernel,” LWN.net, Aug. 17, 2026. [Online]. Available: https://lwn.net/Articles/1088776/ ↩
[3]The FreeBSD Documentation Project, “Introduction: About the FreeBSD Project,” in FreeBSD Handbook. [Online]. Available: https://docs.freebsd.org/en/books/handbook/introduction/ ↩
[4]M. Linksvayer, “The Choice of a GNU Generation: An Interview With Linus Torvalds,” Meta, Nov. 1993. [Online]. Available: https://gondwanaland.com/meta/history/interview.html ↩
[5]Red Hat, Inc., “Prospectus: 6,000,000 Shares, Common Stock (Form 424B1),” U.S. Securities and Exchange Commission, Aug. 11, 1999. [Online]. Available: https://www.sec.gov/Archives/edgar/data/0001087423/000104746999031070/0001047469-99-031070.txt ↩
[6]A. Leonard, “Red Hot,” Salon, Aug. 12, 1999. [Online]. Available: https://www.salon.com/1999/08/12/redhat_ipo/ ↩
[7]M. Tosatti, “Re: Linux 2.4.16-pre1,” message on the linux-kernel mailing list, Nov. 24, 2001. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0111.3/0103.html ↩
[8]LWN.net, “Linux in the News,” LWN.net Weekly Edition, Dec. 14, 2000. [Online]. Available: https://lwn.net/2000/1214/press.php3 ↩
[9]LWN.net, “Commerce,” LWN.net Weekly Edition, Dec. 14, 2000. [Online]. Available: https://lwn.net/2000/1214/commerce.php3 ↩
[10]J. Barr, “Inside IBM's Linux Technology Center,” Computerworld, Mar. 20, 2001. [Online]. Available: https://www.computerworld.com/article/1447992/inside-ibm-s-linux-technology-center.html ↩
[11]“Industry Leader Forming Development Lab For Linux,” press release reproduced by Scoop, Aug. 31, 2000. [Online]. Available: https://www.scoop.co.nz/stories/BU0008/S00241.htm ↩
[12]OSDL and Transmeta, “Linux Creator Linus Torvalds joins OSDL,” press release reproduced on LWN.net, Jun. 17, 2003. [Online]. Available: https://lwn.net/Articles/36635/ ↩
[13]A. Updegrove, “Joining Forces: OSDL and the Free Standards Group will become The Linux Foundation,” ConsortiumInfo.org, Jan. 21, 2007. [Online]. Available: https://www.consortiuminfo.org/open-source-open-standards/joining-forces-osdl-and-the-free-standards-group-will-become-the-linux-foundation ↩
[14]Novell, Inc., “Novell Announces Agreement to Acquire Leading Enterprise Linux Technology Company SUSE LINUX,” Exhibit 99, Form 8-K, U.S. Securities and Exchange Commission, Nov. 4, 2003. [Online]. Available: https://www.sec.gov/Archives/edgar/data/0000758004/000075800403000018/nov4_99.htm ↩
[15]Caldera International, Inc. (The SCO Group), “Form 8-K,” U.S. Securities and Exchange Commission, Mar. 7, 2003. [Online]. Available: https://www.sec.gov/Archives/edgar/data/1102542/000104746903008083/a2105216z8-k.txt ↩
[16]The SCO Group, Inc., “Form 8-K,” U.S. Securities and Exchange Commission, Aug. 10, 2007. [Online]. Available: https://www.sec.gov/Archives/edgar/data/1102542/000095013407018100/v33019e8vk.htm ↩
[17]S. Sharwood, “SCO v. IBM settlement deal is done, but zombie case shuffles on elsewhere,” The Register, Aug. 30, 2021. [Online]. Available: https://www.theregister.com/2021/08/30/sco_tsg_vs_ibm_settlement/ ↩
[18]L. Torvalds, “[RFD] Explicitly documenting patch submission,” message on the linux-kernel mailing list, May 23, 2004. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0405.2/1301.html ↩
[19]The Linux Foundation, “Developer Certificate of Origin, Version 1.1,” 2004–2006. [Online]. Available: https://developercertificate.org/ ↩
[20]The kernel development community, “Submitting patches: the essential guide to getting your code into the kernel,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/process/submitting-patches.html ↩
[21]J. Corbet, “The kernel and BitKeeper part ways,” LWN.net, Apr. 6, 2005. [Online]. Available: https://lwn.net/Articles/130746/ ↩
[22]J. Corbet, “An attempt to backdoor the kernel,” LWN.net, Nov. 6, 2003. [Online]. Available: https://lwn.net/Articles/57135/ ↩
[23]L. Torvalds, “Kernel SCM saga..,” message on the linux-kernel mailing list, Apr. 6, 2005. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0504.0/1540.html ↩
[24]L. Torvalds, “Initial revision of "git", the information manager from hell,” commit e83c5163316f, git/git repository, Apr. 7, 2005. [Online]. Available: https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 ↩
[25]L. Torvalds, “Linux-2.6.12-rc2,” commit 1da177e4c3f4, torvalds/linux repository, Apr. 16, 2005. [Online]. Available: https://github.com/torvalds/linux/commit/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ↩
[26]J. Corbet, “Kernel Summit: Development process,” LWN.net, Jul. 21, 2004. [Online]. Available: https://lwn.net/Articles/94386/ ↩
[27]J. Corbet, “Who wrote 2.6.20?,” LWN.net, Feb. 21, 2007. [Online]. Available: https://lwn.net/Articles/222773/ ↩
[28]The Linux Foundation, “Linux Foundation Publishes Study on Linux Development Statistics: Who Writes Linux and Who Supports It,” press release, Apr. 1, 2008. [Online]. Available: https://www.linuxfoundation.org/press/press-release/linux-foundation-publishes-study-on-linux-development-statistics-who-writes-linux-and-who-supports-it ↩
[29]The Linux Foundation, “The Linux Foundation Releases Annual Linux Development Report,” press release, Apr. 3, 2012. [Online]. Available: https://www.linuxfoundation.org/press/press-release/the-linux-foundation-releases-annual-linux-development-report ↩
[30]The Linux Foundation, “The Linux Foundation Releases Linux Development Report,” press release, Feb. 18, 2015. [Online]. Available: https://www.linuxfoundation.org/press/press-release/the-linux-foundation-releases-linux-development-report ↩
[31]J. Corbet e G. Kroah-Hartman, 2017 Linux Kernel Development Report. The Linux Foundation, 2017. [Online]. Available: https://www.linuxfoundation.org/hubfs/Reports/LinuxKernelReport_2017.pdf ↩
[32]J. Corbet, “Developer statistics for 2.6.30,” LWN.net, May 27, 2009. [Online]. Available: https://lwn.net/Articles/334721/ ↩
[33]J. Corbet, “Who wrote 3.0 - from two points of view,” LWN.net, Jul. 13, 2011. [Online]. Available: https://lwn.net/Articles/451243/ ↩
[34]J. Corbet, “Statistics from the 4.0 development cycle,” LWN.net, Apr. 1, 2015. [Online]. Available: https://lwn.net/Articles/637909/ ↩
[35]J. Corbet, “Some 6.0 development statistics,” LWN.net, Oct. 3, 2022. [Online]. Available: https://lwn.net/Articles/909625/ ↩
[36]J. Corbet, “Some 6.7 development statistics,” LWN.net, Jan. 8, 2024. [Online]. Available: https://lwn.net/Articles/956765/ ↩
[37]L. Torvalds et al., “Linux kernel source tree (torvalds/linux),” Git repository, clone accessed Oct. 2, 2026. [Online]. Available: https://github.com/torvalds/linux ↩
[38]J. Corbet, “Some 6.18 development statistics,” LWN.net, Dec. 1, 2025. [Online]. Available: https://lwn.net/Articles/1046966/ ↩
[39]J. Corbet, “Some 6.6 development statistics,” LWN.net, Oct. 30, 2023. [Online]. Available: https://lwn.net/Articles/948970/ ↩
[40]J. Corbet, “Development statistics for 6.19,” LWN.net, Feb. 9, 2026. [Online]. Available: https://lwn.net/Articles/1057302/ ↩
[41]U. Lerch, “Kommerzielle Entwicklung von Open-Source-Software: Idealismus, Pragmatismus oder Strategie? Eine Fallstudie über Entwickler des Linux-Kernels in großen Firmen der Informationstechnologie,” doctoral dissertation, Technische Universität Berlin, 2010. [Online]. Available: https://depositonce.tu-berlin.de/items/0f44ee1e-66a6-4161-b9bf-ed7a937be1d5/full ↩
[42]D. Riehle, P. Riemer, C. Kolassa and M. Schmidt, “Paid vs. Volunteer Work in Open Source,” in Proc. 47th Hawaii International Conference on System Sciences (HICSS), 2014, pp. 3286–3295, doi: 10.1109/HICSS.2014.407. [Online]. Available: https://dirkriehle.com/2013/08/22/paid-vs-volunteer-work-in-open-source/ ↩
[43]R. Seth, “[patch 0/5]-Containers: Introduction,” message on the linux-kernel mailing list, Sep. 14, 2006. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0609.1/2068.html ↩
[44]J. Corbet, “Process containers,” LWN.net, May 29, 2007. [Online]. Available: https://lwn.net/Articles/236038/ ↩
[45]A. Verma, L. Pedrosa, M. Korupolu, D. Oppenheimer, E. Tune and J. Wilkes, “Large-scale cluster management at Google with Borg,” in Proc. EuroSys 2015, 2015. [Online]. Available: https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/ ↩
[46]P. B. Menage, “Adding Generic Process Containers to the Linux Kernel,” in Proc. Ottawa Linux Symposium, vol. 2, 2007, pp. 45–58. [Online]. Available: https://www.kernel.org/doc/ols/2007/ols2007v2-pages-45-58.pdf ↩
[47]P. Menage, “Task Control Groups: basic task cgroup framework,” commit ddbcc7e8e50a, Oct. 18, 2007. [Online]. Available: https://github.com/torvalds/linux/commit/ddbcc7e8e50aefe467c01cac3dec71f118cd8ac2 ↩
[48]T. Heo, “Control Group v2,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/admin-guide/cgroup-v2.html ↩
[49]J. Corbet, “The unified control group hierarchy in 3.16,” LWN.net, Jun. 11, 2014. [Online]. Available: https://lwn.net/Articles/601840/ ↩
[50]Kernelnewbies, “Linux 4.5,” Mar. 13, 2016. [Online]. Available: https://kernelnewbies.org/Linux_4.5 ↩
[51]D. Xu, “Open-sourcing oomd, a new approach to handling OOMs,” Engineering at Meta, Jul. 19, 2018. [Online]. Available: https://engineering.fb.com/2018/07/19/production-engineering/oomd/ ↩
[52]J. Corbet, “Tracking pressure-stall information,” LWN.net, Jul. 13, 2018. [Online]. Available: https://lwn.net/Articles/759781/ ↩
[53]J. Weiner, “psi: pressure stall information for CPU, memory, and IO,” commit eb414681d5a0, Oct. 26, 2018. [Online]. Available: https://github.com/torvalds/linux/commit/eb414681d5a07d28d2ff90dc05f69ec6b232ebd2 ↩
[54]R. Pike, D. Presotto, K. Thompson, H. Trickey and P. Winterbottom, “The Use of Name Spaces in Plan 9,” Bell Laboratories. [Online]. Available: https://9p.io/sys/doc/names.html ↩
[55]E. W. Biederman, “Multiple Instances of the Global Linux Namespaces,” in Proc. Ottawa Linux Symposium, vol. 1, 2006, pp. 101–112. [Online]. Available: https://www.kernel.org/doc/ols/2006/ols2006v1-pages-101-112.pdf ↩
[56]M. Kerrisk, “Namespaces in operation, part 1: namespaces overview,” LWN.net, Jan. 4, 2013. [Online]. Available: https://lwn.net/Articles/531114/ ↩
[57]A. Kali, “cgroup: introduce cgroup namespaces,” commit a79a908fd2b0, Jan. 29, 2016. [Online]. Available: https://github.com/torvalds/linux/commit/a79a908fd2b080977b45bf103184b81c9d11ad07 ↩
[58]A. Vagin and D. Safonov, “ns: Introduce Time Namespace,” commit 769071ac9f20, Nov. 12, 2019. [Online]. Available: https://github.com/torvalds/linux/commit/769071ac9f20b6a447410c7eaa55d1a5233ef40c ↩
[59]S. E. Hallyn, “uts namespaces: Introduction,” patch reproduced on LWN.net, Apr. 2006. [Online]. Available: https://lwn.net/Articles/179345/ ↩
[60]P. Emelyanov and K. Kolyshkin, “PID namespaces in the 2.6.24 kernel,” LWN.net, Nov. 19, 2007. [Online]. Available: https://lwn.net/Articles/259217/ ↩
[61]A. Kivity, “[PATCH 0/7] KVM: Kernel-based Virtual Machine,” message on the linux-kernel mailing list, Oct. 19, 2006. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0610.2/1369.html ↩
[62]A. Kivity, Y. Kamay, D. Laor, U. Lublin and A. Liguori, “kvm: the Linux Virtual Machine Monitor,” in Proc. Ottawa Linux Symposium, vol. 1, 2007, pp. 225–230. [Online]. Available: https://www.kernel.org/doc/ols/2007/ols2007v1-pages-225-230.pdf ↩
[63]“The Definitive KVM (Kernel-based Virtual Machine) API Documentation,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/virt/kvm/api.html ↩
[64]A. Kivity, “[PATCH] kvm: userspace interface,” commit 6aa8b732ca01, Dec. 10, 2006. [Online]. Available: https://github.com/torvalds/linux/commit/6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 ↩
[65]Kernelnewbies, “Linux 3.0,” Jul. 21, 2011. [Online]. Available: https://kernelnewbies.org/Linux_3.0 ↩
[66]Red Hat, “Red Hat Advances Virtualization Leadership with Qumranet, Inc. Acquisition,” press release, Sep. 4, 2008. [Online]. Available: https://www.redhat.com/en/about/press-releases/qumranet ↩
[67]“MAINTAINERS,” Linux 3.0, torvalds/linux repository. [Online]. Available: https://github.com/torvalds/linux/blob/v3.0/MAINTAINERS ↩
[68]Amazon Web Services, “Amazon EC2 FAQs,” accessed Oct. 2, 2026. [Online]. Available: https://aws.amazon.com/ec2/faqs/ ↩
[69]A. Honig and N. Porter, “7 ways we harden our KVM hypervisor at Google Cloud: security in plaintext,” Google Cloud Blog, Jan. 25, 2017. [Online]. Available: https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext ↩
[70]“MAINTAINERS,” Linux 7.2, torvalds/linux repository. [Online]. Available: https://github.com/torvalds/linux/blob/v7.2/MAINTAINERS ↩
[71]S. McCanne and V. Jacobson, “The BSD Packet Filter: A New Architecture for User-level Packet Capture,” Lawrence Berkeley Laboratory, Dec. 19, 1992. [Online]. Available: https://www.tcpdump.org/papers/bpf-usenix93.pdf ↩
[72]A. Starovoitov, “net: filter: rework/optimize internal BPF interpreter's instruction set,” commit bd4cf0ed331a, Mar. 28, 2014. [Online]. Available: https://github.com/torvalds/linux/commit/bd4cf0ed331a275e9bf5a49e6d0fd55dffc551b8 ↩
[73]A. Starovoitov, “bpf: introduce BPF syscall and maps,” commit 99c55f7d47c0, Sep. 26, 2014. [Online]. Available: https://github.com/torvalds/linux/commit/99c55f7d47c0dc6fc64729f37bf435abf43f4c60 ↩
[74]J. Corbet, “Ktap or BPF?,” LWN.net, Apr. 23, 2014. [Online]. Available: https://lwn.net/Articles/595565/ ↩
[75]T. Høiland-Jørgensen, J. D. Brouer, D. Borkmann, J. Fastabend, T. Herbert, D. Ahern and D. Miller, “The eXpress Data Path: Fast Programmable Packet Processing in the Operating System Kernel,” in Proc. CoNEXT '18, 2018, doi: 10.1145/3281411.3281443. [Online]. Available: https://github.com/tohojo/xdp-paper ↩
[76]B. Blanco, “bpf: add XDP prog type for early driver filter,” commit 6a773a15a1e8, Jul. 19, 2016. [Online]. Available: https://github.com/torvalds/linux/commit/6a773a15a1e8874e5eccd2f29190c31085912c95 ↩
[77]J. Corbet, “BPF at Facebook (and beyond),” LWN.net, Oct. 10, 2019. [Online]. Available: https://lwn.net/Articles/801871/ ↩
[78]K. P. Singh, “bpf: Introduce BPF_PROG_TYPE_LSM,” commit fc611f47f218, Mar. 29, 2020. [Online]. Available: https://github.com/torvalds/linux/commit/fc611f47f2188ade2b48ff6902d5cce8baac0c58 ↩
[79]J. Corbet, “KRSI — the other BPF security module,” LWN.net, Dec. 27, 2019. [Online]. Available: https://lwn.net/Articles/808048/ ↩
[80]D. Thaler, Ed., “BPF Instruction Set Architecture (ISA),” RFC 9669, Internet Engineering Task Force, Oct. 2024. [Online]. Available: https://www.rfc-editor.org/rfc/rfc9669.html ↩
[81]J. Corbet, “Ringing in a new asynchronous I/O API,” LWN.net, Jan. 15, 2019. [Online]. Available: https://lwn.net/Articles/776703/ ↩
[82]J. Axboe, “Add io_uring IO interface,” commit 2b188cc1bb85, Jan. 7, 2019. [Online]. Available: https://github.com/torvalds/linux/commit/2b188cc1bb857a9d4701ae59aa7768b5124e262e ↩
[83]J. Axboe, public GitHub profile (declared company), accessed Oct. 2, 2026. [Online]. Available: https://github.com/axboe ↩
[84]T. Koczka, “Learnings from kCTF VRP's 42 Linux kernel exploits submissions,” Google Online Security Blog, Jun. 14, 2023. [Online]. Available: https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html ↩
[85]M. Rizzo, “io_uring: add a sysctl to disable io_uring system-wide,” commit 76d3ccecfa18, Aug. 21, 2023. [Online]. Available: https://github.com/torvalds/linux/commit/76d3ccecfa186af3120e206d62f03db1a94a535f ↩
[86]C. Mason, “[ANNOUNCE] Btrfs: a copy on write, snapshotting FS,” message on the linux-kernel mailing list, Jun. 12, 2007. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0706.1/1732.html ↩
[87]O. Rodeh, J. Bacik and C. Mason, “BTRFS: The Linux B-Tree Filesystem,” ACM Transactions on Storage, vol. 9, no. 3, 2013, doi: 10.1145/2501620.2501623. [Online]. Available: https://doi.org/10.1145/2501620.2501623 ↩
[88]Kernelnewbies, “Linux 2.6.29,” Mar. 23, 2009. [Online]. Available: https://kernelnewbies.org/Linux_2_6_29 ↩
[89]J. Corbet, “Btrfs at Facebook,” LWN.net, Jul. 2, 2020. [Online]. Available: https://lwn.net/Articles/824855/ ↩
[90]Red Hat, “Btrfs (Technology Preview),” in Red Hat Enterprise Linux 7 Storage Administration Guide. [Online]. Available: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-btrfs ↩
[91]Fedora Project, “Changes/BtrfsByDefault,” Fedora Project Wiki. [Online]. Available: https://fedoraproject.org/wiki/Changes/BtrfsByDefault ↩
[92]A. Sweeney, D. Doucette, W. Hu, C. Anderson, M. Nishimoto and G. Peck, “Scalability in the XFS File System,” in Proc. USENIX 1996 Annual Technical Conference, 1996. [Online]. Available: https://www.usenix.org/legacy/publications/library/proceedings/sd96/sweeney.html ↩
[93]L. Torvalds, “Linux 2.5.36,” message on the linux-kernel mailing list, Sep. 17, 2002. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0209.2/0514.html ↩
[94]Red Hat, “The XFS File System,” in Red Hat Enterprise Linux 7 Storage Administration Guide. [Online]. Available: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-xfs ↩
[95]D. J. Wong, “xfs: create an ioctl to scrub AG metadata,” commit 36fd6e863cb7, Oct. 17, 2017. [Online]. Available: https://github.com/torvalds/linux/commit/36fd6e863cb7329ab2e5687fdae4e4626b840adc ↩
[96]I. Molnar, “[announce] [patch] ultra-scalable O(1) SMP and UP scheduler,” message on the linux-kernel mailing list, Jan. 3, 2002. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0201.0/0810.html ↩
[97]J. Corbet, “The Rotating Staircase Deadline Scheduler,” LWN.net, Mar. 6, 2007. [Online]. Available: https://lwn.net/Articles/224865/ ↩
[98]I. Molnar, “[Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS],” message on the linux-kernel mailing list, Apr. 13, 2007. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0704.1/2138.html ↩
[99]I. Molnar, “sched: cfs core code,” commit dd41f596cda0, Jul. 9, 2007. [Online]. Available: https://github.com/torvalds/linux/commit/dd41f596cda0d7d6e4a8b139ffdfabcefdd46528 ↩
[100]I. Stoica and H. Abdel-Wahab, “Earliest Eligible Virtual Deadline First: A Flexible and Accurate Mechanism for Proportional Share Resource Allocation,” Old Dominion University, technical report TR-95-22, 1995. [Online]. Available: https://people.eecs.berkeley.edu/~istoica/papers/eevdf-tr-95.pdf ↩
[101]J. Corbet, “An EEVDF CPU scheduler for Linux,” LWN.net, Mar. 9, 2023. [Online]. Available: https://lwn.net/Articles/925371/ ↩
[102]“EEVDF Scheduler,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/scheduler/sched-eevdf.html ↩
[103]P. Zijlstra, “sched/fair: Implement an EEVDF-like scheduling policy,” commit 147f3efaa241, May 31, 2023. [Online]. Available: https://github.com/torvalds/linux/commit/147f3efaa24182a21706bca15eab2f3f4630b5fe ↩
[104]J. Corbet, “The extensible scheduler class,” LWN.net, Feb. 10, 2023. [Online]. Available: https://lwn.net/Articles/922405/ ↩
[105]J. Corbet, “Extensible scheduler class to be merged for 6.11,” LWN.net, Jun. 11, 2024. [Online]. Available: https://lwn.net/Articles/978007/ ↩
[106]T. Heo, “sched_ext: Implement BPF extensible scheduler class,” commit f0e1a0643a59, Jun. 18, 2024. [Online]. Available: https://github.com/torvalds/linux/commit/f0e1a0643a59bf1f922fa209cec86a170b784f3f ↩
[107]T. Heo, public GitHub profile (declared company), accessed Oct. 2, 2026. [Online]. Available: https://github.com/htejun ↩
[108]“Extensible Scheduler Class,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/scheduler/sched-ext.html ↩
[109]ProPublica, “The Linux Foundation (EIN 46-0503801),” Nonprofit Explorer, IRS Form 990 data, accessed Oct. 2, 2026. [Online]. Available: https://projects.propublica.org/nonprofits/organizations/460503801 ↩
[110]L. Torvalds, “Linux 4.2-rc1,” message on the linux-kernel mailing list, Jul. 5, 2015. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/1507.0/02156.html ↩
[111]A. Deucher, “drm/amdgpu: add core driver (v4),” commit d38ceaf99ed0, Apr. 20, 2015. [Online]. Available: https://github.com/torvalds/linux/commit/d38ceaf99ed015f2a0b9af3499791bd3a3daae21 ↩
[112]M. Brost et al., “drm/xe: Introduce a new DRM driver for Intel GPUs,” commit dd08ebf6c352, Mar. 30, 2023. [Online]. Available: https://github.com/torvalds/linux/commit/dd08ebf6c3525a7ea2186e636df064ea47281987 ↩
[113]Kernelnewbies, “Linux 2.6.33,” Feb. 24, 2010. [Online]. Available: https://kernelnewbies.org/Linux_2_6_33 ↩
[114]NVIDIA, “NVIDIA Releases Open-Source GPU Kernel Modules,” NVIDIA Technical Blog, May 2022. [Online]. Available: https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ ↩
[115]D. Krummrich, “gpu: nova-core: add initial driver stub,” commit 54e6baf123fd, Mar. 6, 2025. [Online]. Available: https://github.com/torvalds/linux/commit/54e6baf123fde089cfa9f609b0b39b40abe41e94 ↩
[116]E. Cohen, “mlx5: Add driver for Mellanox Connect-IB adapters,” commit e126ba97dba9, Jul. 7, 2013. [Online]. Available: https://github.com/torvalds/linux/commit/e126ba97dba9edeb6fafa3665b5f8497fc9cdf8c ↩
[117]NVIDIA, “NVIDIA Completes Acquisition of Mellanox, Creating Major Force Driving Next-Gen Data Centers,” press release, Apr. 27, 2020. [Online]. Available: https://nvidianews.nvidia.com/news/nvidia-completes-acquisition-of-mellanox-creating-major-force-driving-next-gen-data-centers ↩
[118]“patch-2.2.14.gz,” kernel.org archive file, Jan. 4, 2000. [Online]. Available: https://cdn.kernel.org/pub/linux/kernel/v2.2/patch-2.2.14.gz ↩
[119]“patch-2.5.5.gz,” kernel.org archive file, Feb. 20, 2002. [Online]. Available: https://cdn.kernel.org/pub/linux/kernel/v2.5/patch-2.5.5.gz ↩
[120]J. Edge, “Linaro seeks to simplify ARM Linux landscape,” LWN.net, Jun. 9, 2010. [Online]. Available: https://lwn.net/Articles/391189/ ↩
[121]L. Torvalds, “Re: [GIT PULL] omap changes for v2.6.39 merge window,” message on the linux-kernel mailing list, Mar. 17, 2011. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/1103.2/01004.html ↩
[122]J. Corbet, “Supporting 64-bit ARM systems,” LWN.net, Jul. 10, 2012. [Online]. Available: https://lwn.net/Articles/506148/ ↩
[123]C. Marinas, “arm64: Kernel booting and initialisation,” commit 9703d9d7f77c, Mar. 5, 2012. [Online]. Available: https://github.com/torvalds/linux/commit/9703d9d7f77ce129621f7d80a844822e2daa7008 ↩
[124]B. Swetland, “[ARM] msm: board file for MACH_HALIBUT (QCT MSM7200A),” commit 9e73c84c89b7, Nov. 26, 2007. [Online]. Available: https://github.com/torvalds/linux/commit/9e73c84c89b7c91ad5d6a141c58efbbe139f6b6c ↩
[125]“MAINTAINERS,” Linux 2.6.35, torvalds/linux repository. [Online]. Available: https://github.com/torvalds/linux/blob/v2.6.35/MAINTAINERS ↩
[126]P. Dabbelt, “RISC-V: Init and Halt Code,” commit 76d2a0493a17, Jul. 10, 2017. [Online]. Available: https://github.com/torvalds/linux/commit/76d2a0493a17d4c8ecc781366850c3c4f8e1a446 ↩
[127]“MAINTAINERS,” Linux 4.15, torvalds/linux repository. [Online]. Available: https://github.com/torvalds/linux/blob/v4.15/MAINTAINERS ↩
[128]I. Molnar, “[patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0,” message on the linux-kernel mailing list, Oct. 13, 2004. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0410.1/1577.html ↩
[129]“Lock types and their rules,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/locking/locktypes.html ↩
[130]T. Gleixner, “genirq: add threaded interrupt handler support,” commit 3aa551c9b4c4, Mar. 23, 2009. [Online]. Available: https://github.com/torvalds/linux/commit/3aa551c9b4c40018f0e261a178e3d25478dc04a9 ↩
[131]T. Gleixner, “sched/rt, Kconfig: Introduce CONFIG_PREEMPT_RT,” commit a50a3f4b6a31, Jul. 17, 2019. [Online]. Available: https://github.com/torvalds/linux/commit/a50a3f4b6a313dc76912bd4ad3b8b4f4b479c801 ↩
[132]The Linux Foundation, “The Linux Foundation Announces Project to Advance Real-Time Linux,” press release reproduced by Firmenpresse, Oct. 2015. [Online]. Available: https://www.firmenpresse.de/pressrelease424560/the-linux-foundation-announces-project-to-advance-real-time-linux.html ↩
[133]J. Corbet, “Intel acquires Linutronix,” LWN.net, Feb. 23, 2022. [Online]. Available: https://lwn.net/Articles/885903/ ↩
[134]L. Torvalds, “Merge tag 'printk-for-6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux,” commit c903327d3295, Sep. 17, 2024. [Online]. Available: https://github.com/torvalds/linux/commit/c903327d3295b135eb8c81ebe0b68c1837718eb8 ↩
[135]S. A. Siewior, “x86: Allow to enable PREEMPT_RT.,” commit d2d6422f8bd1, Sep. 6, 2024. [Online]. Available: https://github.com/torvalds/linux/commit/d2d6422f8bd17c6bb205133e290625a564194496 ↩
[136]L. Torvalds, “Merge tag 'sched-rt-2024-09-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip,” commit baeb9a7d8b60, Sep. 20, 2024. [Online]. Available: https://github.com/torvalds/linux/commit/baeb9a7d8b60b021d907127509c44507539c15e5 ↩
[137]J. Edge, “Rust heads into the kernel?,” LWN.net, Apr. 21, 2021. [Online]. Available: https://lwn.net/Articles/853423/ ↩
[138]J. Aas, “Supporting Miguel Ojeda's Work on Rust in the Linux Kernel,” Prossimo (ISRG), Jun. 17, 2021. [Online]. Available: https://www.memorysafety.org/blog/supporting-miguel-ojeda-rust-in-linux/ ↩
[139]L. Torvalds, “Merge tag 'rust-v6.1-rc1' of https://github.com/Rust-for-Linux/linux,” commit 8aebac82933f, Oct. 3, 2022. [Online]. Available: https://github.com/torvalds/linux/commit/8aebac82933ff1a7c8eede18cab11e1115e2062b ↩
[140]A. Ryhl, “rust_binder: add Rust Binder driver,” commit eafedbc7c050, Sep. 19, 2025. [Online]. Available: https://github.com/torvalds/linux/commit/eafedbc7c050c44744fbdf80bdf3315e860b7513 ↩
[141]J. Corbet, “The state of the kernel Rust experiment,” LWN.net, Dec. 13, 2025. [Online]. Available: https://lwn.net/Articles/1050174/ ↩
[142]M. Ojeda, “rust: conclude the Rust experiment,” commit 9fa7153c31a3, Dec. 13, 2025. [Online]. Available: https://github.com/torvalds/linux/commit/9fa7153c31a3e5fe578b83d23bc9f185fde115da ↩
[143]G. Krisman Bertazi, “futex: Implement mechanism to wait on any of several futexes,” patch reproduced on LWN.net, Jul. 30, 2019. [Online]. Available: https://lwn.net/Articles/794969/ ↩
[144]A. Almeida, “futex: Implement sys_futex_waitv(),” commit bf69bad38cf6, Sep. 23, 2021. [Online]. Available: https://github.com/torvalds/linux/commit/bf69bad38cf63d980e8a603f8d1bd1f85b5ed3d9 ↩
[145]Kernelnewbies, “Linux 5.16,” Jan. 9, 2022. [Online]. Available: https://kernelnewbies.org/Linux_5.16 ↩
[146]The kernel development community, “2. How the development process works,” in A guide to the Kernel Development Process, The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/process/2.Process.html ↩
[147]The kernel development community, “Everything you ever wanted to know about Linux -stable releases,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/process/stable-kernel-rules.html ↩
[148]kernel.org, “Releases,” accessed Oct. 2, 2026. [Online]. Available: https://www.kernel.org/category/releases.html ↩
[149]J. Corbet, “A turning point for CVE numbers,” LWN.net, Feb. 14, 2024. [Online]. Available: https://lwn.net/Articles/961332/ ↩
[150]The kernel development community, “CVEs,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/process/cve.html ↩
[151]LWN.net, “Kroah-Hartman: Linux CVEs, more than you ever wanted to know,” LWN.net, Dec. 10, 2025. [Online]. Available: https://lwn.net/Articles/1049963/ ↩
[152]The Linux Foundation, Annual Report 2025. The Linux Foundation, Dec. 2025. [Online]. Available: https://www.linuxfoundation.org/hubfs/Publications/2025%20Linux%20Foundation%20Annual%20Report_122225a_lr.pdf ↩
[153]The Linux Foundation, “Technical Advisory Board,” accessed Oct. 2, 2026. [Online]. Available: https://www.linuxfoundation.org/about/technical-advisory-board ↩
[154]Linux Plumbers Conference, contribution page of J. Kicinski, LPC 2025. [Online]. Available: https://lpc.events/event/19/contributions/2289/ ↩
[155]Open Source Summit North America 2025, talk page of D. Borkmann. [Online]. Available: https://ossna2025.sched.com/event/d3d6bc22578712b8eca7f0c202b195f5 ↩
[156]J. Corbet, “A new era for memory-management maintainership,” LWN.net, May 7, 2026. [Online]. Available: https://lwn.net/Articles/1070994/ ↩
[157]The Linux Foundation, Annual Report 2024. The Linux Foundation, Dec. 2024. [Online]. Available: https://linuxfoundation.org/hubfs/Reports/lf_ar24_121524a.pdf ↩
[158]M. Ojeda, “2025 LF Technical Advisory Board election - update,” message on the linux-kernel mailing list, Dec. 5, 2025. [Online]. Available: https://lkml.iu.edu/2512.0/05847.html ↩
[159]The Linux Foundation, “Bylaws,” accessed Oct. 2, 2026. [Online]. Available: https://www.linuxfoundation.org/legal/bylaws ↩
[160]M. Ojeda, “2025 LF Technical Advisory Board election - results,” message on the linux-kernel mailing list, Dec. 21, 2025. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2512.2/07130.html ↩
[161]J. Corbet, “An open seat on the TAB,” LWN.net, Dec. 8, 2025. [Online]. Available: https://lwn.net/Articles/1049035/ ↩
[162]G. Kroah-Hartman, “The Linux Kernel Driver Interface (all of your questions answered and then some),” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/process/stable-api-nonsense.html ↩
[163]J. Edge, “Moving Google toward the mainline,” LWN.net, Oct. 5, 2021. [Online]. Available: https://lwn.net/Articles/871195/ ↩
[164]B. Matheny and C. Mason, “Improving the Linux kernel with upstream contributions,” Engineering at Meta, Oct. 5, 2015. [Online]. Available: https://engineering.fb.com/2015/10/05/open-source/improving-the-linux-kernel-with-upstream-contributions/ ↩
[165]Y. Brosseau, “Upstream kernels @ Facebook,” talk at SCALE 14x, Jan. 2016. [Online]. Available: https://www.socallinuxexpo.org/scale/14x/presentations/upstream-kernels-facebook ↩
[166]Amazon Web Services, “Amazon Linux 2023 kernel lifecycle,” Amazon Linux 2023 User Guide, accessed Oct. 2, 2026. [Online]. Available: https://docs.aws.amazon.com/linux/al2023/ug/kernel-lifecycle.html ↩
[167]J. Edge, “ELC: Android and the community,” LWN.net, Apr. 14, 2010. [Online]. Available: https://lwn.net/Articles/383276/ ↩
[168]J. Corbet, “Bringing Android closer to the mainline,” LWN.net, Dec. 20, 2011. [Online]. Available: https://lwn.net/Articles/472984/ ↩
[169]J. Corbet, “Autosleep and wake locks,” LWN.net, Feb. 7, 2012. [Online]. Available: https://lwn.net/Articles/479841/ ↩
[170]Kernelnewbies, “Linux 3.5,” Jul. 21, 2012. [Online]. Available: https://kernelnewbies.org/Linux_3.5 ↩
[171]J. Corbet, “An update on the Android problem,” LWN.net, Nov. 7, 2017. [Online]. Available: https://lwn.net/Articles/738225/ ↩
[172]J. Corbet, “Bringing the Android kernel back to the mainline,” LWN.net, Nov. 15, 2018. [Online]. Available: https://lwn.net/Articles/771974/ ↩
[173]J. Corbet, “Android kernel notes from LPC 2020,” LWN.net, Sep. 10, 2020. [Online]. Available: https://lwn.net/Articles/830979/ ↩
[174]Android Open Source Project, “Generic Kernel Image (GKI) project,” source.android.com, accessed Oct. 2, 2026. [Online]. Available: https://source.android.com/docs/core/architecture/kernel/generic-kernel-image ↩
[175]Android Open Source Project, “Android common kernels,” source.android.com, accessed Oct. 2, 2026. [Online]. Available: https://source.android.com/docs/core/architecture/kernel/android-common ↩
[176]P. Galli, “Microsoft Releases Device Driver Code to the Linux Community,” Port25 (Microsoft), Jul. 20, 2009. [Online]. Available: https://learn.microsoft.com/en-us/archive/blogs/port25/microsoft-releases-device-driver-code-to-the-linux-community ↩
[177]G. Kroah-Hartman, “[patch 00/54] [Announce] Microsoft Hyper-V drivers for Linux,” message on the linux-kernel mailing list, Jul. 20, 2009. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0907.2/01249.html ↩
[178]The Linux Foundation, “Microsoft Fortifies Commitment to Open Source, Becomes Linux Foundation Platinum Member,” press release, Nov. 16, 2016. [Online]. Available: https://www.linuxfoundation.org/press/press-release/microsoft-fortifies-commitment-to-open-source-becomes-linux-foundation-platinum-member ↩
[179]Microsoft, “WSL2-Linux-Kernel: The source for the Linux kernel used in Windows Subsystem for Linux 2 (WSL2),” GitHub repository. [Online]. Available: https://github.com/microsoft/WSL2-Linux-Kernel ↩
[180]Sony Interactive Entertainment, “Open Source Software used in PlayStation®4,” accessed Oct. 2, 2026. [Online]. Available: https://www.playstation.com/en-us/oss/ps4/ ↩
[181]Apple, “xnu,” apple-oss-distributions GitHub repository. [Online]. Available: https://github.com/apple-oss-distributions/xnu ↩
[182]J. Looney, “Netflix and FreeBSD: Reflections on Running FreeBSD Head in Production,” BSDCan 2019, 2019. [Online]. Available: https://papers.freebsd.org/2019/bsdcan/looney-netflix_and_freebsd/ ↩
[183]K. Vervloesem, “Illumos: new hope for the OpenSolaris community?,” LWN.net, Aug. 11, 2010. [Online]. Available: https://lwn.net/Articles/399533/ ↩
[184]J. Lerner and J. Tirole, “Some Simple Economics of Open Source,” The Journal of Industrial Economics, vol. 50, no. 2, pp. 197–234, 2002, doi: 10.1111/1467-6451.00174. Working paper version: NBER Working Paper 7600, 2000. [Online]. Available: https://www.nber.org/papers/w7600 ↩
[185]J. West and S. Gallagher, “Challenges of open innovation: the paradox of firm investment in open-source software,” R&D Management, vol. 36, no. 3, pp. 319–331, 2006, doi: 10.1111/j.1467-9310.2006.00436.x. [Online]. Available: https://scholarworks.sjsu.edu/org_mgmt_pub/3 ↩
[186]J. Henkel, “Selective revealing in open innovation processes: The case of embedded Linux,” Research Policy, vol. 35, no. 7, pp. 953–969, 2006, doi: 10.1016/j.respol.2006.04.010. [Online]. Available: https://doi.org/10.1016/j.respol.2006.04.010 ↩
[187]M. Hoffmann, F. Nagle and Y. Zhou, “The Value of Open Source Software,” Harvard Business School, Working Paper 24-038, 2024. [Online]. Available: https://www.hbs.edu/ris/Publication%20Files/24-038_51f8444f-502c-4139-8bf2-56eb4b65c58a.pdf ↩
[188]N. Eghbal, Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure. Ford Foundation, 2016. [Online]. Available: https://www.fordfoundation.org/wp-content/uploads/2016/07/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure.pdf ↩
[189]Google, “syzkaller: an unsupervised coverage-guided kernel fuzzer,” GitHub repository (created Oct. 12, 2015). [Online]. Available: https://github.com/google/syzkaller ↩
[190]Google, “syzbot,” syzkaller documentation. [Online]. Available: https://github.com/google/syzkaller/blob/master/docs/syzbot.md ↩
[191]D. Vyukov, “Reflections on kernel development process, quality and testing,” presentation at the Linux Kernel Maintainers Summit, 2019. [Online]. Available: https://lpc.events/event/4/contributions/554/attachments/353/584/Reflections__Kernel_Summit_2019.pdf ↩
[192]syzbot, “Linux upstream,” painel accessed Oct. 2, 2026. [Online]. Available: https://syzkaller.appspot.com/upstream ↩
[193]M. Kerrisk, “KS2012: Kernel build/boot testing,” LWN.net, Sep. 5, 2012. [Online]. Available: https://lwn.net/Articles/514278/ ↩
[194]Intel, “lkp-tests: Linux Kernel Performance tests,” GitHub repository. [Online]. Available: https://github.com/intel/lkp-tests ↩
[195]J. Corbet, “Some 5.5 kernel development statistics,” LWN.net, Jan. 28, 2020. [Online]. Available: https://lwn.net/Articles/810639/ ↩
[196]The Linux Foundation, “Distributed Linux Testing Platform KernelCI Secures Funding and Long-Term Sustainability as New Linux Foundation Project,” press release reproduced on kernelci.org, Oct. 28, 2019. [Online]. Available: https://kernelci.org/?p=56 ↩
[197]KernelCI, home page and member list, accessed Oct. 2, 2026. [Online]. Available: https://kernelci.org/ ↩
[198]A. Ryabinin, “kasan: add kernel address sanitizer infrastructure,” commit 0b24becc810d, Feb. 13, 2015. [Online]. Available: https://github.com/torvalds/linux/commit/0b24becc810dc3be6e3f94103a866f214c282394 ↩
[199]M. Elver, “kcsan: Add Kernel Concurrency Sanitizer infrastructure,” commit dfd402a4c4ba, Nov. 14, 2019. [Online]. Available: https://github.com/torvalds/linux/commit/dfd402a4c4baae42398ce9180ff424d589b8bffc ↩
[200]J. Corbet, “5.8 Merge window, part 2,” LWN.net, Jun. 14, 2020. [Online]. Available: https://lwn.net/Articles/822527/ ↩
[201]A. Potapenko, “kmsan: add KMSAN runtime core,” commit f80be4571b19, Sep. 15, 2022. [Online]. Available: https://github.com/torvalds/linux/commit/f80be4571b19b9fd8dd1528cd2a2f123aff51f70 ↩
[202]A. Morton, “[GIT PULL] MM updates for 6.1-rc1,” message on the linux-kernel mailing list, Oct. 8, 2022. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2210.1/00272.html ↩
[203]B. Higgins, “kunit: test: add KUnit test runner core,” commit 914cc63eea6f, Sep. 23, 2019. [Online]. Available: https://github.com/torvalds/linux/commit/914cc63eea6fbe11ed46dba5e4438d81b0cd42d2 ↩
[204]The kernel development community, “Linux Kernel Selftests,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/dev-tools/kselftest.html ↩
[205]J. Corbet, “Reducing kernel-maintainer burnout,” LWN.net, Nov. 24, 2023. [Online]. Available: https://lwn.net/Articles/952034/ ↩
[206]J. Edge, “Maintainers don't scale,” LWN.net, Jun. 6, 2022. [Online]. Available: https://lwn.net/Articles/896918/ ↩
[207]M. Zhou, Q. Chen, A. Mockus and F. Wu, “On the scalability of Linux kernel maintainers' work,” in Proc. ESEC/FSE 2017, 2017, doi: 10.1145/3106237.3106287. [Online]. Available: https://par.nsf.gov/biblio/10063576 ↩
[208]L. Collin, “Re: [xz-devel] XZ for Java,” message on the xz-devel list, Jun. 8, 2022. [Online]. Available: https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html ↩
[209]A. Freund, “backdoor in upstream xz/liblzma leading to ssh server compromise,” message on the oss-security list, Mar. 29, 2024. [Online]. Available: https://www.openwall.com/lists/oss-security/2024/03/29/4 ↩
[210]J. Tan, “Tests: Update two test files.,” commit 6e636819e8f0, tukaani-project/xz repository, Mar. 9, 2024. [Online]. Available: https://github.com/tukaani-project/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89 ↩
[211]R. Russell et al., “Unreliable Guide To Hacking The Linux Kernel,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/kernel-hacking/hacking.html ↩
[212]C. Hellwig, “modules: inherit TAINT_PROPRIETARY_MODULE,” commit 262e6ae7081d, Jul. 28, 2020. [Online]. Available: https://github.com/torvalds/linux/commit/262e6ae7081df304fc625cf368d5c2cbba2bb991 ↩
[213]J. Corbet, “Making life (even) harder for proprietary modules,” LWN.net, Aug. 3, 2023. [Online]. Available: https://lwn.net/Articles/939842/ ↩
[214]M. Larabel, “Linus Torvalds Calls NVIDIA The Worst Company,” Phoronix, Jun. 17, 2012 (secondary source). [Online]. Available: https://www.phoronix.com/news/MTEyMTc ↩
[215]L. Torvalds, “Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation,” message on the linux-kernel mailing list, Jan. 21, 2018. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html ↩
[216]The kernel development community, “Embargoed hardware issues,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/process/embargoed-hardware-issues.html ↩
[217]G. Kroah-Hartman, “MAINTAINERS: Remove some entries due to various compliance requirements.,” commit 6e90b675cf94, Oct. 18, 2024. [Online]. Available: https://github.com/torvalds/linux/commit/6e90b675cf942e50c70e8394dfb5862975c3b3b2 ↩
[218]J. Corbet, “Several Russian developers lose kernel maintainership status,” LWN.net, Oct. 22, 2024, with updates. [Online]. Available: https://lwn.net/Articles/995186/ ↩
[219]P. Moore, “Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.,” message on the linux-kernel mailing list, Oct. 2024. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2410.2/09875.html ↩
[220]J. Bottomley, “Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.,” message on the linux-kernel mailing list, Oct. 24, 2024. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2410.3/01081.html ↩
[221]W. Almeida Filho, “[PATCH 0/1] Retiring from the Rust for Linux project,” message on the kernel mailing lists, Aug. 28, 2024. [Online]. Available: https://patchew.org/linux/20240828211117.9422-1-wedsonaf@gmail.com ↩
[222]C. Hellwig, “Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.,” message on the linux-kernel mailing list, Jan. 28, 2025. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2501.3/03615.html ↩
[223]C. Hellwig, “Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.,” message on the linux-kernel mailing list, Jan. 31, 2025. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2501.3/06788.html ↩
[224]L. Torvalds, reply to H. Martin in the Rust DMA abstraction thread, linux-kernel mailing list, Feb. 6, 2025. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2502.0/07186.html ↩
[225]H. Martin, “[PATCH] MAINTAINERS: Remove myself,” message on the linux-kernel mailing list, Feb. 2025. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2502.0/07276.html ↩
[226]L. Torvalds, “Re: Rust kernel policy,” message on the linux-kernel mailing list, Feb. 20, 2025. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2502.2/08504.html ↩
[227]Rust for Linux, “Rust kernel policy,” accessed Oct. 2, 2026. [Online]. Available: https://rust-for-linux.com/rust-kernel-policy ↩
[228]L. Torvalds, “MAINTAINERS: mark bcachefs externally maintained,” commit ebf2bfec412a, Aug. 28, 2025. [Online]. Available: https://github.com/torvalds/linux/commit/ebf2bfec412ad293a0b118fb1a20a551088ebc9b ↩
[229]L. Torvalds, “Remove bcachefs core code,” commit f2c61db29f27, Sep. 29, 2025. [Online]. Available: https://github.com/torvalds/linux/commit/f2c61db29f277b9c80de92102fc532cc247495cd ↩
[230]Linux Foundation Technical Advisory Board, “Report on University of Minnesota Breach-of-Trust Incident,” message on the linux-kernel mailing list, May 5, 2021. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2105.0/04009.html ↩
[231]S. Smalley, “selinux: de-brand SELinux,” commit 90aa4f5e92f2, Jul. 18, 2023. [Online]. Available: https://github.com/torvalds/linux/commit/90aa4f5e92f2797c3c86e05f588ab277b0e0ba39 ↩
[232]P. Moore, “[GIT PULL] SELinux patches for v6.6,” message on the linux-kernel mailing list, Aug. 29, 2023. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2308.3/05977.html ↩

摘要

Linux 在 1991 年以一名學生的業餘專案起家，至今仍有許多人這樣想像它。數字說的是另一個故事。在 2026 年 8 月發布的 7.2 版核心中，16,418 個提交裡有 78.8% 來自 LWN 能辨識出所屬單位的人，無論是公司、顧問公司或機構。只有 4.5% 來自自行工作的人，而 2009 年是 16.8%。負責接受修補的人更加企業化：在 6.19 版中，維護者的簽核只有 1.6% 來自沒有雇主的人。cgroups、KVM、eBPF、io_uring、Btrfs、sched_ext、PREEMPT_RT 與 ARM64 支援，都源自企業的需求，並由企業員工寫進主線。測試核心的機器人也有主人。本文根據 git log、MAINTAINERS 檔案、LWN 的統計以及 Linux 基金會的報告重建這段歷史；該基金會在 2025 年的預估支出中，只把 2.95% 撥給核心。本文說明這個模式解釋了什麼、又留下哪些未解的問題：審查不足、維護者過勞、集中化、制裁，以及圍繞 Rust 的爭執。起源是個人的，基礎設施是產業的。

從業餘嗜好到預算科目（1991–2005）

1991 年 8 月 25 日，一名赫爾辛基大學的學生在 comp.os.minix 新聞群組發了一則簡短的意見調查，談他從 4 月開始寫的作業系統：「I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones」[1]。Linus Torvalds 在附註中提醒，這份程式碼無法移植，而且大概永遠只支援 AT 硬碟，「as that's all I have」。

三十五年後，同一個專案以 2,652 人在九週內完成的 16,418 個提交結束了 7.2 版，LWN 辨識出 249 家公司為其中一部分工作付錢 [2]。這個業餘嗜好並非偶然變得龐大而專業，而是因為有人開始付錢。

當時有個明顯的競爭者。柏克萊的 BSD 已經有 PC 版本 386BSD，卻困在一場關於 Net/2 磁帶法律地位的漫長訴訟中，訴訟雙方是加州大學與 Unix 程式碼的擁有者，先是 AT&T，後來是 Novell。和解直到 1994 年才達成，並要求刪除三個被認定為「encumbered」的檔案 [3]。1993 年 11 月，Linus 告訴《Meta》雜誌，他從沒試過 386BSD：「If 386BSD had been available when I started on Linux, Linux would probably never had happened」[4]。Linux 是在一所大學與一家公司的訴訟所打開的窗口中長大的。這也不會是這段歷史中的最後一場訴訟。

最早的薪水來自販售這套系統的人。Red Hat 在 1999 年 8 月 11 日上市，以每股 14 美元發行 600 萬股 [5]；第一個交易日開盤價為 48.50 美元 [6]。2001 年 11 月，Marcelo Tosatti 主持 2.4 穩定系列（當時伺服器上跑的那一版）的郵件，寄件地址是 marcelo@conectiva.com.br [7]。Conectiva 是一家位於巴西庫里提巴的發行版公司。核心穩定樹的維護者，領的是一家巴西公司的薪水。

2000 年 12 月，根據 LWN 整理的 News.com 與 ZDNet 報導，IBM 宣布將在 2001 年投入 10 億美元於 Linux [8]。我找不到 IBM 的原始新聞稿。IBM 技術副總裁 Irving Wladawsky-Berger 表示，公司已經投資了大約 10 億，這個數字還會成長；LWN 在同一期評論：「IBM is not a philanthropic organization. What they invest now they expect to get back」[9]。IBM 自 1999 年 8 月起設有 Linux Technology Center，到 2001 年約有 185 名員工 [10]。

2000 年 8 月 31 日，HP、Intel、IBM 與 NEC 創立了 Open Source Development Lab（OSDL），Caldera、Dell、Red Hat、SuSE、SGI 等公司擔任贊助者 [11]。2003 年 6 月 17 日，Linus 離開任職六年多的處理器廠商 Transmeta，成為第一位「OSDL Fellow」。新聞稿說他將「exclusively on leading the development of Linux」工作 [12]。核心的創造者第一次領錢專心照顧核心，而付錢的是一個製造商聯盟。2007 年 1 月，OSDL 與 Free Standards Group 合併，成為 Linux 基金會 [13]。

金錢也透過收購易手。2003 年 11 月 4 日，Novell 宣布收購 SUSE：「Novell will pay $210 million in cash」。同一份公告中，IBM 承諾投資 5,000 萬美元購買 Novell 的優先股 [14]。

在 Linus 加入 OSDL 的三個月前，也就是 2003 年 3 月，SCO Group 在猶他州法院控告 IBM 盜用營業秘密、侵權干擾、不正當競爭與違約，求償「no less than $1 billion」[15]。背後的指控是 Unix 程式碼經由 IBM 流入了 Linux。2007 年 8 月，SCO 自己向美國證券交易委員會（SEC）申報，它在對 Novell 的訴訟中，關於 UNIX 著作權歸屬的判決結果不利 [16]。針對 IBM 的訴訟直到 2021 年才結束，IBM 與 SCO 的破產管理人以 1,425 萬美元和解 [17]。

核心的回應不是法律上的，而是流程上的。2004 年 5 月 23 日，Linus 提議每個修補都附上一行 Signed-off-by: [18]。那封郵件開頭提到「this crazy company called SCO」，說這家公司似乎很難相信開放原始碼比「than their five engineers do」做得更好。簽名的人依據 Developer's Certificate of Origin 證明，這份貢獻是自己寫的，或者自己有權以開放授權轉交 [19], [20]。簽名誕生於一場訴訟的防禦。二十年後，正是它讓人能逐一統計每個修補背後是誰在替誰工作。下一節幾乎所有統計數字，都以它為原料。

版本控制也來自一家公司。在 2.5 系列期間，Linus 採用了 BitMover 公司的 BitKeeper。它是專有軟體，只以二進位形式發布，對開放原始碼專案提供附帶限制的免費授權 [21]。2003 年 11 月，有人在核心 CVS 鏡像的 wait4() 函式中插入了兩行程式 [22]：

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
        retval = -EINVAL;

這是一個 =，而不是 ==。這一行不是在檢查使用者是否為 root，而是把呼叫者變成 root。任何人帶著那兩個旗標呼叫 wait4()，就能取得完整權限。這個修改之所以被抓到，是因為 CVS 中每個合法提交都對應到一個 BitKeeper 變更集，而這個沒有。發現的人是 BitMover 的老闆 Larry McVoy [22]。

2005 年 4 月，免費版本結束了。LWN 記錄壓垮駱駝的最後一根稻草是「a certain high-profile developer who refused to stop reverse engineering work while simultaneously doing some work for OSDL」[21]。4 月 6 日，Linus 寫道「the kernel team is looking at alternatives」，並請大家不要責怪 BitMover [23]。隔天，他為一個新工具做了第一個提交：「Initial revision of "git", the information manager from hell」[24]。4 月 16 日，核心以提交 1da177e4「Linux-2.6.12-rc2」遷入 Git，沒有帶上先前的歷史，那段歷史加起來大約有「about 3.2GB」[25]。

同一時期，開發模式也改變了。在 2004 年 7 月的 Kernel Summit 上，Andrew Morton 主張讓 2.6 系列持續變動，並讓「the distributors do the final stabilization work」[26]。奇數版號的開發系列就此結束，穩定化的工作交給了販售支援服務的人。

日期	事件	誰付錢或促成
1991 年 8 月	在 comp.os.minix 發文	沒有人：一個業餘嗜好
1993 年 11 月	Linus 說他開始時 386BSD 還無法取得	Net/2 訴訟
1999 年 8 月	Red Hat 上市；Linux Technology Center	Red Hat；IBM
2000 年 8 月	OSDL 成立	HP、Intel、IBM 與 NEC
2000 年 12 月	2001 年投入 Linux 10 億美元	IBM
2001 年 11 月	2.4 系列由 Conectiva 的信箱主持	Conectiva
2003 年 3 月	SCO 控告 IBM	SCO
2003 年 6 月	Linus 成為第一位 OSDL Fellow	OSDL，也就是其會員公司
2003 年 11 月	Novell 收購 SUSE；`wait4()` 後門企圖	Novell 與 IBM；BitKeeper 抓到
2004 年 5 月	Developer's Certificate of Origin 與 `Signed-off-by`	回應 SCO 訴訟
2005 年 4 月	免費 BitKeeper 結束；Git 誕生	BitMover

到了 2005 年，核心有一位由製造商聯盟付薪的創造者、一條因企業訴訟而生的簽名規則，以及一個誕生於授權爭議的版本控制工具。起源是個人的，讓專案得以成長的基礎設施卻不是。

誰在寫核心

我曾經寫過，核心大概有 80% 是大型科技公司做的。我去查證了。數字幾乎是對的，用詞卻不對。

2007 年 2 月，LWN 的編輯 Jonathan Corbet 寫了幾個腳本，想弄清楚 2.6.20 的程式碼從哪裡來。方法簡單，而且他自己承認並不完美，因為「very few developers say 'I wrote this on behalf of my employer.'」凡是電子郵件地址指向某家公司的修補，都算作那家公司的工作 [27]。此後 LWN 每個版本都重做這項分析，而表格中有兩列比其他的更重要。「(None)」是 LWN 確知在自己時間工作的開發者；「(Unknown)」是無法辨識的人，混合了志願者和使用個人信箱的公司員工。早在 2007 年，結論就是「at least 65% of the code which went into 2.6.20 was created by people working for companies」。之所以說「至少」，是因為有 25.0% 的提交屬於「(Unknown)」，而假設這些人全是志願者，被認為是「an unlikely result」[27]。

Linux 基金會的年度報告由同一位 Corbet 與 Greg Kroah-Hartman 撰寫，得出相同的結論。2008 年的報告估計，有 70% 到 95% 的開發者是領薪水的，足以打破「'hobbyist' myth present from the start of open source development」[28]。2012 年是 75% 的開發工作 [29]，2015 年超過 80% [30]。2017 年的報告最直接：即使假設所有「unknown」的人都是無償工作，「well over 85 percent of all kernel development is demonstrably done by developers who are being paid for their work」。無償的比例從 2012 年報告的 14.6% 降到 8.2%，給出的解釋與就業市場有關：「kernel developers are in short supply, so anybody who demonstrates an ability to get code into the mainline tends not to have trouble finding job offers」[31]。成功的志願者會變成員工。

LWN 的系列數據顯示，沒有雇主的工作在 2009 年達到高峰，佔 2.6.30 提交的 16.8% [32]。之後這個比例幾乎一路下滑：3.0 是 12.0% [33]，4.0 是 8.6% [34]，6.0 是 3.1% [35]。有一個顯著而有啟發性的例外。在 2024 年 1 月的 6.7 版，「(None)」跳到 18.1%。那不是志願者回來了，而是 bcachefs：Kent Overstreet 以「on his own, supported by interested users on Patreon」的方式開發的檔案系統，整段開發歷史一次併入 [36]。一個人就拉動了整個核心的平均值，而同一個 bcachefs 不到兩年後就離開了主線，下文談張力的一節會說明。

版本	發布日期	提交數（LWN）	無雇主「(None)」	未辨識「(Unknown)」
2.6.20	2007-02-04	4,983	7.7%	25.0%
2.6.30	2009-06-09	11,733（統計至 rc7）	16.8%	10.1%
3.0	2011-07-21	9,007（統計至 rc7）	12.0%	6.3%
4.0	2015-04-12	略多於 10,000	8.6%	7.1%
6.0	2022-10-02	15,402	3.1%	6.6%
6.7	2024-01-07	17,284	18.1%（bcachefs）	6.7%
6.18	2025-11-30	13,710	4.6%	9.5%
7.2	2026-08-16	16,418	4.5%	16.7%

日期取自核心儲存庫中的標籤 [37]；百分比以提交數計算，來源是 LWN 各版本的文章 [27], [32], [33], [34], [35], [36], [38], [2]。就 2025 全年（6.13 到 6.18）而言，LWN 統計出 5.3% 無雇主、8.5% 未辨識 [38]。

7.2 的「(Unknown)」達 16.7%，是近期系列中最高的數字，LWN 自己將它「partially, at least」歸因於「ongoing flood of new developers entering the kernel community」。這一版有 613 位首次貢獻者，創下紀錄。同一個週期中，有 1,111 個變更（「under 7% of the total」）帶有 Assisted-by 標記，也就是聲明使用了 AI 工具，而 7.1 只有 301 個 [2]。未知的部分正在增加，其中一部分是帶著語言模型一起來的。

以下是 7.2 版依提交數排列的公司 [2]：

雇主	提交數	比例
(Unknown)	2,743	16.7%
Intel	1,512	9.2%
Google	1,191	7.3%
Red Hat	873	5.3%
AMD	813	5.0%
Qualcomm	767	4.7%
(None)	743	4.5%
NVIDIA	535	3.3%
Meta	441	2.7%
(Consultant)	429	2.6%
SUSE	358	2.2%
Renesas Electronics	328	2.0%
IBM	307	1.9%
Kylin	278	1.7%
NXP Semiconductors	264	1.6%

回到我那句話。扣掉「(Unknown)」與「(None)」，7.2 的 16,418 個提交中還剩 12,932 個，也就是 78.8%，來自所屬單位已辨識的人：公司、顧問公司、大學 [2]。「大約 80%」說得通，「大型科技公司」卻說不通。前五大具名公司 Intel、Google、Red Hat、AMD 與 Qualcomm 合計 5,156 個提交，佔 31.4%；前十大佔 43.4%。其餘分散在 249 個雇主之間：Renesas、NXP 等晶片廠，BayLibre、Bootlin 等顧問公司，SUSE、Kylin 等發行版。若以變更的行數計算，排名就不同了：AMD 以 22.4% 居首 [2]。核心不是由幾家公司寫的，而是由一整個產業寫的。

寫程式只是權力的一半，另一半是接受。維護者把修補套用到自己的樹時，會加上自己的 Signed-off-by；統計這些非作者的簽核，就能看出誰在控制什麼能進入核心。2009 年，其中 42.4% 來自 Red Hat 的員工 [32]。2017 年，「over half of the patches going into the kernel pass through the hands of developers employed by just five companies」[31]。2023 年，LWN 重算一次，得到同樣的結論：「over 50% of the changes going into the kernel pass through the hands of maintainers working for just five companies」[39]。在 2026 年 2 月的 6.19 版，Meta 居首，而沒有雇主的維護者簽核只佔 1.6% [40]。

雇主	2.6.30（2009）	4.8 至 4.13（2017）	6.19（2026）
Red Hat	42.4%	20.6%	4.9%
Intel	9.5%	9.7%	9.5%
Google	6.6%	7.4%	9.9%
Linux 基金會	2.2%	9.1%	3.4%
Novell，後為 SUSE	13.8%（Novell）	2.4%（SUSE）	3.2%（SUSE）
Linaro	未列出	7.9%	6.0%
Meta（原 Facebook）	未列出	2.0%	11.8%
Arm	未列出	1.3%	8.9%
AMD	未列出	2.4%	6.5%
無雇主	4.1%	3.9%	1.6%

本表列出非修補作者的 Signed-off-by，也就是接受程式碼的人 [32], [31], [40]。「未列出」表示該公司不在該期公布的名單中。

那麼，誰在讀進入核心的東西？提交的標記能說明一部分。我在 git log 中統計了至少帶有一個 Reviewed-by、Acked-by 或 Tested-by 的提交比例 [37]：

版本	非合併提交	Reviewed-by	Acked-by	Tested-by	至少一種
2.6.20	4,768	0.0%	10.2%	0.1%	10.3%
3.0	9,153	7.5%	13.6%	3.8%	22.4%
4.0	10,346	16.8%	15.5%	5.6%	34.1%
5.0	12,808	31.6%	16.6%	5.7%	46.2%
6.0	15,402	39.2%	16.2%	9.0%	52.9%
7.0	14,251	53.8%	13.3%	9.4%	64.1%
7.2	16,418	48.2%	13.6%	8.0%	58.6%

方法如下：在 2026 年 10 月 2 日取得的 torvalds/linux 儲存庫副本中，對每個版本的標籤之間執行 git log --no-merges，統計訊息中有以上三種標記開頭之行的提交。在較舊的版本中，git log 的計數與 LWN 略有差異，因為 LWN 採用不同的切分方式。就 6.18 而言，LWN 記錄 53.6% 帶有 Reviewed-by，並稱這個數字「typical」[38]。所以在 2026 年，每五個提交中有兩個沒有任何審查標記就進入核心，只帶著作者與套用者的簽名。在 7.2 中，這樣的提交有 6,794 個。這不代表沒有人讀過：很多審查發生在郵件論壇上卻沒有變成標記，而套用修補的維護者也會讀自己套用的東西。但「任何人都能審查核心」這句話需要加個星號。任何人都可以，然而有紀錄顯示作者與維護者以外還有人看過的，只有略多於一半。

學術研究循其他途徑得到相近的數字。Urs Lerch 在柏林工業大學的博士論文分析了 2007 年核心的全部紀錄，結論是「commercial companies contribute 75 percent to the kernel development」[41]。一項 2014 年針對整體開放原始碼的研究估計，大約一半的工作是有償的 [42]。核心遠高於這個平均。

以提交數計算，每五個裡有四個來自某人薪資名單上的人；以接受的權力計算，超過 95%。志願者確實存在，可以量測，而且位在邊緣：7.2 程式碼的 4.5%，以及 6.19 鑰匙的 1.6%。

按訂單打造：源自企業的子系統

1991 年的那則貼文說，這個系統「is NOT protable (uses 386 task switching etc)」，而且大概永遠只支援 AT 硬碟 [1]。到了 7.2，核心有 3,770 萬行 C、Rust 與組合語言的原始碼；其中 69.0% 在 drivers/，arch/ 目錄有 21 個子目錄 [37]。我直接從 Git 物件統計了 v7.2 標籤中的 .c、.h、.rs 與 .S 檔案。這些目錄每一個背後都有人在付錢。本節逐一檢視最能改變 Linux 面貌的子系統，都依照同一個脈絡：一家公司的問題、解決它的機制、落敗的替代方案，以及進入主線的過程。

cgroups 與 namespaces：容器的基礎

2006 年 9 月 14 日，Rohit Seth 向 LKML 寄出一個名為 containers 的修補的介紹。理由來自資料中心：「Commodity HW is becoming more powerful」，要在同一台機器上執行不同的工作負載，需要「a notion of limits for each workload in Linux kernel」[43]。Seth 用的是 Google 的信箱，之後這項工作交給了 Paul Menage，他「like Rohit, posts from a google.com address」[44]。多年後，Google 關於其內部調度系統 Borg 的論文寫道：「all Borg tasks run inside a Linux cgroup-based resource container」[45]。

在 2007 年的 Ottawa Linux Symposium 上，Menage 與 IBM Linux Technology Center 的 Balbir Singh、Srivatsa Vaddagiri 一同發表了一個建立在既有 cpusets 之上的通用框架 [46]。這個設計刻意保持低成本：每個任務只多一個指向共享 css_group 的指標，「the space overhead is one pointer per task, and the time overhead is one reference count operation per fork()/exit()」。當時的替代方案中，ResGroups 落敗的原因是「the additional overheads that it introduces are unnecessary」[46]。Menage 的提交進入了 2008 年 1 月發布的 2.6.24 [47]。

第一版允許多個獨立的階層。結果行不通：Tejun Heo 撰寫的第二版文件說，這種彈性「wasn't useful in practice」[48]。統一階層在 3.16 以實驗性質加入 [49]，並在 4.5 被認定為穩定 [50]。介面仍然是一個檔案系統 [48]：

mkdir /sys/fs/cgroup/job
echo "+memory +cpu" > /sys/fs/cgroup/cgroup.subtree_control
echo 512M > /sys/fs/cgroup/job/memory.max
echo $$ > /sys/fs/cgroup/job/cgroup.procs

2018 年，Facebook 加入了 PSI，用來量測任務因等待 CPU、記憶體或 I/O 而停滯的時間。這項功能「developed by Facebook engineer Johannes Weiner」[51]，在提案時已經「used within Facebook for some time」[52]，並進入了 4.20 [53]。

cgroups 限制一個行程能用多少，namespaces 限制它能看到什麼。這個概念來自研究型 Unix：Bell Labs 的 Rob Pike、Ken Thompson 等人所寫的〈The Use of Name Spaces in Plan 9〉[54]。Eric Biederman 在 2006 年的 OLS 上引用了這個靈感，並瞄準當時的替代方案：「Hypervisor solutions like Xen are nice but they impose a performance penalty」[55]。namespaces 在將近十八年間一塊一塊地進入核心：mount 在 2.4.19，UTS 與 IPC 在 2.6.19，PID 在 2.6.24，網路大約在 2.6.29 完成，user 在 3.8 [56]，cgroup 在 4.6 [57]，time 在 5.6 [58]。作者來自四面八方：UTS 出自一個 @us.ibm.com 地址 [59]；PID 是「developed by the OpenVZ team with the help of IBM」[60]；cgroup namespace 在 Google 寫成；time namespace 則由 OpenVZ 與 Arista 合作完成 [57], [58]。這項工作中也有一位巴西人：Glauber Costa 擴充 cgroups 記憶體計量的提交，在 2013 年出自 @parallels.com [37]。成為業界標準的容器，在核心裡就是這兩個部件的組合。

KVM：從 Qumranet 到 Red Hat

2006 年 10 月 19 日，Avi Kivity 向 LKML 介紹了一個名為 KVM 的驅動程式。構想是利用 Intel 與 AMD 剛加進處理器的虛擬化擴充，其餘一切交給 Linux：「Each virtual machine is a process on the host; a virtual cpu is a thread in that process. kill(1), nice(1), top(1) work as expected.」這個驅動程式在核心模式與使用者模式之外，加入了「a third execution mode」，也就是客體模式；任何對 I/O 裝置的存取都會被攔截並交回使用者空間，由一個稍作修改的 QEMU 模擬硬體 [61]。Linux 的排程器、記憶體管理與行程工具，都不需要新的程式碼就能用在虛擬機上。

2007 年 OLS 的論文由四位 Qumranet 工程師與一位 IBM 工程師署名，描述了其餘部分：一個函式指標表 kvm_arch_ops 區分 Intel 與 AMD；影子分頁表讓客體記憶體保持一致；髒頁紀錄讓執行中的虛擬機可以遷移；而且「In kvm, I/O virtualization is performed by userspace」[62]。對使用者來說，一切都是對 /dev/kvm 的 ioctl [63]：

int kvm  = open("/dev/kvm", O_RDWR);
int vm   = ioctl(kvm, KVM_CREATE_VM, 0);
int vcpu = ioctl(vm, KVM_CREATE_VCPU, 0);
struct kvm_run *run = mmap(NULL, ioctl(kvm, KVM_GET_VCPU_MMAP_SIZE, 0),
                           PROT_READ | PROT_WRITE, MAP_SHARED, vcpu, 0);
for (;;) {
        ioctl(vcpu, KVM_RUN, 0);          /* 執行客體，直到它退出 */
        if (run->exit_reason == KVM_EXIT_IO || run->exit_reason == KVM_EXIT_MMIO)
                emulate_device(run);      /* 由使用者空間扮演硬體 */
}

從第一封郵件到穩定版本不到四個月：這個出自 avi@qumranet.com 的提交，進入了 2007 年 2 月 4 日發布的 2.6.20 [64]。競爭者 Xen 的 dom0 支援直到 2011 年的 3.0 才被接受 [65]。2008 年 9 月，Red Hat 以「approximately $107 million in cash」收購 Qumranet [66]。在 3.0 中，MAINTAINERS 列出兩位 KVM 維護者：Avi Kivity 與 Marcelo Tosatti（就是 2.4 那位），兩人都使用 @redhat.com 信箱 [67]。Glauber Costa 也以 @redhat.com 寫了 kvmclock 的一部分，那是 KVM 的半虛擬化時鐘 [37]。

如今，KVM 支撐著最大的幾朵雲。AWS 說 Nitro 的 hypervisor「is built on core Linux Kernel-based Virtual Machine (KVM) technology」[68]。Google Cloud 執行 KVM，但使用自己的虛擬機監控程式，因為「Google does not use QEMU」[69]。在 7.2 中，KVM 由使用 Red Hat 信箱的 Paolo Bonzini 維護，x86 的 KVM 另由 Google 的 Sean Christopherson 共同維護；兩個條目都標示為 Supported [70]。

eBPF 與 XDP：核心裡的程式

最初的 BPF 出自 1992 年，由 Lawrence Berkeley Laboratory 的 Steven McCanne 與 Van Jacobson 設計：一個在核心內過濾封包、以暫存器為基礎的虛擬機，「10 to 150 times faster than Sun's NIT」[71]。二十年來，它主要為 tcpdump 服務，用途不多。

2014 年 3 月，來自 @plumgrid.com 的 Alexei Starovoitov 以一套「designed to be JITed with one to one mapping」的指令集改寫了內部直譯器 [72]，進入了 3.15。同年 9 月推出了 bpf() 系統呼叫與 maps，也就是核心內程式與使用者空間共享的資料結構，進入了 3.18 [73]。當時有個競爭者 ktap，是另一個用於追蹤的虛擬機。LWN 這樣總結這場僵局：「Putting one virtual machine into the kernel for tracing is a hard sell; adding two of them is not really seen as an option by anybody involved」[74]。最後留下的是 BPF。

讓人能接受在核心裡執行使用者程式碼的，是驗證器（verifier）。它把程式當作一張無環圖走訪，拒絕迴圈，並追蹤每個暫存器與堆疊位置的狀態，然後才接受載入；之後再由 JIT 轉譯成原生指令 [75]。

2016 年 7 月，同樣來自 @plumgrid.com 的 Brenden Blanco 加入了 XDP，這種程式類型在核心為封包配置資料結構之前，就在網路驅動程式中執行 [76]，進入了 4.8。2018 年 CoNEXT 上的 XDP 論文，作者來自 Red Hat、Cilium 以及其他公司與大學，量測到單核心每秒 2,400 萬個封包，而把網路卡從核心拿走的 DPDK 是 4,350 萬個 [75]。這個取捨是刻意的：犧牲一些原始速度，換來封包留在核心裡，與防火牆、路由和其他功能一起運作。

Starovoitov 後來加入 Facebook，2016 到 2018 年間從那裡提交程式碼 [37]。2019 年，這家公司在「about 40 BPF programs running on each server, with another 100 that are demand loaded」[77]。2020 年，Google 的 KP Singh 在 5.7 中把 BPF 帶進了核心的安全掛鉤 [78]，儘管 Casey Schaufler 反對：「This effectively exposes the LSM hooks as external APIs. It would mean that we can't change or delete them」[79]。2024 年 10 月，這套指令集成為 IETF 標準 RFC 9669，其中註明 eBPF「is no longer an acronym for anything」[80]。

io_uring：Meta 寫的，Google 關掉

Linux 原本就有非同步 I/O 介面 AIO，但它對使用頁面快取的人並不好用：「buffered I/O has always been a bit of a sore spot for Linux AIO」[81]。2019 年 1 月，區塊層維護者 Jens Axboe 提出了另一條路 [82]。Axboe 待過 SUSE、Oracle 與 Fusion-io，2014 到 2017 年間以 @fb.com 提交 [37]；他在 GitHub 的公開檔案至今仍把 Facebook 列為所屬公司 [83]。

整個機制可以用提交說明中的一句話概括：「The submission queue (SQ) and completion queue (CQ) rings are shared between the application and the kernel. This eliminates the need to copy data back and forth to submit and complete IO」[82]。應用程式把請求寫進一個 io_uring_sqe 陣列，把索引放進提交環，然後為整批請求只呼叫一次 io_uring_enter()；結果以 io_uring_cqe 的形式出現在完成環中，應用程式不需系統呼叫就能讀取。

 應用程式：在陣列中填寫 SQE，把索引寫入 SQ ring
      |
      |  io_uring_enter(fd, n, ...)：n 個請求只需一次系統呼叫
      v
 核心：取用 SQ ring，執行 I/O，每個完成的請求寫入一個 CQE
      |
      v
 應用程式：從 CQ ring 讀取 CQE

 SQ ring、CQ ring 與 SQE 陣列都位於共享記憶體（mmap）

每個完成事件是一個 16 位元組的結構，啟用 IORING_SETUP_CQE32 選項時大小加倍 [37]：

struct io_uring_cqe {
	__u64	user_data;	/* sqe->user_data value passed back */
	__s32	res;		/* result code for this event */
	__u32	flags;
	__u64	big_cqe[];	/* 僅在 IORING_SETUP_CQE32 時存在 */
};

它在 2019 年 5 月進入 5.1。帳單來得比較晚。2023 年 6 月，Google 公布，在其核心漏洞利用獎勵計畫 kCTF 中，「60% of the submissions exploited the io_uring component of the Linux kernel (we paid out around 1 million USD for io_uring alone)」。這家公司在 ChromeOS 上停用 io_uring，在 Android 上封鎖應用程式的存取，並寫道：「It is disabled on production Google servers」[84]。兩個月後，Google 工程師 Matteo Rizzo 送出了 io_uring_disabled 這個 sysctl，進入了 6.6 [85]。一家公司的人寫的子系統，由另一家公司的人寫了它的開關。

Btrfs 與 XFS：掛著識別證的檔案系統

2007 年 6 月 12 日，Chris Mason 宣布了一個新的檔案系統：「After the last FS summit, I started working on a new filesystem that maintains checksums of all file data and metadata.」程式碼有「a sparsely commented 10,547 lines」[86]。Btrfs 把一切組織成寫時複製的 B 樹：沒有任何東西會被原地覆寫，而快照就是一個與前一版共享區塊的新根節點 [87]。它在 2009 年 3 月進入 2.6.29 [88]。

Btrfs 的歷史跟著 Mason 的識別證走：他有 972 個提交出自 @oracle.com，44 個出自 @fusionio.com，從 2013 年 12 月起有 148 個出自 @fb.com、34 個出自 @meta.com [37]。Josef Bacik 走了類似的路，從 Red Hat 到 Fusion-io 再到 Facebook [37]。在 Facebook，Btrfs 成了內部容器的根：「Containers in this system use Btrfs for the root filesystem」[89]。各發行版選了邊。Red Hat 在 RHEL 7.4 中棄用 Btrfs，並警告它「will be removed in a future major release」[90]。Fedora 則在 Bacik 也是提案作者之一的情況下，於 Fedora 33 將 Btrfs 設為預設 [91]。在 7.2 中，Btrfs 的兩位維護者是 @fb.com 的 Mason 與 @suse.com 的 David Sterba [70]。

XFS 來自另一個時代。Silicon Graphics 在 1996 年的 USENIX 上描述了它：獨立的配置群組、管理可用空間的 B+ 樹，以及延遲配置，也就是系統「simply reserves blocks in the file system for the data buffered in memory」[92]。這份程式碼在 2002 年 9 月的 2.5.36 進入 Linux，Linus 的公告這樣總結：「Big patch, most of it due to the XFS merge」[93]。多年後，Red Hat 將它描述為「originally designed at Silicon Graphics, Inc.」的檔案系統，並讓它成為「the default file system for Red Hat Enterprise Linux 7」[94]。在掛載狀態下檢查檔案系統的 scrub 功能，始於 2017 年 @oracle.com 的 Darrick Wong [95]。

排程器：O(1)、CFS、EEVDF 與 sched_ext

排程器是核心中爭議最多的程式碼，而這些爭議比任何表格都更能說明本文的論點。

2002 年 1 月，Ingo Molnar 宣布了「a pretty radical rewrite of the Linux scheduler」，也就是 O(1) 排程器，修補放在 redhat.com/~mingo [96]。2007 年 3 月，Con Kolivas 提出 RSDL，一個沒有互動性啟發式、追求完全公平的排程器 [97]。一個月後，Molnar 以完全公平排程器（CFS）回應，並且說得很清楚：「i'd like to give credit to Con Kolivas for the general approach here: he has proven via RSDL/SD that 'fair scheduling' is possible and that it results in better desktop scheduling」。CFS 用「a time-ordered rbtree to build a 'timeline' of future task execution」取代了優先權佇列 [98]，並進入了 2.6.23 [99]。勝出的是 Kolivas 的構想，進入核心的卻是那位 Red Hat 工程師的程式碼。

十六年後，Peter Zijlstra 用 EEVDF 取代了 CFS 的核心部分。EEVDF 是 Old Dominion University 的 Ion Stoica 與 Hussein Abdel-Wahab 在 1995 年發表的演算法 [100]。目標是刪掉「a whole [bunch] of icky heuristics code」，換成定義明確的策略 [101]。每個任務都有一個 lag，也就是它應得與實際得到的 CPU 時間之差；EEVDF「picks tasks with lag greater or equal to zero and calculates a virtual deadline (VD) for each, selecting the task with the earliest VD to execute next」[102]。它在 6.6 進入核心，提交的簽名是「Peter Zijlstra (Intel)」[103]。

2023 年，Tejun Heo 提出的東西恰恰與更好的排程器相反：讓每個人用 BPF 寫自己的排程器。與 David Vernet、Josh Don、Barret Rhoden 共同撰寫的 sched_ext [104]，得到排程器維護者這樣的回應：「I hate all of this. Linus NAK'ed loadable schedulers a number of times in the past and this is just that again -- with the extra downside of the whole BPF thing on top」[104]。2024 年 6 月，Linus 越過維護者做出決定：「I honestly see no reason to delay this any more」[105]。提交中 Vernet 是共同作者，信箱是 @meta.com，另有三個來自 @google.com 的 Acked-by [106]；Heo 在 GitHub 上的所屬公司是 Facebook [107]。它進入了 6.12。BPF 排程器是一張由核心在適當時機呼叫的函式表，任何錯誤都會讓系統退回預設排程器 [108]：

/* kernel/sched/ext/internal.h，Linux 7.2（節錄） */
struct sched_ext_ops {
	s32 (*select_cpu)(struct task_struct *p, s32 prev_cpu, u64 wake_flags);
	void (*enqueue)(struct task_struct *p, u64 enq_flags);
	void (*dequeue)(struct task_struct *p, u64 deq_flags);
	void (*dispatch)(s32 cpu, struct task_struct *prev);
	void (*running)(struct task_struct *p);
	void (*stopping)(struct task_struct *p, bool runnable);
	s32 (*init_task)(struct task_struct *p, struct scx_init_task_args *args);
	/* ... */
	u32 timeout_ms;
	char name[SCX_OPS_NAME_LEN];
};

辯論雙方都是企業員工：一方是以 Intel 名義簽名的維護者，另一方是與 Meta 和 Google 有關的作者。仲裁的是 Linus，他在 Linux 基金會的薪資名單上列為「Fellow」[109]。

驅動程式：核心首先是硬體支援

2015 年 7 月 5 日，Linus 在發布 4.2-rc1 時提醒，這看起來是「the biggest rc we've ever had, with over a million lines added」。接著他解釋：「just those register descriptor headers alone are about 41% of the entire patch」。AMD 新驅動程式 amdgpu 的其餘部分又佔了 8%，讓核心處於「in the somewhat odd situation where a single driver is about half of the whole rc1 in number of lines」[110]。amdgpu 的核心提交出自 @amd.com 的 Alex Deucher [111]。

十一年後，我統計了 7.2 中的 drivers/gpu/drm/amd 目錄樹：6,343,652 行，佔核心全部原始碼的 16.8%。光是 include/asic_reg/ 中的暫存器標頭檔就有 4,977,963 行，佔整個核心的 13.2% [37]。單一驅動程式的目錄樹，行數比 arch/、fs/、net/ 與 kernel/ 加起來的 601 萬行還多 [37]。其中大部分描述的是一家公司晶片的暫存器，而它的兩位維護者在一個 Supported 條目中，都使用 @amd.com 信箱 [70]。

Intel 有兩個圖形驅動程式。i915 有 418,774 行，支援 Tiger Lake 以後 GPU 的 xe 有 139,555 行 [37]。xe 在 6.8 進入核心，它的第一個提交聲明了 16 位共同開發者：12 位使用 Intel 信箱，一位來自 Red Hat，一位來自 Collabora [112]。

NVIDIA 長期是反例。nouveau 是「a reverse-engineered driver for Nvidia graphic cards」，2010 年在 2.6.33 進入 staging [113]。2022 年 5 月，NVIDIA 以 GPL 與 MIT 雙授權釋出了自己的核心模組，但放在主樹之外 [114]。2025 年，以 Rust 撰寫的 nova-core 進入 6.15，它「intended to serve as the successor of Nouveau for all GSP-based GPUs」[115]。作者 Danilo Krummrich 在 2022 到 2024 年間以 @redhat.com 提交 [37]，在 7.2 中與 @nvidia.com 的 Alexandre Courbot 共同維護 [70]。

網路方面，模式重複出現。Mellanox 為 Connect-IB 網卡寫的驅動程式 mlx5，2013 年進入 3.11，作者是 @mellanox.com 的 Eli Cohen [116]。2020 年 4 月，NVIDIA 以 70 億美元完成收購 Mellanox [117]。7.2 中 mlx5 的四位維護者都使用 @nvidia.com 信箱 [70]。

架構：每種處理器，一個贊助者

IBM 來得很早。大型主機的移植版本 s390 出現在 2000 年 1 月發布的 2.2.14 修補中，標頭寫著「Copyright (C) 1999 IBM Deutschland Entwicklung GmbH, IBM Corporation」[118]。給 POWER 伺服器用的 ppc64，則在 2002 年 2 月的 2.5.5 進入開發系列，同樣帶有 IBM 著作權的程式碼 [119]。在 7.2 中，s390 與 PowerPC 的維護者都使用 @linux.ibm.com 信箱，兩個條目都是 Supported [70]。

ARM 是一團混亂的例子。2010 年，LWN 在 ARM 目錄中數到「nearly 70 different sub-architectures」，每一個對應一種晶片或 SoC；同一篇文章報導了由 Arm、Freescale、IBM、Samsung、ST-Ericsson 與 Texas Instruments 創立的 Linaro，預算為「tens of millions of dollars, much of which will pay for 80 employees」[120]。2011 年 3 月，Linus 失去了耐性：「Gaah. Guys, this whole ARM thing is a f*cking pain in the ass」[121]。64 位元支援由 Arm 自己提供，是 Catalin Marinas 的「36-part patch set」[122]，第一個提交出自 Marinas 與 Will Deacon 的 @arm.com 信箱 [123]，並在 2012 年 12 月進入 3.7。Qualcomm MSM 系列的支援，由 Google 工程師 Brian Swetland 帶進 2.6.25 [124]；到了 2.6.35，這個平台的三位維護者都使用 @codeaurora.org 信箱 [125]。

RISC-V 照著同樣的劇本走。第一個提交出自 Palmer Dabbelt，時間是 2017 年 7 月 [126]；4.15 的 MAINTAINERS 檔案列出他與 Albert Ou，使用 @sifive.com 信箱，條目標示為 Supported，這個狀態在該檔案中的定義正是「Someone is actually paid to look after this」[127]。

PREEMPT_RT：在主樹外的二十年

2004 年 10 月 13 日，Ingo Molnar 發表了他所稱的「the first correct conversion of the Linux kernel to a fully preemptible (fully mutex-based) preemption model」，同樣放在 redhat.com/~mingo [128]。這個構想說來容易做來難：在即時核心中，「spinlock_t is mapped to a separate implementation based on rt_mutex」，也就是一種會睡眠、會繼承優先權的鎖，而中斷處理程式則在執行緒中執行。只有 raw_spinlock_t 繼續自旋，它是「a strict spinning lock implementation in all kernels, including PREEMPT_RT kernels」[129]。

這花了二十年。這個修補長期存在於主樹之外，各部分逐步進入：執行緒化中斷由 @linutronix.de 的 Thomas Gleixner 在 2.6.30 加入 [130]，CONFIG_PREEMPT_RT 符號在 5.3 加入 [131]。2015 年，Linux 基金會成立了一個資助這項工作的專案，Google 是創始白金會員，National Instruments、OSADL 與 Texas Instruments 是金級會員；維護這個分支「for more than a decade」的 Gleixner 成為 Linux 基金會 Fellow [132]。2022 年，Intel 收購了 Linutronix，Intel 自己形容它是「the architect of PREEMPT_RT (Real Time)」[133]。最後的障礙是 printk，它被改寫成不依賴全域鎖的主控台 [134]；啟用 x86 的提交記錄道，「with the recent printk changes, the last known road block has been addressed」[135]。2024 年 9 月，Gleixner 的 pull request 寫道：「After twenty years of development we finally reached the point to enable PREEMPT_RT support in the mainline kernel」[136]。x86 提交的理由開頭只有一句：「It is really time.」[135]。它進入了 6.12。就 2025 全年而言，Linutronix 以 1,149 個提交名列提交數前 20 名的雇主 [38]。

Rust for Linux：有贊助的實驗

2021 年 4 月，Miguel Ojeda 送出了在核心中使用 Rust 的提案。Linus 抱怨了個別修補，但說：「on the whole I don't hate it」[137]。同年 4 月，Let's Encrypt 背後的非營利組織 Internet Security Research Group 給了 Ojeda 一份為期一年的全職合約，「made possible through financial support from Google」[138]。這項支援在 2022 年 12 月進入 6.1，那個 pull request 感謝了 173 個人，並聲明「Miguel is the primary maintainer」[139]。

企業隨後跟進。最早的維護者之一 Wedson Almeida Filho，先以 @google.com、後以 @microsoft.com 提交 [37]。Android 的 Binder 驅動程式由 @google.com 的 Alice Ryhl 以 Rust 重寫，進入了 6.18。提交開頭寫著「We're generally not proponents of rewrites (nasty uncomfortable things that make you late for dinner!)」，接著解釋原因：C 版本的 Binder 約有 6,000 行，「combines/nests 13 different locks, 7 reference counters, and atomic variables」[140]。由 Red Hat 與 NVIDIA 合作的 nova-core，從第一個提交起就是 Rust [115]。

2025 年 12 月，在 Maintainers Summit 上，這項實驗被宣告結束。LWN 記錄，Rust 程式碼「by a factor of five over the last year」成長，而搭載 Android 16 與 6.12 核心的裝置已經內含一個 Rust 模組 ashmem：「So there are millions of real devices running kernels with Rust code now」[141]。Ojeda 在 7.0 中移除實驗性標籤的提交，最後要求的正是本文所描述的事：「I hope this signals commitment from the kernel to companies and other entities to invest more into it, e.g. into giving time to their kernel developers to train themselves in Rust」[142]。在 7.2 中，Rust 仍然很少：473 個 .rs 檔案、182,584 行，佔原始碼的 0.5% [37]。圍繞它的政治爭執，留待談張力的一節。

為了在 Linux 上打遊戲的修補

這個模式在小規模上同樣成立。Windows 遊戲用 WaitForMultipleObjects 同時等待多個事件；Linux 的 futex() 每次呼叫只能等待一個位址。2019 年 7 月 30 日，@collabora.com 的 Gabriel Krisman Bertazi 送出了 FUTEX_WAIT_MULTIPLE，上面有兩個 @valvesoftware.com 的簽名。有了它，在 Proton 中「using futexes in our Wine use case reduced the CPU utilization by 4% for the game Beat Saber and by 1.5% for the game Shadow of Tomb Raider」[143]。最後進入核心的是另一個介面：同樣來自 @collabora.com 的 André Almeida 所寫的專用系統呼叫 [144]。futex_waitv() 在 2022 年 1 月的 5.16 推出，明確寫出用途：模擬 WaitForMultipleObjects，「which allows software like Proton to improve the performance of Windows Games」[145]。兩位巴西人、一家開放原始碼顧問公司和一家遊戲公司：這就是一個修補進入主線的路徑。

子系統	誰開始的（當時的雇主）	進入主線
cgroups	Rohit Seth 與 Paul Menage（Google）	2.6.24，2008 年 1 月
namespaces	IBM、OpenVZ、Google、Arista 等	從 2.4.19（2002）到 5.6（2020）
KVM	Avi Kivity（Qumranet，後為 Red Hat）	2.6.20，2007 年 2 月
eBPF	Alexei Starovoitov（PLUMgrid）	3.15 與 3.18，2014 年
XDP	Brenden Blanco（PLUMgrid）	4.8，2016 年 10 月
io_uring	Jens Axboe（見正文）	5.1，2019 年 5 月
Btrfs	Chris Mason（Oracle）	2.6.29，2009 年 3 月
XFS	Silicon Graphics	2.5.36，2002 年 9 月
CFS	Ingo Molnar（Red Hat）	2.6.23，2007 年 10 月
EEVDF	Peter Zijlstra（Intel）	6.6，2023 年 10 月
sched_ext	Tejun Heo 與 David Vernet（Meta），與 Google 合作	6.12，2024 年 11 月
amdgpu	Alex Deucher（AMD）	4.2，2015 年 8 月
xe	Intel，與 Red Hat 及 Collabora 合作	6.8，2024 年 3 月
mlx5	Eli Cohen（Mellanox）	3.11，2013 年 9 月
arm64	Catalin Marinas 與 Will Deacon（Arm）	3.7，2012 年 12 月
RISC-V	Palmer Dabbelt 與 Albert Ou（SiFive）	4.15，2018 年 1 月
s390	IBM 德國	2.2.14，2000 年 1 月
PREEMPT_RT	Ingo Molnar（Red Hat）與 Thomas Gleixner（Linutronix）	6.12，2024 年 11 月
Rust	Miguel Ojeda（ISRG 合約，由 Google 資助）	6.1，2022 年 12 月
futex_waitv	André Almeida（Collabora），為 Valve 而做	5.16，2022 年 1 月

這些子系統幾乎沒有一個是某人週末解決自己的問題而誕生的。它們誕生於需要隔離工作負載的資料中心、想賣虛擬化的新創公司、想為封包路徑寫程式的另一家新創，以及需要讓自家晶片運作的製造商。主線是這些需求交會、並開始被共同維護的地方。

誰在做決定

一個修補從維護者的收件匣到進入正式版本，需要兩到三個月。這條路徑是公開的，也有文件記載，而它經過的幾乎每一雙手，都在某個人的薪資名單上。

文件描述了這個節奏。新版本「every two or three months」發布一次，帶有「about 13,000 changesets」。首先是合併窗口（merge window），它「lasts for approximately two weeks」，Linus 在這段期間拉取維護者累積的程式碼。接著「about once a week」發布一個 -rc，直到 -rc6 到 -rc9 之間 [146]。7.2 花了九週，從 2026 年 6 月 14 日到 8 月 16 日 [37]。在到達 Linus 之前，程式碼會經過某個子系統的樹，以及 linux-next；後者「maintained by Mark Brown」，是主線在下一個合併窗口應有樣貌的預覽 [146]。

 作者 --電子郵件--> 子系統郵件論壇
                     （公開審查：Reviewed-by、Acked-by、Tested-by）
                            |
                            v
                   維護者的樹  （+ 套用者的 Signed-off-by）
                            |
                            v
                       linux-next  （整合各子系統的樹）
                            |   合併窗口：約兩週
                            v
                  主線（Linus） --> -rc1 ... -rc7 --> 7.x 正式版
                            |
                            v
          stable 與 LTS（Greg Kroah-Hartman、Sasha Levin）：
          只收已在主線中的修正，最多 100 行

正式版發布後，修正會往下流入 stable 與長期支援的樹。規則很嚴格：修補必須「already exist in Linux mainline (upstream)」，而且「cannot be bigger than 100 lines, with context」[147]。一個長期版本能活多久，字面上就是市場的決定。每一個長期版本「usually starts with only a 2-year projected EOL that can be extended further if there is enough interest from the industry at large to help support it for a longer period of time」[148]。2026 年 10 月共有六個 LTS 系列，從 5.10 到 6.18，預計的終止時間介於 2026 年 12 月與 2028 年 12 月之間 [148]。自 2024 年 2 月 13 日起，核心也自行發布 CVE [149]，明言的準則是「assign CVE numbers to any bugfix that they identify」[150]。它從零開始，在 CVE 編號機構中以數量成為「number 1 in 2025」[151]，而 Linux 基金會統計出每天 13 個 CVE [152]。

每一部分歸誰所有，記錄在一個文字檔裡。7.2 的 MAINTAINERS 檔案有 3,255 個條目，每個條目都有維護者（M:）、審查者（R:）、郵件論壇（L:）、樹（T:）與狀態（S:）[70]。狀態是核心裡最坦白的資料。Supported 的意思是「Someone is actually paid to look after this」；Maintained 則是「Someone actually looks after it」。在 7.2 中，795 個條目（24.4%）自稱有人付錢，2,205 個（67.7%）自稱有人維護，139 個（4.3%）是孤兒 [70]。這個數字是自行申報的，低估了付費的程度。由 Tejun Heo、Johannes Weiner 與一位 SUSE 工程師維護的 CGROUP 標示為 Maintained；由 @fb.com 的 Chris Mason 與 @suse.com 的 David Sterba 維護的 Btrfs 也是；由四位 @nvidia.com 維護者負責的 mlx5 亦然 [70]。

在 1,998 個維護者信箱中，287 個是 gmail.com，191 個是 kernel.org，兩者都看不出雇主。接下來是 Intel（86 個，含 linux.intel.com）、AMD（56）、Red Hat（46）、IBM（45）、Broadcom（41）、NVIDIA（35）與 NXP（35）[70]。網域會從兩個方向誤導人。Mauro Carvalho Chehab 在 MAINTAINERS 中是 mchehab@kernel.org，但他有 2,310 個提交出自 mchehab+huawei@kernel.org [37]。Peter Zijlstra 使用個人網域，簽名卻是「Peter Zijlstra (Intel)」[103]。要知道誰付錢給誰，必須拼湊證據：

領域	維護者	所屬單位，以及找到的最新證據
其他一切（「THE REST」）	Linus Torvalds	Linux 基金會：2024 年 990 表上的「Fellow」[109]
stable 與 LTS	Greg Kroah-Hartman	Linux 基金會：TAB 頁面上的「Fellow」[153]
排程器	Peter Zijlstra	Intel：簽名為「Peter Zijlstra (Intel)」[103]
x86	Borislav Petkov	AMD：簽名為「Borislav Petkov (AMD)」[37]
x86 與排程器	Ingo Molnar	MAINTAINERS 中的 `@redhat.com` 信箱 [70]
網路	Eric Dumazet	`@google.com` 信箱 [70]
網路	Jakub Kicinski	Facebook，見 LPC 2025 議程 [154]
網路	Paolo Abeni	`@redhat.com` 信箱 [70]
BPF	Daniel Borkmann	「Isovalent at Cisco」，見 OSS NA 2025 議程 [155]
KVM	Paolo Bonzini	`@redhat.com` 信箱 [70]
x86 的 KVM	Sean Christopherson	`@google.com` 信箱 [70]
核心安全	Kees Cook	Google，見 TAB 頁面 [153]
AMDGPU	Alex Deucher	`@amd.com` 信箱 [70]
PREEMPT_RT	Sebastian Andrzej Siewior	`@linutronix.de` 信箱，一家 Intel 旗下的公司 [70], [133]

交棒也遵循同樣的模式。2026 年 4 月，在 MAINTAINERS 中使用 @linux-foundation.org 信箱的 Andrew Morton [70]，宣布將開始交出記憶體管理的維護工作；他擔任這個角色「since before memory management was even seen as its own subsystem」。這個子系統的整合樹「will be picked up by David Hildenbrand」[156]，而 TAB 的頁面把 Hildenbrand 列為 Arm 的員工 [153]。

在這一切之上的是 Linux 基金會，它付錢給 Linus 本人。在 2024 年的 990 表上，他的職稱是「Fellow」，報酬欄為 524,349 美元，「Other」欄為 1,089,627 美元。在主要報酬欄中，有十位基金會主管排在他前面，第一位是執行董事 Jim Zemlin，分別為 952,166 美元與 451,018 美元 [109]。2025 年的年度報告預估收入為 3.113 億美元，其中 42.8% 來自「Membership & Donations」，支出為 2.848 億美元。「Linux Kernel Project」這一項是 840 萬美元，佔支出的 2.95%。這比「Training」的 2,160 萬美元和「Event Services」的 1,680 萬美元都少。最大的一塊，1.819 億美元，流向「Project Support」，也就是基金會託管的其他專案 [152]。2024 年，核心拿到 680 萬美元，佔 2.27% [157]。年度報告的數字是預估值，與 990 表並不一致；990 表記錄的 2024 年收入是 2.207 億美元 [109]。無論用哪一種算法，今天的 Linux 基金會都是一個託管許多專案、卻冠著其中一個專案名字的基金會。

社群與基金會之間的正式橋梁是技術顧問委員會（TAB）。它「exists to provide advice from the kernel community to the Linux Foundation and holds a seat on the LF's board of directors」[158]，基金會章程也為 TAB 保留了一個不分區（at-large）董事席位 [159]。在 2025 年 12 月的選舉中，登記選民有 1,054 人，投票的有 265 人 [160]。目前列出的十位成員中，兩位來自 Google，兩位來自 Intel，一位來自 Arm，一位來自 Inria；兩位是基金會自己的 Fellow，一位寫的是 Qube-RT，Miguel Ojeda 則沒有列出公司 [153]。LWN 形容 TAB 是「a sort of governing board in a community that has no governing boards」[161]。

薪資名單上的巴西人

在我談核心的貼文中出現過的那些巴西人，同樣掛著識別證。提交中電子郵件的網域，記錄了每個人的職涯 [37]：

開發者	在 7.2 MAINTAINERS 中的角色	提交中的網域（年份）
Marcelo Tosatti	（2001 年的 2.4 維護者；2011 年的 KVM）	2001 年在 LKML 上使用 `conectiva.com.br`；`redhat.com`（2007–2024）
Arnaldo Carvalho de Melo	Performance Events	`mandriva.com`（2005–2006）；`redhat.com`（2007–2026），4,726 個提交中的 4,392 個
Mauro Carvalho Chehab	Media（V4L/DVB）與 HiSilicon 驅動程式	`redhat.com`（2007–2013）；`samsung.com` 與 `osg.samsung.com`（2013–2018）；`mchehab+huawei@kernel.org`（2,310 個提交）
Glauber Costa	（kvmclock；cgroups 中的記憶體）	`redhat.com`（2008–2011）；`parallels.com`（2011–2013）
Lucas De Marchi	（xe 驅動程式的共同開發者）	`profusion.mobi`（2011–2013）；`intel.com`（2014–2025，871 個提交）；`nvidia.com`（2026）
Gabriel Krisman Bertazi	Unicode	`linux.vnet.ibm.com`（2015–2016）；Collabora（2016–2024）；`suse.de`（2022–2026）
André Almeida	Futex（審查者）	`collabora.com`（2019–2022）；`igalia.com`（2022–2026）
Luiz Augusto von Dentz	Bluetooth	`nokia.com`（2010–2011）；`intel.com`（2011–2026，503 個提交）
Henrique de Moraes Holschuh	ThinkPad ACPI	`hmh.eng.br`，自己的網域（2006–2021，342 個提交）

網域的來源是核心的 git log，角色的來源是 7.2 與 3.0 的 MAINTAINERS 檔案 [37], [70], [67]。Tosatti 在 2001 年的郵件存於 LKML [7]。LKML 的門檻對所有人開放，而他們跨過去了。但幾乎每一個案例，都是在有人支付工時的情況下跨過去的。表中的例外是 Henrique de Moraes Holschuh，他用自己的網域維護一個驅動程式長達十五年，這正是 4.5% 的「(None)」所量測的那種貢獻。

流程是開放的：任何人都能送出修補，規則對每個人都一樣。但負責套用的人、負責整合的人、決定一個版本能活多久的人，以及付錢給最終仲裁者的人，幾乎總是某個掛著識別證的人。

為什麼競爭者共用同一份程式碼

在一篇談授權的貼文中，我寫過：GPL 是法條主義，BSD 是信任；一個強迫你回饋，另一個期待合作自己出現。近看核心之後，這句話需要修正。讓一家公司回饋程式碼的，不只是授權，而是不回饋的代價。

Linux 不對留在主樹外的人承諾任何穩定性。Greg Kroah-Hartman 談這個主題的文件一開頭就說，Linux「does not have a binary kernel interface, nor does it have a stable kernel interface」。作為交換，它提出一項協議：「If your driver is in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change in the first place」。文件列出的好處中，第一項是經濟上的：「The quality of the driver will rise as the maintenance costs (to the original developer) will decrease」[162]。留在外面的人，每個版本都要付 rebase 的錢，而版本是「every nine or ten weeks」就出一個 [39]。進來的人，則和所有人一起分攤帳單，包括競爭者。

Google 從內部量過這筆帳。公司伺服器所用的核心 Prodkernel「consists of around 9000 patches on top of an older upstream Linux kernel」，而把這些修補 rebase 到新版本（大約每兩年做一次）是「extremely costly」的事。Icebreaker 專案的誕生，是為了「to provide a near-mainline kernel for development and testing within Google」[163]。Facebook 更早走到這一步。2015 年，該公司表示，它內部的 4.0 分支有 12 位工程師的 101 個提交，而主線收到了其中九人的 238 個提交：「This is our upstream-first philosophy at work」[164]。在 2016 年的一場研討會上，該公司的一位工程師說得很直白：「Running old kernels with internal-only patches is painful」[165]。AWS 採用了發行版的模式：Amazon Linux 2023 每年推出一個長期核心，「based on the upstream Linux community's annual LTS kernel」[166]。

Android 示範了反其道而行的代價。2010 年，Greg Kroah-Hartman 說，他把 Android 的驅動程式放進了 staging，Google 也承諾協助把它們帶進主線，「but they didn't」；他只好把它們移除 [167]。癥結在 wakelocks，也就是 Android 散布在各個驅動程式中的省電機制。這份程式碼在 2011 年底回到 staging [168]，而 autosleep，一個主線可以接受的版本，在 2012 年進入 3.5 [169], [170]。即便如此，2017 年出貨的裝置，核心仍帶著「large amounts (often millions of lines) of out-of-tree code」[171]。

Google 改變了策略。2018 年，Android Common Kernel 只需要「only about 30 patches」、約 6,500 行，就能開機 [172]；2020 年，它在 5.9-rc 之上仍帶著 485 個修補 [173]。Android 的文件解釋了原因：在 Generic Kernel Image 之前，晶片商與裝置製造商的客製化「could result in as much as 50% of kernel code being out-of-tree code」。自 Android 12 起，搭載 5.10 或更新核心的裝置「must ship with the GKI kernel」[174]，而給開發者的指引是：「Upstream development is strongly encouraged」[175]。

Microsoft 是最具象徵意義的案例。2009 年 7 月 20 日，該公司釋出了「20,000 lines of device driver code to the Linux community under the popular General Public Licence v2」，也就是 Hyper-V 驅動程式 [176]。Greg Kroah-Hartman 在 LKML 上宣布，它們會進入 drivers/staging/，並伴隨「a whole bunch of cleanups」[177]。清理的工作多到在 2011 年的 3.0 中，Microsoft 佔了 4.0% 的變更，LWN 評論道：「one assumes that presence will not be permanent: even the HV drivers can only need so much cleaning up」[33]。這份存在留了下來。2016 年 11 月，Microsoft 成為 Linux 基金會的白金會員 [178]。如今它公開維護 WSL2 的核心 [179]，在 6.19 中佔維護者簽核的 3.3% [40]。

那 BSD 呢？FreeBSD 從反面證明了這一點。Sony 把「FreeBSD Kernel」列在 PlayStation 4 的元件中 [180]，而 Apple 的 XNU 是「a hybrid kernel combining the Mach kernel developed at Carnegie Mellon University with components from FreeBSD」，由該公司發布在一個名為 apple-oss-distributions 的 GitHub 組織下 [181]。授權允許封閉，而許多公司確實封閉了。但在影片傳遞網路上執行 FreeBSD 的 Netflix，緊跟著開發分支：「a commit to the upstream FreeBSD development branch will usually be fully deployed across Netflix's CDN within 4-12 weeks」[182]。它這麼做的理由，和 Google 與 Facebook 在 Linux 上一樣：讓一個分叉遠離上游，代價很高。GPL 要求公開你所散布的程式碼，卻不要求任何人把修補送進主線。把修補送到那裡的，是算盤。

反例來自 Solaris。2010 年，一位 Oracle 員工總結了收購 Sun 之後發生的事：Oracle「stopped publishing binaries for recent OpenSolaris releases and stopped talking to the community at the same time」。2010 年 8 月 3 日，Nexenta 宣布 Illumos，在 Oracle 之外延續這個系統 [183]。只有一個主人的專案，會在主人決定的時候死去；本文的結論會回到這一點。

經濟學文獻為這一切取了名字。Lerner 與 Tirole 在 2002 年以勞動經濟學解釋了個人參與的很大一部分，特別是「literature on career concerns」[184]：貢獻就是履歷。Linux 基金會 2017 年的報告顯示了這個效應在核心中的樣子：把程式碼送進主線的人，就找得到工作 [31]。West 與 Gallagher 描述了企業在開放原始碼中的策略，其中包括「pooled R&D/product development」與「selling complements」[185]。核心正是如此：Intel、AMD 與 NVIDIA 分攤作業系統的成本，在跑這個系統的硬體上競爭。Joachim Henkel 研究了嵌入式 Linux 公司，指出揭露是選擇性的：它們公開一部分自己開發的東西，保護其餘的部分 [186]。2024 年，哈佛商學院的一項研究估計，重寫最廣泛使用的開放原始碼軟體需要 41.5 億美元，而它為使用者創造的價值是 8.8 兆美元，並指出「96% of the demand-side value is created by only 5% of OSS developers」[187]。作者在致謝中提到「financial and administrative support from the Linux Foundation」[187]。

Nadia Eghbal 在 2016 年為福特基金會撰寫的報告中，把核心視為例外。她寫道「The Linux Foundation is one of the most successful outliers, due to the fundamental value of the Linux kernel to nearly every corporate entity」，並帶來一筆巴西的資料：米納斯吉拉斯聯邦大學（UFMG）對 GitHub 上 133 個熱門專案的研究顯示，其中 64%「relied upon just one or two developers to survive」[188]。核心之所以逃過這種命運，是因為它成了付錢者的基礎設施。

競爭者共用同一份程式碼，是因為不共用的代價，比藏起來的收穫還高。授權有幫助，做決定的是算盤。

測試核心的機器人

我到處說過，實際上幾乎沒有人在讀進入核心的成千上萬個修補。產業的回應不是雇用更多讀者，而是讓機器全天候閱讀並執行程式碼，而這些機器幾乎都有主人。

Google 的 syzkaller 是「an unsupervised coverage-guided kernel fuzzer」，儲存庫從 2015 年 10 月就存在 [189]。syzbot 是不停執行它的機器人：「syzbot system continuously fuzzes main Linux kernel branches and automatically reports found bugs to kernel mailing lists」[190]。2019 年，以 @google.com 提交的 Dmitry Vyukov [37] 統計出，兩年內在上游找到約 2,300 個錯誤，每天三個，另外在 Android、ChromeOS、stable 樹與內部核心中又找到 2,500 個 [191]。2026 年 10 月 2 日，syzbot 的儀表板顯示，上游已修正 7,518 個錯誤，仍有 1,591 個未解決 [192]。

Intel 執行 0-day，它的報告署名為「kernel test robot」。2012 年，它已經在測試 Linus 的樹、linux-next 以及「more than 180 trees owned by individual kernel maintainers and developers」[193]；程式碼放在 lkp-tests 儲存庫 [194]。在 5.5 中，LWN 統計了 Reported-by 的功勞來源：Hulk Robot 佔 15.7%，syzbot 佔 12.0%，Intel 的機器人佔 9.8%，結論是「over 1/3 of the bug reports for the kernel (of which 934 were credited in 5.5) are now coming from automated testing systems」[195]。在 5.5 的 git log 中，Hulk Robot 的 164 次功勞出自 hulkci@huawei.com，Intel 機器人的則出自 lkp@intel.com [37]。

KernelCI 的起點正好相反。它「originally started in 2014 as a side project by a few engineers who were doing the testing at home and in their spare time」。2019 年 10 月，它成為 Linux 基金會的專案，「underwritten by BayLibre, Civil Infrastructure Platform, Collabora, Foundries.io, Google, Microsoft, Red Hat」[196]。如今它的會員名單包括 Arm、Google、Linaro、Microsoft、Qualcomm、Red Hat 與 Texas Instruments [197]。週末專案變成了有贊助者的基礎設施。

核心內部的診斷工具也有相同的出身。偵測非法記憶體存取的 KASAN，由 @samsung.com 的 Andrey Ryabinin 帶進 4.0，而提交本身就引用了 Google 為使用者空間打造的工具家族：「We've developed the set of tools, AddressSanitizer (Asan), ThreadSanitizer and MemorySanitizer」[198]。偵測資料競爭的 KCSAN 出自 @google.com 的 Marco Elver，進入了 5.8 [199], [200]。偵測未初始化記憶體的 KMSAN 出自同樣來自 Google 的 Alexander Potapenko，進入了 6.1；Andrew Morton 在 pull request 中寫道：「KMSAN keeps finding bugs. New ones, as well as the legacy ones」[201], [202]。單元測試框架 KUnit 來自 @google.com 的 Brendan Higgins，在 5.5 加入 [203]。在已安裝核心上執行的測試套件 kselftest，從 2014 年起由當時以 @samsung.com 提交的 Shuah Khan 整理 [37], [204]。

工具	誰付錢或發起	起始	用途
syzkaller 與 syzbot	Google	儲存庫始於 2015 年 10 月	持續模糊測試；截至 2026-10-02 已修正 7,518 個錯誤，1,591 個未解決
kernel test robot（0-day）	Intel	2012 年已測試超過 180 棵樹	編譯、開機並測試每一棵樹；5.5 中 9.8% 的錯誤回報
Hulk Robot	Huawei（`hulkci@huawei.com`）	5.5 時已在運作	5.5 中 15.7% 的錯誤回報
KernelCI	Linux 基金會，與 Google、Microsoft、Red Hat 等	2014 年；2019 年起屬於 LF	在多個實驗室的實體硬體上測試
KASAN	Andrey Ryabinin（Samsung），以 Google 的工具為基礎	4.0，2015 年 4 月	非法記憶體存取
KCSAN	Marco Elver（Google）	5.8，2020 年 8 月	資料競爭
KMSAN	Alexander Potapenko（Google）	6.1，2022 年 12 月	使用未初始化的記憶體
KUnit	Brendan Higgins（Google）	5.5，2020 年 1 月	核心內的單元測試
kselftest	Shuah Khan（當時在 Samsung）	2014 年	測試已安裝的核心

就連獵捕漏洞利用也是有償的。Google 針對核心漏洞的獎勵計畫 kCTF，自開辦以來「has rewarded researchers with a total of 1.8 million USD」[84]。

稽核核心是可能的，而大規模稽核的人，都在某人的薪資名單上：Google、Intel、Huawei、Samsung。syzbot 上 1,591 個未解決錯誤的佇列，提醒了我常說的那句話的另一半：有審查、有測試、有維護者，不代表漏洞不存在。

對不上的地方

一個由企業出資的模式解決了很多問題，也製造了其他問題。有些出現在數字裡，有些出現在郵件論壇上。

走到極限的維護者

根據 LWN 的報導，在 2023 年的 Maintainers Summit 上，Ted Ts'o 開啟一場關於過勞的討論時說，維護者最後做的是「all of the tasks that nobody else working on a given subsystem wants to take on」[205]。一年前，在 Josef Bacik 主持的一場討論中，關於檔案系統的說法是：「we simply do not have enough people on some of the filesystem teams」[206]。學術研究證實了這幅圖像。一項 2017 年的研究結論是「the distribution of work among maintainers is highly unbalanced」，而讓一個檔案有不只一位維護者，帶來的只是「only a power of 1/2 increase in productivity」[207]。公司雇人來寫程式碼，審查別人程式碼的工作卻落在少數人身上；7.2 中 41.4% 沒有任何審查標記的提交，就是這幅景象的寫照 [37]。

代價出現在核心之外。2022 年 6 月，xz 的維護者 Lasse Collin 回應要求他更活躍的催促：「I haven't lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues but also due to some other things. Recently I've worked off-list a bit with Jia Tan on XZ Utils」[208]。2024 年 3 月，Andres Freund 發現「the upstream xz repository and the xz tarballs have been backdoored」，並寫道做出可疑提交的人「is either directly involved or there was some quite severe compromise of their system」[209]。他指出的其中一個提交，署名是 Jia Tan [210]。核心不是 xz，但教訓同樣適用：疲憊的維護者就是攻擊面。

GPL 與不肯開放的驅動程式

核心試圖用授權區分公開與內部的東西。以 EXPORT_SYMBOL_GPL() 匯出的符號，「can only be seen by modules with a MODULE_LICENSE() that specifies a GPLv2 compatible license」[211]。封閉驅動程式的廠商用開放授權的橋接模組繞過這一點。2020 年，5.9 關上了這扇門：從專有模組匯入符號的模組，也會被視為專有模組 [212]。這個提交帶著 Greg Kroah-Hartman 的一句評論：「Ah, the proven-to-be-illegal "GPL Condom" defense :)」。2023 年，LWN 總結了這條規則：這樣的模組「immediately loses its ability to access GPL-only symbols」[213]。

NVIDIA 一直是箭靶。根據 Phoronix 的報導，2012 年 Linus 在阿爾托大學的一場演講中，稱這家公司是「the single worst company we have ever dealt with」[214]。2022 年 5 月，NVIDIA 開放了其驅動程式的核心模組，但放在主樹之外 [114]。預計要進入主線的驅動程式 nova-core，是由一位以 Red Hat 身分提交的開發者發起的，如今維護者中有一位 NVIDIA 工程師 [115], [70]。當留在外面的代價大於進來的代價時，這家公司就進來了。

有禁令的硬體

硬體漏洞製造了一種核心無從避免的衝突：發現漏洞的人和修正漏洞的人，是彼此競爭的公司。2018 年 1 月，在修正 Spectre 的過程中，Linus 這樣評價一系列實作 Intel 所定義 IBRS 介面的修補：「As it is, the patches are COMPLETE AND UTTER GARBAGE」。在同一串討論中，他也曾呼籲：「Please, any Intel engineers here - talk to your managers」[215]。由此產生的流程有文件記載。像「Meltdown, Spectre, L1TF etc. must be treated differently because they usually affect all Operating Systems」，而核心團隊因為是「not a formal body」，所以「unable to enter into any non-disclosure agreements」，改以一份合作備忘錄代替 [216]。核心以社群的身分與晶片廠商往來，而不是以簽約供應商的身分。

少數公司，很大的權力

集中化已經出現在數字中。自 2017 年起，超過一半的修補要經過五家公司的維護者之手 [31], [39]。這些公司的名單會變：2009 年 Red Hat 握有 42.4% 的維護者簽核，到了 6.19 只剩 4.9%；2009 年還不在名單上的 Meta，如今排名第一 [32], [40]。核心度過了這次換班，沒有出現明顯的危機。風險不在於某家公司離開，而在於留下來的公司，基於共同利益，獨自決定什麼值得維護。

制裁

2024 年 10 月 18 日，Greg Kroah-Hartman 的一個提交從 MAINTAINERS 中移除了幾個條目，理由是「due to various compliance requirements」，並承諾「if sufficient documentation is provided」就可以恢復 [217]。這個修補只寄到一個修補用的郵件論壇，夾在一個驅動程式的 pull request 中進入 6.12-rc4，沒有任何特別說明；LWN 指出，被移除的開發者「all appear to be of Russian origin」[218]。Paul Moore 提出最低限度的要求：「can we at least explicitly list those requirements in the commit description?」[219]。James Bottomley 給了解釋：「If your company is on the U.S. OFAC SDN lists, subject to an OFAC sanctions program, or owned/controlled by a company on the list, our ability to collaborate with you will be subject to restrictions, and you cannot be in the MAINTAINERS file」[220]。Linus 公開支持這項變更，並表示不會撤回 [218]。一個由企業維護、由美國基金會託管的專案，遵守美國法律。這不是社群品格上的缺陷，而是這個模式的結果。

Rust 與維護者的權力

近年持續最久的爭執是關於 Rust 的，而它與其說是關於語言，不如說是關於誰能管什麼。2024 年 8 月，以 @microsoft.com 提交的 Wedson Almeida Filho [37] 離開了這個專案：「I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense」[221]。2025 年 1 月，Christoph Hellwig 以一個 Nacked-by 否決了一個 Rust 的 DMA 抽象層，寫道他不想在子系統中多一位維護者，並要想要雙語程式碼庫的人在自己的驅動程式裡做，「instead of spreading this cancer to core subsystems」。在同一封郵件中，他澄清所謂的癌症是「a cross-language codebase」[222]。幾天後他補充：「I will do everything I can do to stop this. This is NOT because I hate Rust」[223]。

Asahi Linux 的 Hector Martin 在郵件論壇上寫道：「If shaming on social media does not work, then tell me what does, because I'm out of ideas.」Linus 回覆：「How about you accept the fact that maybe the problem is you」[224]。Martin 退出了 MAINTAINERS，表示他已經沒有「any faith left in the kernel development process or community management approach」[225]。兩週後，Linus 寫信給 Hellwig，指出那個有爭議的 pull request「DID NOT TOUCH THE DMA LAYER AT ALL」，並定下規則：「if you as a maintainer feel that you control who or what can use your code, YOU ARE WRONG」[226]。專案的官方政策容許折衷：「Some subsystems may decide they do not want to have Rust code for the time being, typically for bandwidth reasons. This is fine and expected」[227]。一項由企業資助的實驗，撞上了核心維護者的時間極限。最後拍板的，是由基金會付薪的仲裁者。

沒有老闆的檔案系統

bcachefs 是 Kent Overstreet「on his own, supported by interested users on Patreon」推動的專案，也是它把 6.7 的「(None)」推高 [36]。它在 6.17-rc4 被標示為「externally maintained」，那是 Linus 的一個提交，理由只有一行：「As per many long discussion threads, public and private」[228]。在 6.18 中，程式碼被移除，因為這個檔案系統已經是「a DKMS module」[229]。提交沒有提到錢，提到的是漫長的討論。但結果從反面說明了本文的論點：沒有公司撐腰的大型子系統中，最顯眼的這一個，最後落到了主樹之外。

AI 加入了佇列

在 7.2 中，有 1,111 個變更（「under 7% of the total」）以 Assisted-by 標記聲明使用了 AI 工具，上一個週期是 301 個 [2]。syzbot 的儀表板已經有一個篩選器，專門列出由 AI 提出、等待審查的修正 [192]。依我的經驗，AI 沒有減少工作，反而增加了。更多的修補，來自更多不認識的人，交給同樣那幾位維護者審查。

核心有後門嗎？

我曾經寫過，核心有後門，NSA 的程式碼在裡面待了好幾年。我去查了有文件記載的事實。2003 年，一次在 wait4() 中植入後門的企圖，在進入主樹之前就被攔下，歷史那一節已經說明 [22]。2021 年，明尼蘇達大學的研究人員為了研究審查流程，刻意送出有缺陷的修補；TAB 重新檢查了該校的 435 個提交，而「These 39 commits are going to be reverted」[230]。那 NSA 呢？SELinux 是 NSA 寫的，它以公開程式碼的形式進入核心，並在郵件論壇上接受審查。那些消失的「NSA 參考」，是在 SELinux 維護者之一 Stephen Smalley [70] 的提交「selinux: de-brand SELinux」中移除的，該提交把說明文字與註解中的「NSA SELinux」改成「SELinux」[231]。6.6 的 pull request 解釋道：「We've come a long way from the original NSA submission and I would consider SELinux a true community project at this point so removing the NSA branding just makes sense」[232]。這是一次品牌更名，不是移除惡意程式碼。我以前常說的那句話是錯的。真正的風險更無聊：每十個提交中有四個沒有審查標記就進入核心，而套用它們的維護者很疲憊。

這些張力沒有一項意味著這個模式即將崩潰。它們是這種模式的代價：付錢的人決定錢花在哪裡，而沒有人想付錢的東西，例如審查、舊程式碼的維護，以及對流程的耐心，就落在少數人身上。

結論：擁有者太多的公共財

1991 年，核心屬於一個人。2026 年，它不屬於任何人，也屬於每一個付錢的人。

本文的數字指向同一個地方。7.2 的提交中，每五個就有四個來自所屬單位已辨識的人，只有 4.5% 來自明確為自己工作的人 [2]。接受程式碼的人更加企業化：6.19 的維護者簽核中，只有 1.6% 來自沒有雇主的人 [40]。定義現代 Linux 的子系統，從 cgroups 到 io_uring，從 KVM 到 sched_ext，都誕生於企業的需求，並由企業員工寫進主線。測試核心的機器人也有主人。就連一個長期版本的壽命，也取決於「enough interest from the industry at large」[148]。

這並不讓 Linux 成為某一家公司的產品，而與其他 Unix 的對照正好在這裡派上用場。OpenSolaris 有一個主人，當主人停止發布時，社群只好創造 Illumos [183]。XNU 屬於一家公司，在 GitHub 上以發行版的形式出現 [181]。Linux 核心在單一週期中收到 249 個已辨識雇主的提交，沒有任何一家公司超過 7.2 提交數的 10%，也沒有任何一家超過 6.19 維護者簽核的 12% [2], [40]。最終仲裁者由一個靠企業支持的基金會付薪，而在這個基金會的董事會中，每個白金會員只能指派一位董事 [159]。Linux 的穩健不是來自沒有企業，而是來自企業多到沒有一家能說了算。

這個模式在三個條件下運作，而核心三者兼具。留在外面必須很昂貴：沒有穩定的內部 ABI，不把程式碼送進主線的人，就得永遠付 rebase 的錢 [162]。沒有任何參與者大到足以封閉這個專案。流程必須公開，規則對實習生和副總裁一視同仁：同一個郵件論壇、同一個 Signed-off-by、同一個合併窗口。

這個模式也有盲點，就在沒有人有誘因付錢的地方。審查、舊程式碼的維護，以及對流程的耐心，都落在少數人身上。Linux 基金會在 2025 年的預估支出中，只把 2.95% 撥給核心 [152]。每五個提交中有兩個沒有審查標記就進入核心 [37]。當地緣政治找上門時，這個專案服從的是基金會與最大幾家公司所在國家的法律 [218]。

像我這樣每天用 Linux 的人，不需要把這一切浪漫化。Linux 不是因為開放而安全，也不是沒有商業利益。它是一套關鍵基礎設施，數十個競爭者一起維護它，因為這比各自維護便宜；它之所以保持開放，是因為沒有任何一個競爭者有能力把它關起來。

自由軟體不是沒有主人的軟體，而是主人多到沒有一個能說了算的軟體。

參考文獻

[1]L. Torvalds, “What would you like to see most in minix?,” message on comp.os.minix, Aug. 25, 1991. Archived copy at Carnegie Mellon University. [Online]. Available: https://www.cs.cmu.edu/~awb/linux.history.html ↩
[2]J. Corbet, “Development statistics for the 7.2 kernel,” LWN.net, Aug. 17, 2026. [Online]. Available: https://lwn.net/Articles/1088776/ ↩
[3]The FreeBSD Documentation Project, “Introduction: About the FreeBSD Project,” in FreeBSD Handbook. [Online]. Available: https://docs.freebsd.org/en/books/handbook/introduction/ ↩
[4]M. Linksvayer, “The Choice of a GNU Generation: An Interview With Linus Torvalds,” Meta, Nov. 1993. [Online]. Available: https://gondwanaland.com/meta/history/interview.html ↩
[5]Red Hat, Inc., “Prospectus: 6,000,000 Shares, Common Stock (Form 424B1),” U.S. Securities and Exchange Commission, Aug. 11, 1999. [Online]. Available: https://www.sec.gov/Archives/edgar/data/0001087423/000104746999031070/0001047469-99-031070.txt ↩
[6]A. Leonard, “Red Hot,” Salon, Aug. 12, 1999. [Online]. Available: https://www.salon.com/1999/08/12/redhat_ipo/ ↩
[7]M. Tosatti, “Re: Linux 2.4.16-pre1,” message on the linux-kernel mailing list, Nov. 24, 2001. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0111.3/0103.html ↩
[8]LWN.net, “Linux in the News,” LWN.net Weekly Edition, Dec. 14, 2000. [Online]. Available: https://lwn.net/2000/1214/press.php3 ↩
[9]LWN.net, “Commerce,” LWN.net Weekly Edition, Dec. 14, 2000. [Online]. Available: https://lwn.net/2000/1214/commerce.php3 ↩
[10]J. Barr, “Inside IBM's Linux Technology Center,” Computerworld, Mar. 20, 2001. [Online]. Available: https://www.computerworld.com/article/1447992/inside-ibm-s-linux-technology-center.html ↩
[11]“Industry Leader Forming Development Lab For Linux,” press release reproduced by Scoop, Aug. 31, 2000. [Online]. Available: https://www.scoop.co.nz/stories/BU0008/S00241.htm ↩
[12]OSDL and Transmeta, “Linux Creator Linus Torvalds joins OSDL,” press release reproduced on LWN.net, Jun. 17, 2003. [Online]. Available: https://lwn.net/Articles/36635/ ↩
[13]A. Updegrove, “Joining Forces: OSDL and the Free Standards Group will become The Linux Foundation,” ConsortiumInfo.org, Jan. 21, 2007. [Online]. Available: https://www.consortiuminfo.org/open-source-open-standards/joining-forces-osdl-and-the-free-standards-group-will-become-the-linux-foundation ↩
[14]Novell, Inc., “Novell Announces Agreement to Acquire Leading Enterprise Linux Technology Company SUSE LINUX,” Exhibit 99, Form 8-K, U.S. Securities and Exchange Commission, Nov. 4, 2003. [Online]. Available: https://www.sec.gov/Archives/edgar/data/0000758004/000075800403000018/nov4_99.htm ↩
[15]Caldera International, Inc. (The SCO Group), “Form 8-K,” U.S. Securities and Exchange Commission, Mar. 7, 2003. [Online]. Available: https://www.sec.gov/Archives/edgar/data/1102542/000104746903008083/a2105216z8-k.txt ↩
[16]The SCO Group, Inc., “Form 8-K,” U.S. Securities and Exchange Commission, Aug. 10, 2007. [Online]. Available: https://www.sec.gov/Archives/edgar/data/1102542/000095013407018100/v33019e8vk.htm ↩
[17]S. Sharwood, “SCO v. IBM settlement deal is done, but zombie case shuffles on elsewhere,” The Register, Aug. 30, 2021. [Online]. Available: https://www.theregister.com/2021/08/30/sco_tsg_vs_ibm_settlement/ ↩
[18]L. Torvalds, “[RFD] Explicitly documenting patch submission,” message on the linux-kernel mailing list, May 23, 2004. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0405.2/1301.html ↩
[19]The Linux Foundation, “Developer Certificate of Origin, Version 1.1,” 2004–2006. [Online]. Available: https://developercertificate.org/ ↩
[20]The kernel development community, “Submitting patches: the essential guide to getting your code into the kernel,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/process/submitting-patches.html ↩
[21]J. Corbet, “The kernel and BitKeeper part ways,” LWN.net, Apr. 6, 2005. [Online]. Available: https://lwn.net/Articles/130746/ ↩
[22]J. Corbet, “An attempt to backdoor the kernel,” LWN.net, Nov. 6, 2003. [Online]. Available: https://lwn.net/Articles/57135/ ↩
[23]L. Torvalds, “Kernel SCM saga..,” message on the linux-kernel mailing list, Apr. 6, 2005. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0504.0/1540.html ↩
[24]L. Torvalds, “Initial revision of "git", the information manager from hell,” commit e83c5163316f, git/git repository, Apr. 7, 2005. [Online]. Available: https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290 ↩
[25]L. Torvalds, “Linux-2.6.12-rc2,” commit 1da177e4c3f4, torvalds/linux repository, Apr. 16, 2005. [Online]. Available: https://github.com/torvalds/linux/commit/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ↩
[26]J. Corbet, “Kernel Summit: Development process,” LWN.net, Jul. 21, 2004. [Online]. Available: https://lwn.net/Articles/94386/ ↩
[27]J. Corbet, “Who wrote 2.6.20?,” LWN.net, Feb. 21, 2007. [Online]. Available: https://lwn.net/Articles/222773/ ↩
[28]The Linux Foundation, “Linux Foundation Publishes Study on Linux Development Statistics: Who Writes Linux and Who Supports It,” press release, Apr. 1, 2008. [Online]. Available: https://www.linuxfoundation.org/press/press-release/linux-foundation-publishes-study-on-linux-development-statistics-who-writes-linux-and-who-supports-it ↩
[29]The Linux Foundation, “The Linux Foundation Releases Annual Linux Development Report,” press release, Apr. 3, 2012. [Online]. Available: https://www.linuxfoundation.org/press/press-release/the-linux-foundation-releases-annual-linux-development-report ↩
[30]The Linux Foundation, “The Linux Foundation Releases Linux Development Report,” press release, Feb. 18, 2015. [Online]. Available: https://www.linuxfoundation.org/press/press-release/the-linux-foundation-releases-linux-development-report ↩
[31]J. Corbet e G. Kroah-Hartman, 2017 Linux Kernel Development Report. The Linux Foundation, 2017. [Online]. Available: https://www.linuxfoundation.org/hubfs/Reports/LinuxKernelReport_2017.pdf ↩
[32]J. Corbet, “Developer statistics for 2.6.30,” LWN.net, May 27, 2009. [Online]. Available: https://lwn.net/Articles/334721/ ↩
[33]J. Corbet, “Who wrote 3.0 - from two points of view,” LWN.net, Jul. 13, 2011. [Online]. Available: https://lwn.net/Articles/451243/ ↩
[34]J. Corbet, “Statistics from the 4.0 development cycle,” LWN.net, Apr. 1, 2015. [Online]. Available: https://lwn.net/Articles/637909/ ↩
[35]J. Corbet, “Some 6.0 development statistics,” LWN.net, Oct. 3, 2022. [Online]. Available: https://lwn.net/Articles/909625/ ↩
[36]J. Corbet, “Some 6.7 development statistics,” LWN.net, Jan. 8, 2024. [Online]. Available: https://lwn.net/Articles/956765/ ↩
[37]L. Torvalds et al., “Linux kernel source tree (torvalds/linux),” Git repository, clone accessed Oct. 2, 2026. [Online]. Available: https://github.com/torvalds/linux ↩
[38]J. Corbet, “Some 6.18 development statistics,” LWN.net, Dec. 1, 2025. [Online]. Available: https://lwn.net/Articles/1046966/ ↩
[39]J. Corbet, “Some 6.6 development statistics,” LWN.net, Oct. 30, 2023. [Online]. Available: https://lwn.net/Articles/948970/ ↩
[40]J. Corbet, “Development statistics for 6.19,” LWN.net, Feb. 9, 2026. [Online]. Available: https://lwn.net/Articles/1057302/ ↩
[41]U. Lerch, “Kommerzielle Entwicklung von Open-Source-Software: Idealismus, Pragmatismus oder Strategie? Eine Fallstudie über Entwickler des Linux-Kernels in großen Firmen der Informationstechnologie,” doctoral dissertation, Technische Universität Berlin, 2010. [Online]. Available: https://depositonce.tu-berlin.de/items/0f44ee1e-66a6-4161-b9bf-ed7a937be1d5/full ↩
[42]D. Riehle, P. Riemer, C. Kolassa and M. Schmidt, “Paid vs. Volunteer Work in Open Source,” in Proc. 47th Hawaii International Conference on System Sciences (HICSS), 2014, pp. 3286–3295, doi: 10.1109/HICSS.2014.407. [Online]. Available: https://dirkriehle.com/2013/08/22/paid-vs-volunteer-work-in-open-source/ ↩
[43]R. Seth, “[patch 0/5]-Containers: Introduction,” message on the linux-kernel mailing list, Sep. 14, 2006. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0609.1/2068.html ↩
[44]J. Corbet, “Process containers,” LWN.net, May 29, 2007. [Online]. Available: https://lwn.net/Articles/236038/ ↩
[45]A. Verma, L. Pedrosa, M. Korupolu, D. Oppenheimer, E. Tune and J. Wilkes, “Large-scale cluster management at Google with Borg,” in Proc. EuroSys 2015, 2015. [Online]. Available: https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/ ↩
[46]P. B. Menage, “Adding Generic Process Containers to the Linux Kernel,” in Proc. Ottawa Linux Symposium, vol. 2, 2007, pp. 45–58. [Online]. Available: https://www.kernel.org/doc/ols/2007/ols2007v2-pages-45-58.pdf ↩
[47]P. Menage, “Task Control Groups: basic task cgroup framework,” commit ddbcc7e8e50a, Oct. 18, 2007. [Online]. Available: https://github.com/torvalds/linux/commit/ddbcc7e8e50aefe467c01cac3dec71f118cd8ac2 ↩
[48]T. Heo, “Control Group v2,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/admin-guide/cgroup-v2.html ↩
[49]J. Corbet, “The unified control group hierarchy in 3.16,” LWN.net, Jun. 11, 2014. [Online]. Available: https://lwn.net/Articles/601840/ ↩
[50]Kernelnewbies, “Linux 4.5,” Mar. 13, 2016. [Online]. Available: https://kernelnewbies.org/Linux_4.5 ↩
[51]D. Xu, “Open-sourcing oomd, a new approach to handling OOMs,” Engineering at Meta, Jul. 19, 2018. [Online]. Available: https://engineering.fb.com/2018/07/19/production-engineering/oomd/ ↩
[52]J. Corbet, “Tracking pressure-stall information,” LWN.net, Jul. 13, 2018. [Online]. Available: https://lwn.net/Articles/759781/ ↩
[53]J. Weiner, “psi: pressure stall information for CPU, memory, and IO,” commit eb414681d5a0, Oct. 26, 2018. [Online]. Available: https://github.com/torvalds/linux/commit/eb414681d5a07d28d2ff90dc05f69ec6b232ebd2 ↩
[54]R. Pike, D. Presotto, K. Thompson, H. Trickey and P. Winterbottom, “The Use of Name Spaces in Plan 9,” Bell Laboratories. [Online]. Available: https://9p.io/sys/doc/names.html ↩
[55]E. W. Biederman, “Multiple Instances of the Global Linux Namespaces,” in Proc. Ottawa Linux Symposium, vol. 1, 2006, pp. 101–112. [Online]. Available: https://www.kernel.org/doc/ols/2006/ols2006v1-pages-101-112.pdf ↩
[56]M. Kerrisk, “Namespaces in operation, part 1: namespaces overview,” LWN.net, Jan. 4, 2013. [Online]. Available: https://lwn.net/Articles/531114/ ↩
[57]A. Kali, “cgroup: introduce cgroup namespaces,” commit a79a908fd2b0, Jan. 29, 2016. [Online]. Available: https://github.com/torvalds/linux/commit/a79a908fd2b080977b45bf103184b81c9d11ad07 ↩
[58]A. Vagin and D. Safonov, “ns: Introduce Time Namespace,” commit 769071ac9f20, Nov. 12, 2019. [Online]. Available: https://github.com/torvalds/linux/commit/769071ac9f20b6a447410c7eaa55d1a5233ef40c ↩
[59]S. E. Hallyn, “uts namespaces: Introduction,” patch reproduced on LWN.net, Apr. 2006. [Online]. Available: https://lwn.net/Articles/179345/ ↩
[60]P. Emelyanov and K. Kolyshkin, “PID namespaces in the 2.6.24 kernel,” LWN.net, Nov. 19, 2007. [Online]. Available: https://lwn.net/Articles/259217/ ↩
[61]A. Kivity, “[PATCH 0/7] KVM: Kernel-based Virtual Machine,” message on the linux-kernel mailing list, Oct. 19, 2006. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0610.2/1369.html ↩
[62]A. Kivity, Y. Kamay, D. Laor, U. Lublin and A. Liguori, “kvm: the Linux Virtual Machine Monitor,” in Proc. Ottawa Linux Symposium, vol. 1, 2007, pp. 225–230. [Online]. Available: https://www.kernel.org/doc/ols/2007/ols2007v1-pages-225-230.pdf ↩
[63]“The Definitive KVM (Kernel-based Virtual Machine) API Documentation,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/virt/kvm/api.html ↩
[64]A. Kivity, “[PATCH] kvm: userspace interface,” commit 6aa8b732ca01, Dec. 10, 2006. [Online]. Available: https://github.com/torvalds/linux/commit/6aa8b732ca01c3d7a54e93f4d701b8aabbe60fb7 ↩
[65]Kernelnewbies, “Linux 3.0,” Jul. 21, 2011. [Online]. Available: https://kernelnewbies.org/Linux_3.0 ↩
[66]Red Hat, “Red Hat Advances Virtualization Leadership with Qumranet, Inc. Acquisition,” press release, Sep. 4, 2008. [Online]. Available: https://www.redhat.com/en/about/press-releases/qumranet ↩
[67]“MAINTAINERS,” Linux 3.0, torvalds/linux repository. [Online]. Available: https://github.com/torvalds/linux/blob/v3.0/MAINTAINERS ↩
[68]Amazon Web Services, “Amazon EC2 FAQs,” accessed Oct. 2, 2026. [Online]. Available: https://aws.amazon.com/ec2/faqs/ ↩
[69]A. Honig and N. Porter, “7 ways we harden our KVM hypervisor at Google Cloud: security in plaintext,” Google Cloud Blog, Jan. 25, 2017. [Online]. Available: https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext ↩
[70]“MAINTAINERS,” Linux 7.2, torvalds/linux repository. [Online]. Available: https://github.com/torvalds/linux/blob/v7.2/MAINTAINERS ↩
[71]S. McCanne and V. Jacobson, “The BSD Packet Filter: A New Architecture for User-level Packet Capture,” Lawrence Berkeley Laboratory, Dec. 19, 1992. [Online]. Available: https://www.tcpdump.org/papers/bpf-usenix93.pdf ↩
[72]A. Starovoitov, “net: filter: rework/optimize internal BPF interpreter's instruction set,” commit bd4cf0ed331a, Mar. 28, 2014. [Online]. Available: https://github.com/torvalds/linux/commit/bd4cf0ed331a275e9bf5a49e6d0fd55dffc551b8 ↩
[73]A. Starovoitov, “bpf: introduce BPF syscall and maps,” commit 99c55f7d47c0, Sep. 26, 2014. [Online]. Available: https://github.com/torvalds/linux/commit/99c55f7d47c0dc6fc64729f37bf435abf43f4c60 ↩
[74]J. Corbet, “Ktap or BPF?,” LWN.net, Apr. 23, 2014. [Online]. Available: https://lwn.net/Articles/595565/ ↩
[75]T. Høiland-Jørgensen, J. D. Brouer, D. Borkmann, J. Fastabend, T. Herbert, D. Ahern and D. Miller, “The eXpress Data Path: Fast Programmable Packet Processing in the Operating System Kernel,” in Proc. CoNEXT '18, 2018, doi: 10.1145/3281411.3281443. [Online]. Available: https://github.com/tohojo/xdp-paper ↩
[76]B. Blanco, “bpf: add XDP prog type for early driver filter,” commit 6a773a15a1e8, Jul. 19, 2016. [Online]. Available: https://github.com/torvalds/linux/commit/6a773a15a1e8874e5eccd2f29190c31085912c95 ↩
[77]J. Corbet, “BPF at Facebook (and beyond),” LWN.net, Oct. 10, 2019. [Online]. Available: https://lwn.net/Articles/801871/ ↩
[78]K. P. Singh, “bpf: Introduce BPF_PROG_TYPE_LSM,” commit fc611f47f218, Mar. 29, 2020. [Online]. Available: https://github.com/torvalds/linux/commit/fc611f47f2188ade2b48ff6902d5cce8baac0c58 ↩
[79]J. Corbet, “KRSI — the other BPF security module,” LWN.net, Dec. 27, 2019. [Online]. Available: https://lwn.net/Articles/808048/ ↩
[80]D. Thaler, Ed., “BPF Instruction Set Architecture (ISA),” RFC 9669, Internet Engineering Task Force, Oct. 2024. [Online]. Available: https://www.rfc-editor.org/rfc/rfc9669.html ↩
[81]J. Corbet, “Ringing in a new asynchronous I/O API,” LWN.net, Jan. 15, 2019. [Online]. Available: https://lwn.net/Articles/776703/ ↩
[82]J. Axboe, “Add io_uring IO interface,” commit 2b188cc1bb85, Jan. 7, 2019. [Online]. Available: https://github.com/torvalds/linux/commit/2b188cc1bb857a9d4701ae59aa7768b5124e262e ↩
[83]J. Axboe, public GitHub profile (declared company), accessed Oct. 2, 2026. [Online]. Available: https://github.com/axboe ↩
[84]T. Koczka, “Learnings from kCTF VRP's 42 Linux kernel exploits submissions,” Google Online Security Blog, Jun. 14, 2023. [Online]. Available: https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html ↩
[85]M. Rizzo, “io_uring: add a sysctl to disable io_uring system-wide,” commit 76d3ccecfa18, Aug. 21, 2023. [Online]. Available: https://github.com/torvalds/linux/commit/76d3ccecfa186af3120e206d62f03db1a94a535f ↩
[86]C. Mason, “[ANNOUNCE] Btrfs: a copy on write, snapshotting FS,” message on the linux-kernel mailing list, Jun. 12, 2007. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0706.1/1732.html ↩
[87]O. Rodeh, J. Bacik and C. Mason, “BTRFS: The Linux B-Tree Filesystem,” ACM Transactions on Storage, vol. 9, no. 3, 2013, doi: 10.1145/2501620.2501623. [Online]. Available: https://doi.org/10.1145/2501620.2501623 ↩
[88]Kernelnewbies, “Linux 2.6.29,” Mar. 23, 2009. [Online]. Available: https://kernelnewbies.org/Linux_2_6_29 ↩
[89]J. Corbet, “Btrfs at Facebook,” LWN.net, Jul. 2, 2020. [Online]. Available: https://lwn.net/Articles/824855/ ↩
[90]Red Hat, “Btrfs (Technology Preview),” in Red Hat Enterprise Linux 7 Storage Administration Guide. [Online]. Available: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-btrfs ↩
[91]Fedora Project, “Changes/BtrfsByDefault,” Fedora Project Wiki. [Online]. Available: https://fedoraproject.org/wiki/Changes/BtrfsByDefault ↩
[92]A. Sweeney, D. Doucette, W. Hu, C. Anderson, M. Nishimoto and G. Peck, “Scalability in the XFS File System,” in Proc. USENIX 1996 Annual Technical Conference, 1996. [Online]. Available: https://www.usenix.org/legacy/publications/library/proceedings/sd96/sweeney.html ↩
[93]L. Torvalds, “Linux 2.5.36,” message on the linux-kernel mailing list, Sep. 17, 2002. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0209.2/0514.html ↩
[94]Red Hat, “The XFS File System,” in Red Hat Enterprise Linux 7 Storage Administration Guide. [Online]. Available: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-xfs ↩
[95]D. J. Wong, “xfs: create an ioctl to scrub AG metadata,” commit 36fd6e863cb7, Oct. 17, 2017. [Online]. Available: https://github.com/torvalds/linux/commit/36fd6e863cb7329ab2e5687fdae4e4626b840adc ↩
[96]I. Molnar, “[announce] [patch] ultra-scalable O(1) SMP and UP scheduler,” message on the linux-kernel mailing list, Jan. 3, 2002. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0201.0/0810.html ↩
[97]J. Corbet, “The Rotating Staircase Deadline Scheduler,” LWN.net, Mar. 6, 2007. [Online]. Available: https://lwn.net/Articles/224865/ ↩
[98]I. Molnar, “[Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS],” message on the linux-kernel mailing list, Apr. 13, 2007. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0704.1/2138.html ↩
[99]I. Molnar, “sched: cfs core code,” commit dd41f596cda0, Jul. 9, 2007. [Online]. Available: https://github.com/torvalds/linux/commit/dd41f596cda0d7d6e4a8b139ffdfabcefdd46528 ↩
[100]I. Stoica and H. Abdel-Wahab, “Earliest Eligible Virtual Deadline First: A Flexible and Accurate Mechanism for Proportional Share Resource Allocation,” Old Dominion University, technical report TR-95-22, 1995. [Online]. Available: https://people.eecs.berkeley.edu/~istoica/papers/eevdf-tr-95.pdf ↩
[101]J. Corbet, “An EEVDF CPU scheduler for Linux,” LWN.net, Mar. 9, 2023. [Online]. Available: https://lwn.net/Articles/925371/ ↩
[102]“EEVDF Scheduler,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/scheduler/sched-eevdf.html ↩
[103]P. Zijlstra, “sched/fair: Implement an EEVDF-like scheduling policy,” commit 147f3efaa241, May 31, 2023. [Online]. Available: https://github.com/torvalds/linux/commit/147f3efaa24182a21706bca15eab2f3f4630b5fe ↩
[104]J. Corbet, “The extensible scheduler class,” LWN.net, Feb. 10, 2023. [Online]. Available: https://lwn.net/Articles/922405/ ↩
[105]J. Corbet, “Extensible scheduler class to be merged for 6.11,” LWN.net, Jun. 11, 2024. [Online]. Available: https://lwn.net/Articles/978007/ ↩
[106]T. Heo, “sched_ext: Implement BPF extensible scheduler class,” commit f0e1a0643a59, Jun. 18, 2024. [Online]. Available: https://github.com/torvalds/linux/commit/f0e1a0643a59bf1f922fa209cec86a170b784f3f ↩
[107]T. Heo, public GitHub profile (declared company), accessed Oct. 2, 2026. [Online]. Available: https://github.com/htejun ↩
[108]“Extensible Scheduler Class,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/scheduler/sched-ext.html ↩
[109]ProPublica, “The Linux Foundation (EIN 46-0503801),” Nonprofit Explorer, IRS Form 990 data, accessed Oct. 2, 2026. [Online]. Available: https://projects.propublica.org/nonprofits/organizations/460503801 ↩
[110]L. Torvalds, “Linux 4.2-rc1,” message on the linux-kernel mailing list, Jul. 5, 2015. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/1507.0/02156.html ↩
[111]A. Deucher, “drm/amdgpu: add core driver (v4),” commit d38ceaf99ed0, Apr. 20, 2015. [Online]. Available: https://github.com/torvalds/linux/commit/d38ceaf99ed015f2a0b9af3499791bd3a3daae21 ↩
[112]M. Brost et al., “drm/xe: Introduce a new DRM driver for Intel GPUs,” commit dd08ebf6c352, Mar. 30, 2023. [Online]. Available: https://github.com/torvalds/linux/commit/dd08ebf6c3525a7ea2186e636df064ea47281987 ↩
[113]Kernelnewbies, “Linux 2.6.33,” Feb. 24, 2010. [Online]. Available: https://kernelnewbies.org/Linux_2_6_33 ↩
[114]NVIDIA, “NVIDIA Releases Open-Source GPU Kernel Modules,” NVIDIA Technical Blog, May 2022. [Online]. Available: https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/ ↩
[115]D. Krummrich, “gpu: nova-core: add initial driver stub,” commit 54e6baf123fd, Mar. 6, 2025. [Online]. Available: https://github.com/torvalds/linux/commit/54e6baf123fde089cfa9f609b0b39b40abe41e94 ↩
[116]E. Cohen, “mlx5: Add driver for Mellanox Connect-IB adapters,” commit e126ba97dba9, Jul. 7, 2013. [Online]. Available: https://github.com/torvalds/linux/commit/e126ba97dba9edeb6fafa3665b5f8497fc9cdf8c ↩
[117]NVIDIA, “NVIDIA Completes Acquisition of Mellanox, Creating Major Force Driving Next-Gen Data Centers,” press release, Apr. 27, 2020. [Online]. Available: https://nvidianews.nvidia.com/news/nvidia-completes-acquisition-of-mellanox-creating-major-force-driving-next-gen-data-centers ↩
[118]“patch-2.2.14.gz,” kernel.org archive file, Jan. 4, 2000. [Online]. Available: https://cdn.kernel.org/pub/linux/kernel/v2.2/patch-2.2.14.gz ↩
[119]“patch-2.5.5.gz,” kernel.org archive file, Feb. 20, 2002. [Online]. Available: https://cdn.kernel.org/pub/linux/kernel/v2.5/patch-2.5.5.gz ↩
[120]J. Edge, “Linaro seeks to simplify ARM Linux landscape,” LWN.net, Jun. 9, 2010. [Online]. Available: https://lwn.net/Articles/391189/ ↩
[121]L. Torvalds, “Re: [GIT PULL] omap changes for v2.6.39 merge window,” message on the linux-kernel mailing list, Mar. 17, 2011. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/1103.2/01004.html ↩
[122]J. Corbet, “Supporting 64-bit ARM systems,” LWN.net, Jul. 10, 2012. [Online]. Available: https://lwn.net/Articles/506148/ ↩
[123]C. Marinas, “arm64: Kernel booting and initialisation,” commit 9703d9d7f77c, Mar. 5, 2012. [Online]. Available: https://github.com/torvalds/linux/commit/9703d9d7f77ce129621f7d80a844822e2daa7008 ↩
[124]B. Swetland, “[ARM] msm: board file for MACH_HALIBUT (QCT MSM7200A),” commit 9e73c84c89b7, Nov. 26, 2007. [Online]. Available: https://github.com/torvalds/linux/commit/9e73c84c89b7c91ad5d6a141c58efbbe139f6b6c ↩
[125]“MAINTAINERS,” Linux 2.6.35, torvalds/linux repository. [Online]. Available: https://github.com/torvalds/linux/blob/v2.6.35/MAINTAINERS ↩
[126]P. Dabbelt, “RISC-V: Init and Halt Code,” commit 76d2a0493a17, Jul. 10, 2017. [Online]. Available: https://github.com/torvalds/linux/commit/76d2a0493a17d4c8ecc781366850c3c4f8e1a446 ↩
[127]“MAINTAINERS,” Linux 4.15, torvalds/linux repository. [Online]. Available: https://github.com/torvalds/linux/blob/v4.15/MAINTAINERS ↩
[128]I. Molnar, “[patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0,” message on the linux-kernel mailing list, Oct. 13, 2004. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0410.1/1577.html ↩
[129]“Lock types and their rules,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/locking/locktypes.html ↩
[130]T. Gleixner, “genirq: add threaded interrupt handler support,” commit 3aa551c9b4c4, Mar. 23, 2009. [Online]. Available: https://github.com/torvalds/linux/commit/3aa551c9b4c40018f0e261a178e3d25478dc04a9 ↩
[131]T. Gleixner, “sched/rt, Kconfig: Introduce CONFIG_PREEMPT_RT,” commit a50a3f4b6a31, Jul. 17, 2019. [Online]. Available: https://github.com/torvalds/linux/commit/a50a3f4b6a313dc76912bd4ad3b8b4f4b479c801 ↩
[132]The Linux Foundation, “The Linux Foundation Announces Project to Advance Real-Time Linux,” press release reproduced by Firmenpresse, Oct. 2015. [Online]. Available: https://www.firmenpresse.de/pressrelease424560/the-linux-foundation-announces-project-to-advance-real-time-linux.html ↩
[133]J. Corbet, “Intel acquires Linutronix,” LWN.net, Feb. 23, 2022. [Online]. Available: https://lwn.net/Articles/885903/ ↩
[134]L. Torvalds, “Merge tag 'printk-for-6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux,” commit c903327d3295, Sep. 17, 2024. [Online]. Available: https://github.com/torvalds/linux/commit/c903327d3295b135eb8c81ebe0b68c1837718eb8 ↩
[135]S. A. Siewior, “x86: Allow to enable PREEMPT_RT.,” commit d2d6422f8bd1, Sep. 6, 2024. [Online]. Available: https://github.com/torvalds/linux/commit/d2d6422f8bd17c6bb205133e290625a564194496 ↩
[136]L. Torvalds, “Merge tag 'sched-rt-2024-09-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip,” commit baeb9a7d8b60, Sep. 20, 2024. [Online]. Available: https://github.com/torvalds/linux/commit/baeb9a7d8b60b021d907127509c44507539c15e5 ↩
[137]J. Edge, “Rust heads into the kernel?,” LWN.net, Apr. 21, 2021. [Online]. Available: https://lwn.net/Articles/853423/ ↩
[138]J. Aas, “Supporting Miguel Ojeda's Work on Rust in the Linux Kernel,” Prossimo (ISRG), Jun. 17, 2021. [Online]. Available: https://www.memorysafety.org/blog/supporting-miguel-ojeda-rust-in-linux/ ↩
[139]L. Torvalds, “Merge tag 'rust-v6.1-rc1' of https://github.com/Rust-for-Linux/linux,” commit 8aebac82933f, Oct. 3, 2022. [Online]. Available: https://github.com/torvalds/linux/commit/8aebac82933ff1a7c8eede18cab11e1115e2062b ↩
[140]A. Ryhl, “rust_binder: add Rust Binder driver,” commit eafedbc7c050, Sep. 19, 2025. [Online]. Available: https://github.com/torvalds/linux/commit/eafedbc7c050c44744fbdf80bdf3315e860b7513 ↩
[141]J. Corbet, “The state of the kernel Rust experiment,” LWN.net, Dec. 13, 2025. [Online]. Available: https://lwn.net/Articles/1050174/ ↩
[142]M. Ojeda, “rust: conclude the Rust experiment,” commit 9fa7153c31a3, Dec. 13, 2025. [Online]. Available: https://github.com/torvalds/linux/commit/9fa7153c31a3e5fe578b83d23bc9f185fde115da ↩
[143]G. Krisman Bertazi, “futex: Implement mechanism to wait on any of several futexes,” patch reproduced on LWN.net, Jul. 30, 2019. [Online]. Available: https://lwn.net/Articles/794969/ ↩
[144]A. Almeida, “futex: Implement sys_futex_waitv(),” commit bf69bad38cf6, Sep. 23, 2021. [Online]. Available: https://github.com/torvalds/linux/commit/bf69bad38cf63d980e8a603f8d1bd1f85b5ed3d9 ↩
[145]Kernelnewbies, “Linux 5.16,” Jan. 9, 2022. [Online]. Available: https://kernelnewbies.org/Linux_5.16 ↩
[146]The kernel development community, “2. How the development process works,” in A guide to the Kernel Development Process, The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/process/2.Process.html ↩
[147]The kernel development community, “Everything you ever wanted to know about Linux -stable releases,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/process/stable-kernel-rules.html ↩
[148]kernel.org, “Releases,” accessed Oct. 2, 2026. [Online]. Available: https://www.kernel.org/category/releases.html ↩
[149]J. Corbet, “A turning point for CVE numbers,” LWN.net, Feb. 14, 2024. [Online]. Available: https://lwn.net/Articles/961332/ ↩
[150]The kernel development community, “CVEs,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/process/cve.html ↩
[151]LWN.net, “Kroah-Hartman: Linux CVEs, more than you ever wanted to know,” LWN.net, Dec. 10, 2025. [Online]. Available: https://lwn.net/Articles/1049963/ ↩
[152]The Linux Foundation, Annual Report 2025. The Linux Foundation, Dec. 2025. [Online]. Available: https://www.linuxfoundation.org/hubfs/Publications/2025%20Linux%20Foundation%20Annual%20Report_122225a_lr.pdf ↩
[153]The Linux Foundation, “Technical Advisory Board,” accessed Oct. 2, 2026. [Online]. Available: https://www.linuxfoundation.org/about/technical-advisory-board ↩
[154]Linux Plumbers Conference, contribution page of J. Kicinski, LPC 2025. [Online]. Available: https://lpc.events/event/19/contributions/2289/ ↩
[155]Open Source Summit North America 2025, talk page of D. Borkmann. [Online]. Available: https://ossna2025.sched.com/event/d3d6bc22578712b8eca7f0c202b195f5 ↩
[156]J. Corbet, “A new era for memory-management maintainership,” LWN.net, May 7, 2026. [Online]. Available: https://lwn.net/Articles/1070994/ ↩
[157]The Linux Foundation, Annual Report 2024. The Linux Foundation, Dec. 2024. [Online]. Available: https://linuxfoundation.org/hubfs/Reports/lf_ar24_121524a.pdf ↩
[158]M. Ojeda, “2025 LF Technical Advisory Board election - update,” message on the linux-kernel mailing list, Dec. 5, 2025. [Online]. Available: https://lkml.iu.edu/2512.0/05847.html ↩
[159]The Linux Foundation, “Bylaws,” accessed Oct. 2, 2026. [Online]. Available: https://www.linuxfoundation.org/legal/bylaws ↩
[160]M. Ojeda, “2025 LF Technical Advisory Board election - results,” message on the linux-kernel mailing list, Dec. 21, 2025. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2512.2/07130.html ↩
[161]J. Corbet, “An open seat on the TAB,” LWN.net, Dec. 8, 2025. [Online]. Available: https://lwn.net/Articles/1049035/ ↩
[162]G. Kroah-Hartman, “The Linux Kernel Driver Interface (all of your questions answered and then some),” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/process/stable-api-nonsense.html ↩
[163]J. Edge, “Moving Google toward the mainline,” LWN.net, Oct. 5, 2021. [Online]. Available: https://lwn.net/Articles/871195/ ↩
[164]B. Matheny and C. Mason, “Improving the Linux kernel with upstream contributions,” Engineering at Meta, Oct. 5, 2015. [Online]. Available: https://engineering.fb.com/2015/10/05/open-source/improving-the-linux-kernel-with-upstream-contributions/ ↩
[165]Y. Brosseau, “Upstream kernels @ Facebook,” talk at SCALE 14x, Jan. 2016. [Online]. Available: https://www.socallinuxexpo.org/scale/14x/presentations/upstream-kernels-facebook ↩
[166]Amazon Web Services, “Amazon Linux 2023 kernel lifecycle,” Amazon Linux 2023 User Guide, accessed Oct. 2, 2026. [Online]. Available: https://docs.aws.amazon.com/linux/al2023/ug/kernel-lifecycle.html ↩
[167]J. Edge, “ELC: Android and the community,” LWN.net, Apr. 14, 2010. [Online]. Available: https://lwn.net/Articles/383276/ ↩
[168]J. Corbet, “Bringing Android closer to the mainline,” LWN.net, Dec. 20, 2011. [Online]. Available: https://lwn.net/Articles/472984/ ↩
[169]J. Corbet, “Autosleep and wake locks,” LWN.net, Feb. 7, 2012. [Online]. Available: https://lwn.net/Articles/479841/ ↩
[170]Kernelnewbies, “Linux 3.5,” Jul. 21, 2012. [Online]. Available: https://kernelnewbies.org/Linux_3.5 ↩
[171]J. Corbet, “An update on the Android problem,” LWN.net, Nov. 7, 2017. [Online]. Available: https://lwn.net/Articles/738225/ ↩
[172]J. Corbet, “Bringing the Android kernel back to the mainline,” LWN.net, Nov. 15, 2018. [Online]. Available: https://lwn.net/Articles/771974/ ↩
[173]J. Corbet, “Android kernel notes from LPC 2020,” LWN.net, Sep. 10, 2020. [Online]. Available: https://lwn.net/Articles/830979/ ↩
[174]Android Open Source Project, “Generic Kernel Image (GKI) project,” source.android.com, accessed Oct. 2, 2026. [Online]. Available: https://source.android.com/docs/core/architecture/kernel/generic-kernel-image ↩
[175]Android Open Source Project, “Android common kernels,” source.android.com, accessed Oct. 2, 2026. [Online]. Available: https://source.android.com/docs/core/architecture/kernel/android-common ↩
[176]P. Galli, “Microsoft Releases Device Driver Code to the Linux Community,” Port25 (Microsoft), Jul. 20, 2009. [Online]. Available: https://learn.microsoft.com/en-us/archive/blogs/port25/microsoft-releases-device-driver-code-to-the-linux-community ↩
[177]G. Kroah-Hartman, “[patch 00/54] [Announce] Microsoft Hyper-V drivers for Linux,” message on the linux-kernel mailing list, Jul. 20, 2009. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/0907.2/01249.html ↩
[178]The Linux Foundation, “Microsoft Fortifies Commitment to Open Source, Becomes Linux Foundation Platinum Member,” press release, Nov. 16, 2016. [Online]. Available: https://www.linuxfoundation.org/press/press-release/microsoft-fortifies-commitment-to-open-source-becomes-linux-foundation-platinum-member ↩
[179]Microsoft, “WSL2-Linux-Kernel: The source for the Linux kernel used in Windows Subsystem for Linux 2 (WSL2),” GitHub repository. [Online]. Available: https://github.com/microsoft/WSL2-Linux-Kernel ↩
[180]Sony Interactive Entertainment, “Open Source Software used in PlayStation®4,” accessed Oct. 2, 2026. [Online]. Available: https://www.playstation.com/en-us/oss/ps4/ ↩
[181]Apple, “xnu,” apple-oss-distributions GitHub repository. [Online]. Available: https://github.com/apple-oss-distributions/xnu ↩
[182]J. Looney, “Netflix and FreeBSD: Reflections on Running FreeBSD Head in Production,” BSDCan 2019, 2019. [Online]. Available: https://papers.freebsd.org/2019/bsdcan/looney-netflix_and_freebsd/ ↩
[183]K. Vervloesem, “Illumos: new hope for the OpenSolaris community?,” LWN.net, Aug. 11, 2010. [Online]. Available: https://lwn.net/Articles/399533/ ↩
[184]J. Lerner and J. Tirole, “Some Simple Economics of Open Source,” The Journal of Industrial Economics, vol. 50, no. 2, pp. 197–234, 2002, doi: 10.1111/1467-6451.00174. Working paper version: NBER Working Paper 7600, 2000. [Online]. Available: https://www.nber.org/papers/w7600 ↩
[185]J. West and S. Gallagher, “Challenges of open innovation: the paradox of firm investment in open-source software,” R&D Management, vol. 36, no. 3, pp. 319–331, 2006, doi: 10.1111/j.1467-9310.2006.00436.x. [Online]. Available: https://scholarworks.sjsu.edu/org_mgmt_pub/3 ↩
[186]J. Henkel, “Selective revealing in open innovation processes: The case of embedded Linux,” Research Policy, vol. 35, no. 7, pp. 953–969, 2006, doi: 10.1016/j.respol.2006.04.010. [Online]. Available: https://doi.org/10.1016/j.respol.2006.04.010 ↩
[187]M. Hoffmann, F. Nagle and Y. Zhou, “The Value of Open Source Software,” Harvard Business School, Working Paper 24-038, 2024. [Online]. Available: https://www.hbs.edu/ris/Publication%20Files/24-038_51f8444f-502c-4139-8bf2-56eb4b65c58a.pdf ↩
[188]N. Eghbal, Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure. Ford Foundation, 2016. [Online]. Available: https://www.fordfoundation.org/wp-content/uploads/2016/07/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure.pdf ↩
[189]Google, “syzkaller: an unsupervised coverage-guided kernel fuzzer,” GitHub repository (created Oct. 12, 2015). [Online]. Available: https://github.com/google/syzkaller ↩
[190]Google, “syzbot,” syzkaller documentation. [Online]. Available: https://github.com/google/syzkaller/blob/master/docs/syzbot.md ↩
[191]D. Vyukov, “Reflections on kernel development process, quality and testing,” presentation at the Linux Kernel Maintainers Summit, 2019. [Online]. Available: https://lpc.events/event/4/contributions/554/attachments/353/584/Reflections__Kernel_Summit_2019.pdf ↩
[192]syzbot, “Linux upstream,” painel accessed Oct. 2, 2026. [Online]. Available: https://syzkaller.appspot.com/upstream ↩
[193]M. Kerrisk, “KS2012: Kernel build/boot testing,” LWN.net, Sep. 5, 2012. [Online]. Available: https://lwn.net/Articles/514278/ ↩
[194]Intel, “lkp-tests: Linux Kernel Performance tests,” GitHub repository. [Online]. Available: https://github.com/intel/lkp-tests ↩
[195]J. Corbet, “Some 5.5 kernel development statistics,” LWN.net, Jan. 28, 2020. [Online]. Available: https://lwn.net/Articles/810639/ ↩
[196]The Linux Foundation, “Distributed Linux Testing Platform KernelCI Secures Funding and Long-Term Sustainability as New Linux Foundation Project,” press release reproduced on kernelci.org, Oct. 28, 2019. [Online]. Available: https://kernelci.org/?p=56 ↩
[197]KernelCI, home page and member list, accessed Oct. 2, 2026. [Online]. Available: https://kernelci.org/ ↩
[198]A. Ryabinin, “kasan: add kernel address sanitizer infrastructure,” commit 0b24becc810d, Feb. 13, 2015. [Online]. Available: https://github.com/torvalds/linux/commit/0b24becc810dc3be6e3f94103a866f214c282394 ↩
[199]M. Elver, “kcsan: Add Kernel Concurrency Sanitizer infrastructure,” commit dfd402a4c4ba, Nov. 14, 2019. [Online]. Available: https://github.com/torvalds/linux/commit/dfd402a4c4baae42398ce9180ff424d589b8bffc ↩
[200]J. Corbet, “5.8 Merge window, part 2,” LWN.net, Jun. 14, 2020. [Online]. Available: https://lwn.net/Articles/822527/ ↩
[201]A. Potapenko, “kmsan: add KMSAN runtime core,” commit f80be4571b19, Sep. 15, 2022. [Online]. Available: https://github.com/torvalds/linux/commit/f80be4571b19b9fd8dd1528cd2a2f123aff51f70 ↩
[202]A. Morton, “[GIT PULL] MM updates for 6.1-rc1,” message on the linux-kernel mailing list, Oct. 8, 2022. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2210.1/00272.html ↩
[203]B. Higgins, “kunit: test: add KUnit test runner core,” commit 914cc63eea6f, Sep. 23, 2019. [Online]. Available: https://github.com/torvalds/linux/commit/914cc63eea6fbe11ed46dba5e4438d81b0cd42d2 ↩
[204]The kernel development community, “Linux Kernel Selftests,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/dev-tools/kselftest.html ↩
[205]J. Corbet, “Reducing kernel-maintainer burnout,” LWN.net, Nov. 24, 2023. [Online]. Available: https://lwn.net/Articles/952034/ ↩
[206]J. Edge, “Maintainers don't scale,” LWN.net, Jun. 6, 2022. [Online]. Available: https://lwn.net/Articles/896918/ ↩
[207]M. Zhou, Q. Chen, A. Mockus and F. Wu, “On the scalability of Linux kernel maintainers' work,” in Proc. ESEC/FSE 2017, 2017, doi: 10.1145/3106237.3106287. [Online]. Available: https://par.nsf.gov/biblio/10063576 ↩
[208]L. Collin, “Re: [xz-devel] XZ for Java,” message on the xz-devel list, Jun. 8, 2022. [Online]. Available: https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html ↩
[209]A. Freund, “backdoor in upstream xz/liblzma leading to ssh server compromise,” message on the oss-security list, Mar. 29, 2024. [Online]. Available: https://www.openwall.com/lists/oss-security/2024/03/29/4 ↩
[210]J. Tan, “Tests: Update two test files.,” commit 6e636819e8f0, tukaani-project/xz repository, Mar. 9, 2024. [Online]. Available: https://github.com/tukaani-project/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89 ↩
[211]R. Russell et al., “Unreliable Guide To Hacking The Linux Kernel,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/kernel-hacking/hacking.html ↩
[212]C. Hellwig, “modules: inherit TAINT_PROPRIETARY_MODULE,” commit 262e6ae7081d, Jul. 28, 2020. [Online]. Available: https://github.com/torvalds/linux/commit/262e6ae7081df304fc625cf368d5c2cbba2bb991 ↩
[213]J. Corbet, “Making life (even) harder for proprietary modules,” LWN.net, Aug. 3, 2023. [Online]. Available: https://lwn.net/Articles/939842/ ↩
[214]M. Larabel, “Linus Torvalds Calls NVIDIA The Worst Company,” Phoronix, Jun. 17, 2012 (secondary source). [Online]. Available: https://www.phoronix.com/news/MTEyMTc ↩
[215]L. Torvalds, “Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation,” message on the linux-kernel mailing list, Jan. 21, 2018. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html ↩
[216]The kernel development community, “Embargoed hardware issues,” The Linux Kernel documentation. [Online]. Available: https://docs.kernel.org/process/embargoed-hardware-issues.html ↩
[217]G. Kroah-Hartman, “MAINTAINERS: Remove some entries due to various compliance requirements.,” commit 6e90b675cf94, Oct. 18, 2024. [Online]. Available: https://github.com/torvalds/linux/commit/6e90b675cf942e50c70e8394dfb5862975c3b3b2 ↩
[218]J. Corbet, “Several Russian developers lose kernel maintainership status,” LWN.net, Oct. 22, 2024, with updates. [Online]. Available: https://lwn.net/Articles/995186/ ↩
[219]P. Moore, “Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.,” message on the linux-kernel mailing list, Oct. 2024. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2410.2/09875.html ↩
[220]J. Bottomley, “Re: [PATCH] MAINTAINERS: Remove some entries due to various compliance requirements.,” message on the linux-kernel mailing list, Oct. 24, 2024. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2410.3/01081.html ↩
[221]W. Almeida Filho, “[PATCH 0/1] Retiring from the Rust for Linux project,” message on the kernel mailing lists, Aug. 28, 2024. [Online]. Available: https://patchew.org/linux/20240828211117.9422-1-wedsonaf@gmail.com ↩
[222]C. Hellwig, “Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.,” message on the linux-kernel mailing list, Jan. 28, 2025. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2501.3/03615.html ↩
[223]C. Hellwig, “Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.,” message on the linux-kernel mailing list, Jan. 31, 2025. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2501.3/06788.html ↩
[224]L. Torvalds, reply to H. Martin in the Rust DMA abstraction thread, linux-kernel mailing list, Feb. 6, 2025. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2502.0/07186.html ↩
[225]H. Martin, “[PATCH] MAINTAINERS: Remove myself,” message on the linux-kernel mailing list, Feb. 2025. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2502.0/07276.html ↩
[226]L. Torvalds, “Re: Rust kernel policy,” message on the linux-kernel mailing list, Feb. 20, 2025. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2502.2/08504.html ↩
[227]Rust for Linux, “Rust kernel policy,” accessed Oct. 2, 2026. [Online]. Available: https://rust-for-linux.com/rust-kernel-policy ↩
[228]L. Torvalds, “MAINTAINERS: mark bcachefs externally maintained,” commit ebf2bfec412a, Aug. 28, 2025. [Online]. Available: https://github.com/torvalds/linux/commit/ebf2bfec412ad293a0b118fb1a20a551088ebc9b ↩
[229]L. Torvalds, “Remove bcachefs core code,” commit f2c61db29f27, Sep. 29, 2025. [Online]. Available: https://github.com/torvalds/linux/commit/f2c61db29f277b9c80de92102fc532cc247495cd ↩
[230]Linux Foundation Technical Advisory Board, “Report on University of Minnesota Breach-of-Trust Incident,” message on the linux-kernel mailing list, May 5, 2021. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2105.0/04009.html ↩
[231]S. Smalley, “selinux: de-brand SELinux,” commit 90aa4f5e92f2, Jul. 18, 2023. [Online]. Available: https://github.com/torvalds/linux/commit/90aa4f5e92f2797c3c86e05f588ab277b0e0ba39 ↩
[232]P. Moore, “[GIT PULL] SELinux patches for v6.6,” message on the linux-kernel mailing list, Aug. 29, 2023. [Online]. Available: https://lkml.iu.edu/hypermail/linux/kernel/2308.3/05977.html ↩