Kernel Linux 3.2 está disponível para download

Menos de dois meses passaram da disponibilização do kernel Linux 3.1 e Linus Torvalds anunciou recentemente a versão 3.2. O kernel é considerado o coração de qualquer sistema operativo e é responsável por criar uma camada de abstracção entre entidades de alto nível e o hardware da máquina.

O kernel Linux 3.2 traz algumas novidades interessantes, tendo contado com 11881 contribuições de código. O kernel Linux 3.2 tem actualmente cerca de 15 milhões de linhas de código.

kernel_00

Tal como referido, o kernel Linux 3.2 traz muitas novidades das quais se destacam:

  •  Suporte melhorado para sistemas de ficheiros EXT4
    • Através da técnica denominada de bigalloc, é possível usar blocos com mais de 4KB até 1 MB;
  • Suporte para Btrfs
    • Várias correcções no sentido de resolver o problema que poderia levar partições a ficarem corrompidas devido a problemas do sistema ou falhas de energia
  • Integrado o driver Brcm80211 da Broadcom e driver Ath6kl para placas de rede que usam o chip Atheros AR6003;
  • Melhorias a nível do uso da pilha protocolar TCP/IP
  • Suporte para a arquitectura de processadores da Qualcomm Hexagon
  • Integração do driver Nouveau que tem a capacidade de usar as funções de aceleração gráfica disponível com os firmware autogerados nos núcleos Fermi NVC1, NVC8 e NVCF;
  • Controlo a nível de período de execução do processador para os processos

Todas as novidades do kernel 3.2 podem ser consultadas aqui

Como sempre, o Kernel está disponível para download no site kernel.org e também via GitHub.

Artigos relacionados

Homepage: Kernel.org

  
     Pin It  

Arquivado na categoria: Linux


