Console no GNU/Linux

Jaboatão dos Guararapes, PE, 21 de agosto de 2014.

Eis uma tradução livre para a língua portuguesa (português brasileiro) do documento intitulado "console.txt", de autoria de Antonino Daplas.   Esse documento está armazenado sob o diretório "Documentation/console" (linux/Documentation/console/).

Console Drivers
==========

O kernel do linux tem 2 tipos gerais de drivers de console.  O
primeiro tipo é atribuído pelo kernel a todos os consoles virtuais
durante o processo de inicialização.   Esse tipo será chamado 'driver
de sistema', e é permitido existir apenas um driver de sistema.  O
driver de sistema é do tipo persistente e nunca pode ser descarregado,
apesar de eventualmente poder se tornar inativo.

O segundo tipo deve ser explicitamente carregado e descarregado.  Esse
será chamado de 'driver modular' por este documento.  Múltiplos drivers
modulares podem coexistir a qualquer tempo, cada qual compartilhando o
console com outros drivers, incluindo o driver de sistema.  Entretanto,
drivers modulares não podem apossar-se de console que esteja atualmente
ocupado por algum outro driver modular.  (Exceção: Drivers que chamarem
do_take_over_console() terão sucesso no apossamento independentemente do tipo do driver ocupando os consoles).  Eles apenas podem apossar-se de
console que esteja ocupado por driver de sistema.   Dentro do mesmo
símbolo, se o driver modular estiver liberado pelo console, o driver de
sistema se apossará.

Drivers modulares, do ponto de vista do desenvolvedor, tem de chamar:

     do_take_over_console() - carrega e vincula o driver à camada de console
   
     give_up_console() - descarrega driver, funcionará apenas se o
     driver for desvinculado completamente

Em kernels mais novos, as seguintes também estão disponíveis:

     do_register_con_driver()
     do_unregister_con_driver()

Se sysfs estiver habilitado, o conteúdo de /sys/class/vtconsole pode ser
examinado.   Isso mostra as infra-estruturas do console atualmente registrado pelo sistema, os quais são chamados vtcon<n>, onde <n> é um número inteiro de 0 até 15.   Assim:

       ls /sys/class/vtconsole
       .  ..  vtcon0  vtcon1

Cada diretório em /sys/class/vtconsole tem 3 arquivos:

     ls /sys/class/vtconsole/vtcon0
     .  ..  bind  name  uevent

O que esses arquivos significam?

     1. bind - este é um arquivo leitura/escrita. Ele mostra o estado
     do driver se leitura, ou atua para vincular ou desvincular o
     driver aos consoles virtuais quando escritos. Os valores
     possíveis são:

    0 - significa que o driver não está vinculado e se echo'ed,
    ordena a desvinculação do driver

        1 - significa que o driver está vinculado e se echo'ed, ordena a
        vinculação do driver

     2. name - arquivo somente-leitura.  Mostra o nome do driver neste
     formato:

    cat /sys/class/vtconsole/vtcon0/name
    (S) VGA+

        '(S)' significa driver de (S)istema, isto é, não pode ser
        diretamente comandado para vincular ou desvincular

        'VGA+' é o nome do driver

    cat /sys/class/vtconsole/vtcon1/name
    (M) frame buffer device

        Nesse caso, '(M)' significa um driver (M)odular, um que pode
        ser diretamente comandado para vincular ou desvincular.

     3. uevent - ignore este arquivo

Quando do desvinculamento, o driver modular primeiro é isolado, e então
o driver de sistema se apossa do console vago pelo driver. 
Vinculamento, por outro lado, vinculará o driver aos consoles que estão
atualmente ocupados por um driver de sistema.

NOTA1: Vinculamento e desvinculamento devem ser selecionados em Kconfig.  Isso é feito sob:

Device Drivers -> Character devices -> Support for binding and unbinding
console drivers

NOTA2: Se quaisquer dos consoles virtuais estiverem no modo KD_GRAPHICS, então o vinculamento e desvinculamento não ocorrerá.  Um exemplo de uma aplicação que configura o console para KD_GRAPHICS é o servidor X.

O quão útil é esta característica?  Isto é bastante útil para
desenvolvedores de drivers de console.  Desvinculando o driver da camada
de console, uma pessoa pode descarregar o driver, produzir mudanças,
recompilar, recarregar e revincular o driver sem qualquer necessidade de
reinicializar o kernel.   Para usuários comuns que desejarem alternar do
console framebuffer para o console VGA e vice versa, esta característica
também torna isso possível. (NOTA NOTA NOTA: Por favor, leia fbcon.txt
sob Documentation/fb para mais detalhes).

Notas para desenvolvedores:
==========================

do_take_over_console() está atualmente quebrado em:

     do_register_con_driver()
     do_bind_con_driver() - função privada

give_up_console() é uma embalagem para do_unregister_con_driver(), e um
driver deve ser completamente desvinculado para essa chamada ter
sucesso.  con_is_bound() verificará se o driver está vinculado ou
não.

Orientações para escritores de drivers de console:
=================================================

Para que o vinculamento e desvinculamento de um console funcione
adequadamente, drivers de console devem seguir estas orientações:

1. Todos os drivers, exceto drivers de sistema, devem chamar ou
do_register_con_driver() ou do_take_over_console().  
do_register_con_driver() apenas adicionará o driver à lista interna do
console.   Ela não se apossa do console.   do_take_over_console(), como
o nome implica, apenas se apossará (ou vínculo a) do console.

2. Todos os recursos alocados durante con->con_init() devem ser
liberados em con->con_deinit().

3. Todos os recursos alocados em con->con_startup() devem ser liberados
quando o driver, que foi previamente vinculado, se tornar desvinculado. 
A camada de console não tem uma chamada complementar a con->con_startup(), de forma que compete completamente ao driver verificar quando for lícito liberar tais recursos.   A chamada con_is_bound() em con->con_deinit() ajudará.   Se a chamada retornou false(), então é seguro liberar os recursos.   Tal balanço tem de ser feito pois con->con_startup() pode ser chamado novamente quando uma requisição para revincular o driver ao console chegar.

4. Quando da saída do driver, assegure-se de que o driver esteja
totalmente desvinculado.   Se a condição estiver satisfeita, então o
driver deve chamar do_unregister_con_driver() ou give_up_console().

5. do_unregister_con_driver() também pode ser chamado em condições que
tornem impossível para o driver atender a requisições do console.  Isso
pode acontecer com o console framebuffer que repentinamente perca todos
os seus drivers.

A safra atual de drivers de console ainda deveria funcionar corretamente,
porém o vinculamento e desvinculamento deles podem causar problemas. 
Com ajustes mínimos, esses drivers podem funcionar corretamente.

==========================
Antonino Daplas <adaplas@pol.net>