[PATCH 3/3] docs: translations: pt_BR: fix missing text and formatting in process docs

[Daniel Pereira <danielmaraboo@gmail.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 18037 bytes --]

Add a missing paragraph about code review in 6.Followthrough.rst and
fix a grammatical error. Fix formatting and translate an English snippet
in 8.Conclusion.rst. Fix several instances of omitted 'xyzzy'
placeholders in code examples, restore truncated sentences, and fix
missing links in adding-syscalls.rst. Fix typos in applying-patches.rst.
Fix a typo and fix a broken markdown link to reStructuredText format
in backporting.rst.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
 .../pt_BR/process/6.Followthrough.rst         | 14 ++++-
 .../pt_BR/process/8.Conclusion.rst            |  3 +-
 .../pt_BR/process/adding-syscalls.rst         | 54 ++++++++++---------
 .../pt_BR/process/applying-patches.rst        |  4 +-
 .../pt_BR/process/backporting.rst             |  4 +-
 5 files changed, 47 insertions(+), 32 deletions(-)

diff --git a/Documentation/translations/pt_BR/process/6.Followthrough.rst b/Documentation/translations/pt_BR/process/6.Followthrough.rst
index d6bdaa2cb..dbdf479bb 100644
--- a/Documentation/translations/pt_BR/process/6.Followthrough.rst
+++ b/Documentation/translations/pt_BR/process/6.Followthrough.rst
@@ -58,7 +58,17 @@ fácil se você mantiver algumas coisas em mente:
   de codificação e pedidos para refatorar parte do seu código em seções
   compartilhadas do kernel. Uma das funções dos mantenedores é manter as coisas
   com a mesma aparência. Às vezes, isso significa que aquele truque inteligente
-  (*clever hack*) em seu driver para contornar um problema
+  (*clever hack*) em seu driver para contornar um problema na verdade precisa
+  se tornar um recurso generalizado do kernel, pronto para a próxima vez.
+
+O que tudo isso significa é que, quando os revisores lhe enviam comentários,
+você precisa prestar atenção às observações técnicas que eles estão fazendo.
+Não deixe que a forma como eles se expressam, ou o seu próprio orgulho, impeçam
+que isso aconteça. Quando você receber comentários de revisão em um patch,
+reserve um tempo para entender o que o revisor está tentando dizer. Se
+possível, corrija as coisas que o revisor está pedindo para você corrigir. E
+responda ao revisor: agradeça-o e descreva como você responderá às suas
+perguntas.
 
 Note que você não precisa concordar com todas as mudanças sugeridas pelos
 revisores. Se você acredita que o revisor entendeu mal o seu código, explique
@@ -67,7 +77,7 @@ sugerida, descreva-a e justifique a sua solução para o problema. Se as suas
 explicações fizerem sentido, o revisor as aceitará. Contudo, caso a sua
 explicação não seja persuasiva — especialmente se outros começarem a concordar
 com o revisor —, reserve um tempo para repensar as coisas. Pode ser fácil ficar
-ceguificado por sua própria solução para um problema, a ponto de não perceber
+cego por sua própria solução para um problema, a ponto de não perceber
 que algo está fundamentalmente errado ou que, talvez, você não esteja sequer
 resolvendo o problema certo.
 
diff --git a/Documentation/translations/pt_BR/process/8.Conclusion.rst b/Documentation/translations/pt_BR/process/8.Conclusion.rst
index d5af31e7c..2696ea167 100644
--- a/Documentation/translations/pt_BR/process/8.Conclusion.rst
+++ b/Documentation/translations/pt_BR/process/8.Conclusion.rst
@@ -21,6 +21,7 @@ encontradas através do índice do kernel do LWN em:
 	https://lwn.net/Kernel/Index/
 
 Além disso, um recurso valioso para os desenvolvedores do kernel é:
+
 	https://kernelnewbies.org/
 
 E, claro, não se deve esquecer o https://kernel.org/, o local definitivo