28 Comentários

  1. Alguns utilizadores estão a ter problemas ao instalar este kernel, ficando o seu sistema num “infinite loop” no arranque, embora pareça que na realidade o sistema nem sequer arranca.

    Fonte:
    http://www.phoronix.com/scan.php?page=news_item&px=MTAzNzk

    No meu caso não tive qualquer problema. No entanto, devem ter este factor em conta se estão a pensar instalar este kernel.

  2. Boas..
    Parabéns pela publicação Pedro ;)

    especialmente gosto da possiblidade de escolha de tamanho dos blocos na disco para ext4, para além de aumentarem a velocidade de escrita,diminuem ainda mais a fragmentação.

    Gosto do controlo de IO de info buferizada para o disco, esta muito bom mesmo :)

    e gosto tanto ou mais ainda dos processos poderem “saltar” fora do processador a partir de determinada quota de tempo predefinida para o grupo que pertencem(mesmo não excedido o quantum time), isto aumenta especialmente a velocidade, pois processos pequenos não precisam de tanto tempo para correrem no CPU.
    e gosto de tudo o resto…heheh este kernel está a ficar infernal!!

    continua o bom trabalho

    cmps

    • Obrigado @lmx
      Já me apercebi ao longo de alguns comentários, que dominas os assuntos associados aos sistemas operativos…paginação/segmentação, system calls, swapping, fragmentação interna/externa, schedule, PCB…. :)

      Entra em contacto comigo para escrevermos uns artigos de sistemas operativos com temas mais aprofundados.

      Um abraço e bom fim de semana
      PP

      • Boas…
        Obrigado pelo convite Pedro, gostava de facto de fazer alguma coisa relativa ao assunto, não sei o que em concreto,tu já desbravas-te muito caminho ;) .

        Não domino todos os assuntos de Sistemas Operativos, mas gosto muito da area e tenho um especial interesse por assuntos relacionados com sistemas operativos :P , ha uns que domino melhor que outros, é como tudo na vida…
        De momento ando meio sem tempo, não me estou a “curtar”(salve seja :) ), fica prometido daqui a um mês-mês e meio…pois daqui a algum tempo estarei mais liberto ;)

        Um abraço, bom fim de semana

    • Boas lmx.

      Concordo plenamente com o teu comentário ácerca dos blocos de ext4 no disco. Fiz muitos testes nos meus Androids com blocks de tamanhos diferentes, e sem dúvida que blocks e inodes com 4096kb traziam uma melhoria gigante em termos de desempenho. Em relação à fragmentação não posso dar o meu contributo, pois creio (não tenho a certeza) que flash devices não sofrem de fragmentação.

      O CFS bandwith é certamente uma adição interessante nos Desktops mas a nível de Android (plataforma com que eu trabalho) não é muito bem vinda. Por exemplo há algumas tasks que forçosamente têm que ser terminadas, e mesmo que demorem mais tempo não podem ser throttled e ficarem à espera da próxima altura disponível para resumirem para o seu estado anterior e terminarem o que estavam a fazer. Vamos imaginar uma task que demora X+1000 tempo a terminar e que está a ser feita enquanto o sistema está em suspend mode (ecrã desligado), mas o algorítmo só permite a realização de X+500 agora, e os outros 500 passado 10 horas. O que vai acontecer é que o telemóvel vai ficar acordado essas 10 horas com uma task pendente que devia ter sido terminada. Isto vai causar um drain de bateria enorme, e isso não é o que se pretende.

      Cumps ;)

      • Boas Francisco,

        Em relação á fragmentação em dispositivos flash também não sei se existira?!
        no entanto a ideia com que fico é, fazendo um paralelismo com os discos mecano-magneticos.
        Se tivermos todo o disco cheio sem fragmentação, e apagarmos um ficheiro desse mesmo disco, esse espaço fica vazio, se apagarmos vários ficheiros, vamos ter muito provavelmente espaços vazios em varias zonas do disco…
        escrevendo agora DATA para o disco, vamos ter que ir enchendo os blocos e saltando de umas zonas vazias para outras, isto de certeza que acontece também em discos flash, digo eu não tenho a certeza?!

        Uma coisa acho que pode ser garantida, a existir fragmentação, provocará menos impacto que nos discos magnéticos, pois nestes(magnéticos) existe sempre o timeseek que anda a volta dos 12 milissegundos salvo erro, e nos discos flash o endereçamento/acesso de zonas no disco deve ser de longe bem mais rápido…penso que será idêntico ao endereçamento de uma memória RAM, pelo menos é esta a ideia que tenho(mais lento talvez, mas o principio penso que seja o mesmo da ram)…?!

        Quando escrevi acima pensei nos desktop’s :) , no entanto não sei como funcionam as coisas em dispositivos móveis…
        quando o tm entre em modo sleep o processador continua a trabalhar?!
        “Eles” dizem que dará para atribuir grupos a estas aplicações que correrão durante menos tempo, se a tua aplicação não ficar nestes grupos, em principio correrá na totalidade do tempo previsto para cada app, digo eu?!

        cmps

  3. Então e o consumo de bateria excessivo? Já resolveram?

  4. Bom artigo Pedro, mas esqueceste-te de nomear algumas coisas na lista das tais principais novidades, das quais eu destaco:

    I/O-less dirty throttling, reduce filesystem writeback from page reclaim

    e

    TCP Proportional Rate Reduction

    Esta última vem da Google e trouxe me melhorias a nível de velocidade e consistência da minha internet móvel/wifi no meu Android.

    Consegui aproveitar alguns destes patches introduzidos na kernel 3.2 e coloquei-os na do Android, e devo dizer que melhoram substencialmente o desempenho do meu terminal, em particular o patch do I/O que já vinha sendo melhorado deste o kernel 3.1 com a introdução do Dynamic Writeback.

    Vamos ver o que o futuro nos reserva, mas com kernels destas só podemos esperar o melhor, pois estão cada vez mais robustas.

Deixe o seu comentário

Aviso: Todo e qualquer texto publicado na internet através deste sistema não reflete, necessariamente, a opinião deste site ou do(s) seu(s) autor(es). Os comentários publicados através deste sistema são de exclusiva e integral responsabilidade e autoria dos leitores que dele fizerem uso. O autor deste site reserva-se, desde já, o direito de excluir comentários e textos que julgar ofensivos, difamatórios, caluniosos, preconceituosos ou de alguma forma prejudiciais a terceiros. Textos de caráter promocional ou inseridos no sistema sem a devida identificação do seu autor (nome completo e endereço válido de email) também poderão ser excluídos.