Na < http://blogs.forumpcs.com.br/bpiropo/2012/03/11/uefi-vantagens-e-suporte/ > coluna anterior examinamos algumas das vantagens que os sistemas baseados em UEFI oferecem quando comparados ao velho BIOS, citamos alguns sistemas operacionais que já oferecem suporte à especificação UEFI e encerramos a coluna informando que discutiríamos hoje a forma pela qual é feito o gerenciamento das partições nos dispositivos de armazenamento de massa e os serviços que a UEFI pode oferecer mesmo depois que o controle da máquina passa às mãos do sistema operacional. Então vamos adiante.

Colaborando com o SO

Diferentemente dos sistemas baseados em BIOS, que seguem um procedimento praticamente inflexível desde o momento em que a máquina é ligada até saírem completamente de cena quando o sistema operacional é carregado e assume o controle total da máquina, os sistemas baseados em UEFI podem prolongar sua ação mesmo após a carga do sistema operacional. Isto é conseguido subdividindo os “serviços” fornecidos pela UEFI em duas categorias, como mencionado na coluna < http://blogs.forumpcs.com.br/bpiropo/2012/03/09/uefi-como-funciona/ > “UEFI: Como funciona”: “serviços de inicialização” (“boot services”) e “serviços em tempo de execução” (“runtime services”). Vamos ver como isto funciona.

A Figura 1 (obtida em um artigo técnico da MS) mostra um diagrama simplificado do fluxo de inicialização de um sistema baseado em UEFI ao carregar Windows. As ações se desencadeiam a partir do topo do diagrama e o primeiro passo, representado pelo objeto “UEFI firmware”, é executado pelas rotinas incluídas no “firmware” UEFI, ou seja, nos circuitos de memória não volátil da placa-mãe que contêm as rotinas de inicialização.

As primeiras ações consistem na execução dos serviços de inicialização dos circuitos auxiliares da placa-mãe (“chipset”), seguidas do carregamento na memória dos gerenciadores de dispositivos (“drivers”) fornecidos com o hardware e das rotinas que contêm os serviços utilizados para gerenciar e auxiliar a carga do sistema operacional. Esta é a primeira fase do procedimento de partida e os “serviços” por ela carregados são os “serviços de inicialização” (“boot services”).

Os “serviços de inicialização” se limitam aos gerenciadores genéricos do “console” (teclado e vídeo) e um sistema de arquivos bastante limitado. Estas rotinas visam tornar o hardware acessível ao usuário e apenas permanecem funcionais durante a fase inicial do procedimento de partida, ao final do qual tem início o segundo passo: a carga do “UEFI boot manager”, ou gerenciador de inicialização UEFI (isto porque, como também mencionado anteriormente, as rotinas de inicialização de um sistema baseado em UEFI constituem quase um minissistema operacional e uma de suas funcionalidades é a possibilidade de gerenciar a carga de diferentes sistemas operacionais em uma mesma máquina caso o fornecedor da placa-mãe inclua o suporte a esta função no “firmware”).

A partir deste ponto passam a ser carregados os “serviços em tempo de execução” (“runtime services”). Eles incluem serviços como o gerenciamento de hora e data e suas rotinas permanecem armazenadas em um circuito de memória não volátil (mostrado na figura como NVRAM, de “Non Volatile RAM”) que podem ser acessadas pelo sistema operacional quando este último assumir o controle da máquina. Para facilitar a comunicação do SO e dos dispositivos de hardware com estas rotinas, todos os gerenciadores de dispositivos desenvolvidos de acordo com a especificação UEFI, assim como as demais rotinas que se constituem nos “serviços em tempo de execução”, se intercomunicam utilizando um protocolo específico estabelecido pela especificação UEFI.

O que dota a especificação UEFI de sua notável flexibilidade e facilita a incorporação de tecnologias como a ACPI, mencionada na coluna anterior, é justamente esta possibilidade de incluir entre as rotinas de inicialização algumas que permanecem habilitadas e ativas mesmo depois da carga do sistema operacional e são capazes de interagir com ele.