@@ -29,7 +30,7 @@ para informações sobre os lançamentos do kernel.
 Há uma série de livros sobre o desenvolvimento do kernel:
 
 	Linux Device Drivers, 3rd Edition (Jonathan Corbet, Alessandro
-	Rubini, and Greg Kroah-Hartman).  Online at
+	Rubini, e Greg Kroah-Hartman). Disponível online em
 	https://lwn.net/Kernel/LDD3/.
 
 	Linux Kernel Development (Robert Love).
diff --git a/Documentation/translations/pt_BR/process/adding-syscalls.rst b/Documentation/translations/pt_BR/process/adding-syscalls.rst
index cdf8b5033..37b0dd0e2 100644
--- a/Documentation/translations/pt_BR/process/adding-syscalls.rst
+++ b/Documentation/translations/pt_BR/process/adding-syscalls.rst
@@ -122,10 +122,10 @@ como o handle (identificador) para esse objeto -- não invente um novo tipo de
 handle de objeto para o espaço do usuário quando o kernel já possui mecanismos
 e semânticas bem definidas para o uso de descritores de arquivo.
 
-Se a sua nova chamada de sistema (2) de fato retornar un novo descritor de
+Se a sua nova chamada de sistema xyzzy(2) de fato retornar um novo descritor de
 arquivo, então o argumento de flags deve incluir um valor que seja equivalente
 a definir ``O_CLOEXEC`` no novo FD. Isso torna possível para o espaço do usuário
-fechar a janela de tempo entre a chamada ``()`` e a execução de
+fechar a janela de tempo entre a chamada ``xyzzy()`` e a execução de
 ``fcntl(fd, F_SETFD, FD_CLOEXEC)``, onde um ``fork()`` e ``execve()`` inesperados
 em outra thread poderiam vazar um descritor para o programa executado. (Contudo,
 resista à tentação de reutilizar o valor real da constante ``O_CLOEXEC``, pois
@@ -138,7 +138,7 @@ deve considerar o que significa usar a família de chamadas de sistema
 pronto para leitura ou escrita é a maneira normal de o kernel indicar ao espaço
 do usuário que um evento ocorreu no objeto correspondente do kernel.
 
-Se a sua nova chamada de sistema (2) envolver um argumento de nome de arquivo
+Se a sua nova chamada de sistema xyzzy(2) envolver um argumento de nome de arquivo
 (filename)::
 
     int sys_xyzzy(const char __user *path, ..., unsigned int flags);
@@ -152,18 +152,18 @@ o arquivo em questão; em particular, permite que o espaço do usuário solicite
 funcionalidade para um descritor de arquivo já aberto usando a flag
 ``AT_EMPTY_PATH``, fornecendo efetivamente uma operação fxyzzy(3) de graça::
 
- - xyzzyat(AT_FDCWD, path, ..., 0) é equivalente a (path,...)
+ - xyzzyat(AT_FDCWD, path, ..., 0) é equivalente a xyzzy(path,...)
  - xyzzyat(fd, "", ..., AT_EMPTY_PATH) é equivalente a fxyzzy(fd, ...)
 
 (Para mais detalhes sobre a justificativa das chamadas \*at(), veja a página de
 manual :manpage:`openat(2)`; para um exemplo de AT_EMPTY_PATH, veja a página de
 manual :manpage:`fstatat(2)`.)
 
-Se a sua nova chamada de sistema (2) envolver um parâmetro que descreve um
+Se a sua nova chamada de sistema xyzzy(2) envolver um parâmetro que descreve um
 deslocamento (offset) dentro de um arquivo, mude o seu tipo para ``loff_t`` para
 que offsets de 64 bits possam ser suportados mesmo em arquiteturas de 32 bits.
 
-Se a sua nova chamada de sistema (2) envolver funcionalidades privilegiadas,
+Se a sua nova chamada de sistema xyzzy(2) envolver funcionalidades privilegiadas,
 ela precisa ser governada pelo bit de capacidade (capability) do Linux apropriado
 (verificado com uma chamada a ``capable()``), conforme descrito na página de
 manual :manpage:`capabilities(7)`. Escolha um bit de capacidade existente que governe
@@ -172,7 +172,7 @@ apenas uma vaga relação sob o mesmo bit, pois isso vai contra o propósito das
 capabilities de dividir o poder do root. Em particular, evite adicionar novos
 usos para a capacidade ``CAP_SYS_ADMIN``, que já é excessivamente generalista.
 
-Se a sua nova chamada de sistema (2) manipular um processo diferente do
+Se a sua nova chamada de sistema xyzzy(2) manipular um processo diferente do
 processo que a chamou, ela deve ser restrita (usando uma chamada a
 ``ptrace_may_access()``) para que apenas um processo chamador com as mesmas
 permissões do processo alvo, ou com as capacidades necessárias, possa manipular
@@ -211,7 +211,7 @@ kernel, devem sempre ser enviadas com cópia (cc'ed) para linux-api@vger.kernel.
 Implementação Genérica de Chamadas de Sistema
 ---------------------------------------------
 
-O ponto de entrada principal para a sua nova chamada de sistema (2) será chamado
+O ponto de entrada principal para a sua nova chamada de sistema xyzzy(2) será chamado
 de ``sys_xyzzy()``, mas você deve adicionar esse ponto de entrada com a macro
 ``SYSCALL_DEFINEn()`` apropriada, em vez de fazer isso explicitamente. O 'n'
 indica o número de argumentos da chamada de sistema, e a macro recebe o nome da
@@ -242,7 +242,7 @@ O arquivo ``kernel/sys_ni.c`` fornece uma implementação de stub de fallback pa
 cada chamada de sistema, retornando ``-ENOSYS``. Adicione a sua nova chamada de
 sistema aqui também::
 
-    COND_SYSCALL(sys_xyzzy);
+    COND_SYSCALL(xyzzy);
 
 A sua nova funcionalidade de kernel, e a chamada de sistema que a controla, deve
 normalmente ser opcional, portanto adicione uma opção ``CONFIG`` (tipicamente em
@@ -259,7 +259,7 @@ normalmente ser opcional, portanto adicione uma opção ``CONFIG`` (tipicamente
 Para resumir, você precisa de um commit que inclua:
 
  - Opção ``CONFIG`` para a nova função, normalmente em ``init/Kconfig``
- - ``SYSCALL_DEFINEn(, ...)`` para o ponto de entrada
+ - ``SYSCALL_DEFINEn(xyzzy, ...)`` para o ponto de entrada
  - Protótipo correspondente em ``include/linux/syscalls.h``
  - Entrada na tabela genérica em ``include/uapi/asm-generic/unistd.h``
  - Stub de fallback em ``kernel/sys_ni.c``
@@ -289,7 +289,7 @@ ajustar ``arch/*/kernel/Makefile.syscalls``.
 Como o ``scripts/syscall.tbl`` serve como uma tabela de syscall comum para
 múltiplas arquiteturas, uma nova entrada é necessária nesta tabela::
 
-    468   common        sys_xyzzy
+    468   common   xyzzy     sys_xyzzy
 
 Note que adicionar uma entrada ao ``scripts/syscall.tbl`` com a ABI "common"
 também afeta todas as arquiteturas que compartilham essa tabela. Para alterações
@@ -304,7 +304,7 @@ correspondentes também devem ser feitas em ``arch/*/kernel/Makefile.syscalls``:
 Para resumir, você precisa de um commit que inclua:
 
  - Opção ``CONFIG`` para a nova função, normalmente em ``init/Kconfig``
- - ``SYSCALL_DEFINEn(, ...)`` para o ponto de entrada
+ - ``SYSCALL_DEFINEn(xyzzy, ...)`` para o ponto de entrada
  - Protótipo correspondente em ``include/linux/syscalls.h``
  - Nova entrada em ``scripts/syscall.tbl``
  - (Se necessário) Atualizações de Makefile em ``arch/*/kernel/Makefile.syscalls``
@@ -320,11 +320,11 @@ de sistema não seja especial de alguma forma (veja abaixo), isso envolve uma
 entrada "common" (para x86_64 e x32) em
 ``arch/x86/entry/syscalls/syscall_64.tbl``::
 
-    333   common        sys_xyzzy
+    333   common   xyzzy     sys_xyzzy
 
 e uma entrada "i386" em ``arch/x86/entry/syscalls/syscall_32.tbl``::
 
-    380   i386          sys_xyzzy
+    380   i386     xyzzy     sys_xyzzy
 
 Novamente, esses números estão sujeitos a alterações caso ocorram conflitos na
 janela de mesclagem (merge window) relevante.
@@ -414,7 +414,7 @@ a versão compat; a entrada em ``include/uapi/asm-generic/unistd.h`` deve usar
 
 Para resumir, você precisa de:
 
- - uma macro ``COMPAT_SYSCALL_DEFINEn(, ...)`` para o ponto de entrada compat
+ - uma macro ``COMPAT_SYSCALL_DEFINEn(xyzzy, ...)`` para o ponto de entrada compat
  - protótipo correspondente em ``include/linux/compat.h``
  - (se necessário) struct de mapeamento de 32 bits em ``include/linux/compat.h``
  - instância de ``__SC_COMP``, e não de ``__SYSCALL``, em
@@ -433,11 +433,11 @@ Você precisa estender a entrada em ``scripts/syscall.tbl`` com uma coluna extra
 para indicar que um programa de espaço do usuário de 32 bits rodando em um
 kernel de 64 bits deve atingir o ponto de entrada compat::
 
-    468   common          sys_xyzzy    compat_sys_xyzzy
+    468   common     xyzzy     sys_xyzzy    compat_sys_xyzzy
 
 Para resumir, você precisa de:
 
- - ``COMPAT_SYSCALL_DEFINEn(, ...)`` para o ponto de entrada compat
+ - ``COMPAT_SYSCALL_DEFINEn(xyzzy, ...)`` para o ponto de entrada compat
  - Protótipo correspondente em ``include/linux/compat.h``
  - Modificação da entrada em ``scripts/syscall.tbl`` para incluir uma coluna
    "compat" extra
@@ -454,7 +454,7 @@ compatibilidade voltadas para o espaço do usuário de 32 bits (AArch32):
 ``arch/arm64/tools/syscall_32.tbl``. Você precisa adicionar uma linha adicional
 a esta tabela especificando o ponto de entrada compat::
 
-    468   common          sys_xyzzy    compat_sys_xyzzy
+    468   common     xyzzy     sys_xyzzy    compat_sys_xyzzy
 
 
 Chamadas de Sistema de Compatibilidade (x86)
@@ -467,7 +467,7 @@ Primeiro, a entrada em ``arch/x86/entry/syscalls/syscall_32.tbl`` ganha uma
 coluna extra para indicar que um programa de espaço do usuário de 32 bits rodando
 em um kernel de 64 bits deve atingir o ponto de entrada compat::
 
-    380   i386          sys_xyzzy    __ia32_compat_sys_xyzzy
+    380   i386     xyzzy     sys_xyzzy    __ia32_compat_sys_xyzzy
 
 Segundo, você precisa definir o que deve acontecer para a versão da ABI x32 da
 nova chamada de sistema. Há uma escolha aqui: o layout dos argumentos deve
@@ -479,9 +479,9 @@ corresponder à versão de 32 bits, e a entrada em
 ``arch/x86/entry/syscalls/syscall_64.tbl`` é dividida para que os programas x32
 atinjam o wrapper de compatibilidade::
 
-    333   64            sys_xyzzy
+    333   64       xyzzy     sys_xyzzy
     ...
-    555   x32           __x32_compat_sys_xyzzy
+    555   x32      xyzzy     __x32_compat_sys_xyzzy
 
 Se não houver ponteiros envolvidos, então é preferível reutilizar a chamada de
 sistema de 64 bits para a ABI x32 (e, consequentemente, a entrada em
@@ -518,14 +518,14 @@ Para x86_64, isso é implementado como um ponto de entrada ``stub_xyzzy`` em
 ``arch/x86/entry/entry_64.S``, e a entrada correspondente na tabela de syscalls
 (``arch/x86/entry/syscalls/syscall_64.tbl``) é ajustada para refletir::
 
-    333   common        stub_xyzzy
+    333   common   xyzzy     stub_xyzzy
 
 O equivalente para programas de 32 bits executados em um kernel de 64 bits é
 normalmente chamado de ``stub32_xyzzy`` e implementado em
 ``arch/x86/entry/entry_64_compat.S``, com o respectivo ajuste na tabela de
 syscalls em ``arch/x86/entry/syscalls/syscall_32.tbl``::
 
-    380   i386          sys_xyzzy    stub32_xyzzy
+    380   i386     xyzzy     sys_xyzzy    stub32_xyzzy
 
 Se a chamada de sistema precisar de uma camada de compatibilidade (como na
 seção anterior), a versão ``stub32_`` precisará chamar a versão
@@ -579,12 +579,16 @@ espaço do usuário, o cabeçalho correspondente precisará ser instalado para
 compilar o teste.
 
 Certifique-se de que o autoteste seja executado com sucesso em todas as
-arquiteturas suportadas. Por exemplo, verifique se ele funciona quando compitado
+arquiteturas suportadas. Por exemplo, verifique se ele funciona quando compilado
 como um programa ABI x86_64 (-m64), x86_32 (-m32) e x32 (-mx32).
 
 Para testes mais extensos e minuciosos de novas funcionalidades, você também
 deve considerar a adição de testes ao Linux Test Project ou ao projeto
-xfstests para alterações relacionadas
+xfstests para alterações relacionadas a sistemas de arquivos.
+
+ - https://linux-test-project.github.io/
+ - git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
+
 
 Página de Manual (Man Page)
 ---------------------------
diff --git a/Documentation/translations/pt_BR/process/applying-patches.rst b/Documentation/translations/pt_BR/process/applying-patches.rst
index 313401bc2..37a8d804d 100644
--- a/Documentation/translations/pt_BR/process/applying-patches.rst
+++ b/Documentation/translations/pt_BR/process/applying-patches.rst
@@ -12,7 +12,7 @@ Autor Original:
    manualmente, você quase certamente desejará considerar o uso do Git.
 
 Uma pergunta feita com frequência na Linux Kernel Mailing List é como aplicar
-an patch ao kernel ou, mais especificamente, a qual kernel base um patch para
+um patch ao kernel ou, mais especificamente, a qual kernel base um patch para
 uma das muitas árvores/branches deve ser aplicado. Esperamos que este documento
 explique isso a você.
 
@@ -171,7 +171,7 @@ fazer a alteração para fazê-la caber).
 O arquivo resultante pode ou não estar correto, dependendo do motivo pelo qual o
 arquivo estava diferente do esperado.
 
-Isso geralmente acontece se você tentar aplicar un patch que foi gerado contra uma
+Isso geralmente acontece se você tentar aplicar um patch que foi gerado contra uma
 versão de kernel diferente daquela que você está tentando modificar.
 
 Se você receber uma mensagem como ``Hunk #3 FAILED at 2387.``, significa que o
diff --git a/Documentation/translations/pt_BR/process/backporting.rst b/Documentation/translations/pt_BR/process/backporting.rst
index ce3f9fb4f..afcff7085 100644
--- a/Documentation/translations/pt_BR/process/backporting.rst
+++ b/Documentation/translations/pt_BR/process/backporting.rst
@@ -357,7 +357,7 @@ Processo de resolução
 ~~~~~~~~~~~~~~~~~~~~~
 
 Às vezes, a coisa mais fácil a fazer é apenas remover tudo, exceto a primeira
-parteda do conflito, deixando o arquivo essencialmente inalterado, e aplicar
+parte do conflito, deixando o arquivo essencialmente inalterado, e aplicar
 as alterações manualmente. Talvez o patch esteja alterando um argumento de
 chamada de função de ``0`` para ``1``, enquanto uma alteração conflitante
 adicionou um parâmetro totalmente novo (e insignificante) ao final da lista de
@@ -403,7 +403,7 @@ de volta (``git mv`` e commitando novamente) e, finalmente, esmagar (squash) o
 resultado usando ``git rebase -i`` (veja o `tutorial de rebase`_) para que ele
 apareça como um único commit quando você terminar.
 
-.. _tutorial de rebase: [https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec](https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec)
+.. _tutorial de rebase: https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-with-git-rebase-8185cf6e62ec
 
 Pegadinhas
 ----------
-- 
2.47.3