Na Figura 1 o gerenciador de inicialização UEFI carregou o Windows Boot Manager, que dá início à carga de Windows e “chama” o “Windows OS Loader” (carregador do sistema operacional Windows) que, finalmente, carrega na memória o cerne (“kernel”) do sistema. Mas, evidentemente, qualquer outro SO poderia ter sido carregado caso invocado pelo gerenciador de inicialização UEFI. E, qualquer que fosse ele, continuaria podendo interagir com os serviços em tempo de execução carregados pela UEFI.

A nova tabela de partição (GPT)

Outra diferença fundamental entre os sistemas de inicialização baseados em BIOS e UEFI é a forma pela qual são gerenciadas as partições dos meios de armazenamento de massa.

Isto porque uma das primeiras ações do procedimento de carga do sistema operacional a partir de um disco rígido na inicialização baseada em BIOS é o exame do chamado MBR (“Master Boot Record”, ou registro mestre de inicialização, localizado imediatamente no início do disco) para verificar a forma pela qual o disco se subdivide em partições, além do tamanho e localização destas partições e a identificação daquela que armazena o sistema operacional.

Ora, de acordo com as especificações do MBR, nenhum disco pode ter mais que quatro partições primárias e a capacidade do disco que contém o sistema operacional (ou seja, o chamado “disco de inicialização” ou “boot disk”) não pode exceder 2,2 TB (Terabytes).

Há algum tempo isto não representava problema algum. Discos de grande porte não excediam poucas centenas de GB e 1TB vale 1024 GB. Mas hoje em dia já se pode encontrar no mercado americano discos magnéticos de três TB por poucas centenas de dólares e logo haverá discos maiores. Portanto, embora não seja uma questão premente, cedo ou tarde o limite de 2,2TB se tornará um fator restritivo ponderável.

Já os sistemas baseados em UEFI adotam uma nova especificação para a tabela de partições. Ela se denomina GPT, de “GUID Partition Table”, e permite adotar partições com capacidade de até 9,4 ZB (Zetabytes). Como um ZB vale 1024 TB, esta nova especificação oferece a possibilidade de durar ainda um bom tempo (mas não pense que é um valor exagerado; quando eu comprei meu primeiro disco rígido há pouco mais de vinte anos, a maior capacidade admissível para uma partição era de 32 MB – isto mesmo, megabytes – e eu achei que o problema estava resolvido para sempre quando este limite foi elevado para dois GB...).

GUID é o acrônimo de “Globally unique identifier”, ou “identificador globalmente único”. A denominação não fez muito sentido? Também acho. Então, destrinchemos: um GUID é um número único usado como identificador em um dado software.

Ainda está complicado? É porque o conceito é novo. Então elaboremos mais um pouco: um GUID é um número que, em binário, pode ser expresso com 128 dígitos (portanto é um número “de 128 bits”). Como cada quatro bits pode ser convertido em um algarismo (ou caractere) hexadecimal, um GUID geralmente vem expresso sob a forma de um número hexadecimal de 32 caracteres. Basicamente, é só isso. O que, no fundo, é muito simples: um GUID é um conjunto de 32 caracteres hexadecimais que representam unicamente um determinado objeto de um conjunto.

Talvez você tenha achado isto tudo meio esquisito, mas a verdade é que muito provavelmente você já lidou com GUIDs, embora não tenha percebido. Quer ver? Se você já examinou o Registro de Windows com o editor de Registro (Regedit) deve ter se deparado com algumas entradas estranhíssimas, parecidas com isto:

{3F2504E0-4F89-11D3-9A0C-0305E82C3301}

Pois bem, cada uma delas é um GUID, um identificador único de uma “classe de objeto COM” (“Component Object Model”, um modelo usado internamente por Windows para designar objetos de diversos tipos). Este é um dos usos do GUID. Outro, talvez inesperado: aquele “mundo virtual” chamado Second Life, que esteve muito em moda há cerca de dez anos, também usava GUIDs para identificar seus objetos.

Pois muito bem: a tabela de partições tipo GPT usa GUIDs para identificar partições – e sendo o GUID um número de 128 bits, permite alocar a gigantesca capacidade de 9,4 ZB para cada partição (se quiser saber mais sobre GUIDs sugiro consultar o < http://en.wikipedia.org/wiki/Globally_Unique_Identifier > verbete correspondente da Wikipedia, edição em inglês).

Mas usar GUIDs como identificadores de partições não é a única característica nova da tabela de partições tipo GPT (embora seja a que chama mais atenção, tanto que lhe deu o nome). Por exemplo: a GPT possibilita o uso de um número muito maior de partições que as quatro permitidas pelo sistema em MBR (as versões de Windows 64 bits que usam UEFI aceitam até 128 partições, mas este limite foi imposto pela MS, não pela especificação UEFI). Além disto, não exige qualquer tipo específico de sistema de arquivos, oferece excelentes facilidades para inicialização em rede e permite redundância (fazendo com que os dados que definem a partição, ou “cabeçalho” do disco, figurem não apenas no primeiro setor do disco como também mantenham uma cópia no último para permitir recuperação caso um deles seja danificado, como mostrado na Figura 2).

Aqui não cabem maiores detalhes técnicos sobre a GPT, mas quem tiver interesse neles pode obtê-los também no < http://en.wikipedia.org/wiki/GUID_Partition_Table > verbete correspondente da edição em inglês da Wikipedia (onde foi obtida a Figura 2).

Concluindo...

Como vimos na coluna < http://blogs.forumpcs.com.br/bpiropo/2012/02/27/uefi-as-limitacoes-do-bios/ > “UEFI: As limitações do BIOS”, há muito a indústria vem tentando desenvolver alguma coisa capaz de substituir o velho BIOS, concebido para o processador i8088 e que ainda padece de algumas de suas limitações. E o sucesso tem sido escasso. Ao que parece, a Intel foi a primeira a acertar com seu EFI. E acertou ainda mais ao transformá-lo em uma especificação aberta, a UEFI, oferecendo-a ao UEFI Forum para desenvolvimento posterior.

A especificação UEFI, que já chegou à versão 2.3, é indiscutivelmente superior aos velhos sistemas baseados em BIOS e hoje em dia praticamente todo sistema operacional moderno oferece suporte a ela, como vimos na coluna anterior.

Ora, se a especificação está madura, é comprovadamente funcional (é usada em diversas máquinas de diferentes fabricantes, como Apple, IBM e HP; veja a tela de ajustes de um sistema UEFI da ASUS na Figura 3, obtida no artigo de Sebastian Anthony citado na coluna < http://blogs.forumpcs.com.br/bpiropo/2012/03/09/uefi-como-funciona/ > “UEFI: Como funciona”), então por que a maioria das máquinas novas da linha PC ainda adotam o velho sistema baseado em BIOS?

Ao que parece, por pura inércia. E, eventualmente, comodismo do tipo “se estou usando algo que funciona, por que me incomodar para implementar alguma coisa nova que, mesmo sendo melhor, oferece o risco do desconhecido?”

Sim, porque se os desenvolvedores de sistemas operacionais aderiram com entusiasmo à especificação UEFI e implementaram o devido suporte em seus SOs, as indústrias que fabricam placas-mãe não parecem compartilhar deste entusiasmo. Oferecem, sim – pelo menos teoricamente – suporte à nova especificação participando do UEFI Forum, mas fazem pouco mais que isto. Ou seja: com honrosas exceções, refugam no momento de oferecer novos produtos com “firmware” aderente à nova especificação.

A nós, usuários, resta esperar. E, quem achar que esperar não basta, ao comprar novas placas mãe, dar preferência àquelas que aderirem à especificação UEFI. Afinal, são apenas elas que garantem suporte integral aos discos rígidos com capacidade maior que dois TB que já estão começando a aparecer no mercado a preços relativamente baixos. E torcer para a estratégia funcionar...