From nobody Mon May 15 19:41:51 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QKqWM5XqJz4B1f7 for ; Mon, 15 May 2023 19:41:51 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QKqWM31nFz49wX; Mon, 15 May 2023 19:41:51 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684179711; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=4BbqVe0CBdVrWNGV1QZfG3IhpDyZOVKB4LVuP4u7c0A=; b=FQsOzi/x6jjQpflesuQFmHozYPOeNWk4loT+XUwxrFc18Xb5f2aokgya6f8s7yFhh5G7gu FcL7LE2J+RbkUlLLqRK7CdPKG789BOBlhpCoMyJKbDLh0c3B/dpA2Nf1+5A6uFwA5FF+jl l4BNYcUGJOH/6Yha1K3UDDYxI2BGkry3J5dvkuSg2MrrzE/e4GJFHKmBmIfZAPKAJePR0K aGOeStt6eh7fCQbqg53xfDnFDD8QURgvVHVmHjPt73ITUqz9cAz6Asv7qZ1N8W3LHDHEZR DLKCdO9XCQD7rE1th33wAywap7Tjl/MWE3qSkp4Ny+9Ndf59G2DBF+4tfff56Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684179711; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=4BbqVe0CBdVrWNGV1QZfG3IhpDyZOVKB4LVuP4u7c0A=; b=caDLzh3o438dFZp+zTGZkx3YIVAnN7G9i20Vypf2lN2xKUwbgeDFRUWgPjvDVNZGp67xXS 30ozKW/jE4WFQHcA0pCKQJ+duqxZP2RUi7iDmvUjVP1+fP6fXcrUe96RDSfcTvaPQXzA5V DYWjENpgXAigNT9IHTE1v/SK0hvn2ojijT18Oev0bRG90cX4uqWqG2pDeAyh98rd54RSXG +Ro/0M/NgDPVR1Lp+V/hei6t2YKGoohducCVe/IqLoYHSFaPYACDwXr2YZz+EkEG67Z6g6 ZZ6Q7ap0S94dm28gJqTGNqVCrdy7jfp2S8q3Dwav1Vvt4X3shT3iWcWup5Apxw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684179711; a=rsa-sha256; cv=none; b=mzFl8UNbjaQcOgJcumZ0FVzAlMonUieaqBOsbzA31TdZWVjFerruwZiYDE+qqFFEtkTFxX i2yQZObZNKCgPE7dEKofG0ZVoPTXmAj+A/xsUaJ3WSF7i1+bgZ1FCYQk8pGpdEWoSlB696 VK1dNI9XqmecO8+laVXHbe1DxRcgNVv1k2AzpA2+9g230vEY3SbE4lMPyDCGAh2Z8agdyd ZL/pUonk28FTS1+HKEm+C/Pn1W+YfpYbdjY32HV+peiyhKY9sCE9ryZCx/1+gc1EKZ1eL6 U3XjPAeTD1tb9cXx8JZgaKFLBOOI5jFDUqeF5I0WCEl50Gqpi5Vo40Cv9mlpvg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QKqWM25gyzsgv; Mon, 15 May 2023 19:41:51 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 34FJfptD063079; Mon, 15 May 2023 19:41:51 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 34FJfpgx063078; Mon, 15 May 2023 19:41:51 GMT (envelope-from git) Date: Mon, 15 May 2023 19:41:51 GMT Message-Id: <202305151941.34FJfpgx063078@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Edson Brandi Subject: git: 655cf298ff - main - Article gjournal-desktop translated to pt_BR and synced with doc tree version 98c736dd127a2096dc08252d1082300f2ec28ab5 List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: ebrandi X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 655cf298ff801bc3fd1a6db3fb6ccc2275369c72 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by ebrandi: URL: https://cgit.FreeBSD.org/doc/commit/?id=655cf298ff801bc3fd1a6db3fb6ccc2275369c72 commit 655cf298ff801bc3fd1a6db3fb6ccc2275369c72 Author: Edson Brandi AuthorDate: 2023-05-15 19:41:13 +0000 Commit: Edson Brandi CommitDate: 2023-05-15 19:41:13 +0000 Article gjournal-desktop translated to pt_BR and synced with doc tree version 98c736dd127a2096dc08252d1082300f2ec28ab5 --- .../pt-br/articles/gjournal-desktop/_index.adoc | 173 +-- .../pt-br/articles/gjournal-desktop/_index.po | 1348 ++++++++++++++++++++ 2 files changed, 1437 insertions(+), 84 deletions(-) diff --git a/documentation/content/pt-br/articles/gjournal-desktop/_index.adoc b/documentation/content/pt-br/articles/gjournal-desktop/_index.adoc index d25822402a..0b1b33e660 100644 --- a/documentation/content/pt-br/articles/gjournal-desktop/_index.adoc +++ b/documentation/content/pt-br/articles/gjournal-desktop/_index.adoc @@ -1,8 +1,11 @@ --- -title: Implementando o UFS Journaling em um Desktop PC authors: - - author: Manolis Kiagias + - + author: 'Manolis Kiagias' email: manolis@FreeBSD.org +description: 'Implementando o UFS Journaling em um Desktop PC' +tags: ["UFS", "Journaling" , "Desktop", "FreeBSD"] +title: 'Implementando o UFS Journaling em um Desktop PC' trademarks: ["freebsd", "general"] --- @@ -40,7 +43,7 @@ endif::[] [.abstract-title] Resumo -Um sistema de arquivos com journaling usa um log para registrar todas as transações que ocorrem no sistema de arquivos e preserva sua integridade em caso de falha do sistema ou falta de energia. Embora ainda seja possível perder as alterações não salvas nos arquivos, o journaling elimina quase completamente a possibilidade de corrupção do sistema de arquivos causada por um desligamento abrupto. Ele também reduz ao mínimo o tempo necessário para a verificação do sistema de arquivos após a falha. Embora o sistema de arquivos UFS empregado pelo FreeBSD não implemente o journaling em si, a nova classe de journal do framework GEOM no FreeBSD 7._X_ pode ser usada para fornecer journaling independente do sistema de arquivos. Este artigo explica como implementar o UFS journaling em um cenário típico de PC de mesa. +Um sistema de arquivos com journaling utiliza um log para registrar todas as transações que ocorrem no sistema de arquivos e preserva sua integridade em caso de falha do sistema ou queda de energia. Embora ainda seja possível perder alterações não salvas em arquivos, o journaling quase elimina completamente a possibilidade de corrupção do sistema de arquivos causada por uma desligamento incorreto. Ele também reduz ao mínimo o tempo necessário para a verificação do sistema de arquivos após uma falha. Embora o sistema de arquivos UFS utilizado pelo FreeBSD não implemente o journaling por si só, a nova classe de journaling do framework GEOM no FreeBSD 7._X_ pode ser usada para fornecer o journaling independente do sistema de arquivos. Este artigo explica como implementar o journaling do UFS em um cenário típico de um PC desktop. ''' @@ -49,91 +52,91 @@ toc::[] [[introduction]] == Introdução -Embora os servidores profissionais estejam geralmente bem protegidos contra desligamentos imprevistos, um desktop típico fica à mercê de falhas de energia, reinicializações acidentais e outros incidentes relacionados ao usuário que podem levar a paradas abruptas. Os soft updates costumam proteger o sistema de arquivos de maneira eficiente nestes casos, embora na maioria das vezes seja necessária uma longa verificação em background. Em raras ocasiões, a corrupção do sistema de arquivos atinge um ponto em que a intervenção do usuário é necessária e os dados podem ser perdidos. +Enquanto servidores profissionais geralmente estão bem protegidos contra desligamentos imprevistos, os desktops típicos estão sujeitos a quedas de energia, reinicializações acidentais e outros incidentes relacionados ao usuário que podem levar a desligamentos incorretos. As Soft Updates geralmente protegem o sistema de arquivos de forma eficiente nesses casos, embora na maioria das vezes seja necessária uma verificação em segundo plano demorada. Em raras ocasiões, a corrupção do sistema de arquivos atinge um ponto em que é necessária a intervenção do usuário e dados podem ser perdidos. O novo recurso de journaling fornecido pela GEOM pode ajudar bastante nesses cenários, praticamente eliminando o tempo necessário para a verificação do sistema de arquivos e garantindo que o sistema de arquivos seja rapidamente restaurado para um estado consistente. -Este artigo descreve um procedimento para implementar o journaling do UFS em um cenário típico de PC de mesa (um único disco rígido usado para o sistema operacional e para os dados). Deve ser seguido durante uma nova instalação do FreeBSD. As etapas são simples o suficiente e não requerem interação excessivamente complexa com a linha de comando. +Este artigo descreve um procedimento para implementar o journaling do UFS em um cenário típico de um PC desktop (um disco rígido usado tanto para o sistema operacional quanto para os dados). Ele deve ser seguido durante uma nova instalação do FreeBSD. Os passos são simples o suficiente e não exigem interações excessivamente complexas com a linha de comando. Depois de ler este artigo, você saberá: * Como reservar espaço para o journaling durante uma nova instalação do FreeBSD. -* Como carregar e ativar o módulo `geom_journal` (ou como compilar o suporte para ele em seu kernel customizado). -* Como converter seus sistemas de arquivos existentes para utilizar o journaling e quais opções usar em [.filename]#/etc/fstab# para montá-los. +* Como carregar e ativar o módulo `geom_journal` (ou compilar o suporte para ele em seu kernel personalizado). +* Como converter seus sistemas de arquivos existentes para utilizar journaling e quais opções usar no arquivo [.filename]#/etc/fstab# para montá-los. * Como implementar o journaling em novas partições (vazias). * Como solucionar problemas comuns associados ao journaling. Antes de ler este artigo, você deve ser capaz de: * Entender os conceitos básicos do UNIX(R) e do FreeBSD. -* Estar familiarizado com o procedimento de instalação do FreeBSD e com o utilitário sysinstall. +* Estar familiarizado com o procedimento de instalação do FreeBSD e com a ferramenta sysinstall. [WARNING] ==== -O procedimento descrito aqui é destinado a preparar uma nova instalação na qual ainda não temos nenhum dado real do usuário é armazenado no disco. Embora seja possível modificar e estender este procedimento para sistemas já em produção, você deve efetuar o _backup_ de todos os dados importantes antes de fazer isso. Mexer com discos e partições em um baixo nível pode levar a erros fatais e a perda de dados. +A procedimento descrito aqui destina-se a preparar uma nova instalação na qual ainda não existe nenhum dado do usuário armazenado no disco. Embora seja possível modificar e estender este procedimento para sistemas já em produção, você deve fazer um _backup_ de todos os dados importantes antes de fazê-lo. Mexer com discos e partições em um nível baixo pode levar a erros fatais e a perda de dados. ==== [[understanding-journaling]] == Compreendendo o journaling no FreeBSD -O journaling fornecido pelo GEOM no FreeBSD 7._X_ não é específico do sistema de arquivos (diferentemente do sistema de arquivos ext3 no Linux(R)), funcionando a nível de bloco. Embora isso signifique que ele possa ser aplicado a sistemas de arquivos diferentes, no FreeBSD 7.0-RELEASE, ele só pode ser usado com o UFS2. +O journaling fornecido pelo GEOM no FreeBSD 7._X_ não é específico do sistema de arquivos (ao contrário do sistema de arquivos ext3 no Linux(R)), mas funciona no nível de bloco. Embora isso signifique que ele possa ser aplicado a diferentes sistemas de arquivos, no FreeBSD 7.0-RELEASE, ele só pode ser usado no UFS2. -Esta funcionalidade é fornecida pelo carregamento do módulo [.filename]#geom_journal.ko# no kernel (ou através da compilação de um kernel personalizado) e pelo uso do comando `gjournal` para configurar os sistemas de arquivos. Em geral, você gostaria de utilizar o journal em grandes sistemas de arquivos, como o [.filename]#/usr#. Você precisará no entanto (veja a seção seguinte) reservar algum espaço livre em disco para isso. +Essa funcionalidade é fornecida carregando o módulo [.filename]#geom_journal.ko# no kernel (ou compilando-o em um kernel personalizado) e usando o comando `gjournal` para configurar os sistemas de arquivos. Em geral, você gostaria de registrar grandes sistemas de arquivos, como o [.filename]#/usr#. No entanto, você precisará reservar algum espaço livre em disco (consulte a próxima seção). -Quando um sistema de arquivos é "journaled", é necessário algum espaço em disco para manter o próprio journal. O espaço em disco que contém os dados reais é chamado de __data provider__, enquanto o que contém o journal é chamado de __journal provider__. Os provedores de dados e de journal precisam estar em partições diferentes ao fazer o journaling de uma partição existente (não vazia). Ao fazer o journaling de uma nova partição, você tem a opção de usar um único provedor para os dados e o journal. Em todo caso, o comando `gjournal` combina os dois provedores para criar o sistema de arquivos journaled final. Por exemplo: +Quando um sistema de arquivos é jornalizado, é necessário um espaço em disco para armazenar o próprio journal. O espaço em disco que contém os dados reais é chamado de __provedor de dados__ (data provider), enquanto o que contém o journal é chamado de __provedor de journal__ (journal provider). Os provedores de dados e de journal precisam estar em partições diferentes ao jornalizar uma partição existente (não vazia). Ao jornalizar uma nova partição, você tem a opção de usar um único provedor para ambos os dados e o journal. Em qualquer caso, o comando `gjournal` combina ambos os provedores para criar o sistema de arquivos final com journaling. Por exemplo: -* Você deseja fazer o journaling do seu sistema de arquivos [.filename]#/usr#, armazenado em [.filename]#/dev/ad0s1f# (que já contém dados). -* Você reservou algum espaço livre no disco, na partição [.filename]#/dev/ad0s1g#. -* Usando o comando `gjournal`, um novo dispositivo [.filename]#/dev/ad0s1f.journal# é criado no qual o [.filename]#/dev/ad0s1f# é o data provider, e o [.filename]#/dev/ad0s1g# é o journal provider. Este novo dispositivo é então usado para todas as operações de arquivo posteriores. +* Você deseja fazer o journaling do sistema de arquivos [.filename]#/usr#, armazenado em [.filename]#/dev/ad0s1f# (que já contém dados). +* Você reservou um espaço livre em disco em uma partição em [/dev/ad0s1g]. +* Usando `gjournal`, um novo dispositivo [.filename]#/dev/ad0s1f.journal# é criado, onde [.filename]#/dev/ad0s1f# é o provedor de dados e [.filename]#/dev/ad0s1g# é o provedor de journal. Esse novo dispositivo é então usado para todas as operações de arquivo subsequentes. -A quantidade de espaço em disco que você precisa reservar para o journal provider depende da carga de uso do sistema de arquivos e não do tamanho do data provider. Por exemplo, em um desktop típico de escritório, um journal provider de 1 GB para o sistema de arquivos [.filename]#/usr# será suficiente, enquanto uma máquina que lida com I/O de disco pesado (por exemplo, edição de vídeo) pode precisar de mais. Um kernel panic ocorrerá se o espaço do journal estiver esgotado antes de ter a chance de ser committed. +A quantidade de espaço em disco que você precisa reservar para o provedor de journal depende da carga de uso do sistema de arquivos e não do tamanho do provedor de dados. Por exemplo, em um desktop de escritório típico, um provedor de journal de 1 GB para o sistema de arquivos [.filename]#/usr# será suficiente, enquanto uma máquina que lida com intensas operações E/S de disco (por exemplo, edição de vídeo) pode precisar de mais espaço. Ocorrerá um kernel panic se o espaço do journal for esgotado antes que ele tenha a chance de ser confirmado (committed). [NOTE] ==== -É improvável que os tamanhos de journal sugeridos aqui causem problemas no uso típico de um desktop (como navegação na Web, processamento de texto e reprodução de arquivos de mídia). Se sua carga de trabalho incluir intensa atividade de disco, use a regra a seguir para obter a confiabilidade máxima: o tamanho da RAM deve caber em 30% do espaço do journal provider. Por exemplo, se o seu sistema tiver 1 GB de RAM, crie um journal provider de aproximadamente 3,3 GB. (Multiplique o tamanho total da sua RAM por 3.3 para obter o tamanho do journal). +Os tamanhos de journal sugeridos aqui são altamente improváveis de causar problemas em uso típico de desktop, como navegação na web, processamento de texto e reprodução de arquivos de mídia. Se a sua carga de trabalho inclui atividade intensa de disco, utilize a seguinte regra para obter máxima confiabilidade: o tamanho da sua memória RAM deve caber em 30% do espaço do provedor de journal. Por exemplo, se o seu sistema possui 1 GB de RAM, crie um provedor de journal de aproximadamente 3,3 GB (multiplique o tamanho da sua RAM por 3,3 para obter o tamanho do journal). ==== -Para mais informações sobre journaling, leia a página de manual do man:gjournal[8]. +Para obter mais informações sobre o journaling, por favor, leia a página do manual man:gjournal[8]. [[reserve-space]] == Etapas durante a instalação do FreeBSD === Reservando espaço para o journaling -Normalmente, um desktop típico tem um disco rígido que armazena o sistema operacional e os dados do usuário. Indiscutivelmente, o esquema de particionamento padrão selecionado pelo sysinstall é mais ou menos adequado: Um desktop não precisa de uma grande partição [.filename]#/var#, enquanto o [.filename]#/usr# é alocado com a maior parte do espaço em disco, já que os dados do usuário e muitos pacotes são instalados em seus subdiretórios. +Uma máquina desktop típica geralmente possui um único disco rígido que armazena tanto o sistema operacional quanto os dados do usuário. Argumentavelmente, o esquema de particionamento padrão selecionado pelo sysinstall é mais ou menos adequado: uma máquina desktop não precisa de uma partição [.filename]#/var# grande, enquanto a partição [.filename]#/usr# é alocada para a maior parte do espaço em disco, uma vez que os dados do usuário e muitos pacotes são instalados em seus subdiretórios. -O particionamento padrão (aquele obtido pressionando kbd:[A] no editor de partições do FreeBSD, chamado Disklabel) não deixa nenhum espaço não alocado. Cada partição que será journaled, requer outra partição para journal. Como a partição [.filename]#/usr# é a maior, faz sentido reduzir ligeiramente essa partição, para obter o espaço necessário para o journaling. +A partição padrão (aquela obtida ao pressionar kbd:[A] no editor de partição do FreeBSD, chamado Disklabel) não deixa nenhum espaço não alocado. Cada partição que será jornalizada requer outra partição para o journal. Como a partição [.filename]#/usr# é a maior, faz sentido reduzir levemente essa partição para obter o espaço necessário para o journaling. -No nosso exemplo, um disco de 80 GB é usado. A captura de tela a seguir mostra as partições padrões criadas por Disklabel durante a instalação: +No nosso exemplo, um disco de 80 GB está sendo utilizado. A captura de tela a seguir mostra as partições padrões criadas pelo Disklabel durante a instalação: image::disklabel1.png[] -Se isso é mais ou menos o que você precisa, é muito fácil se ajustar ao journaling. Simplesmente use as teclas de seta para mover o realce para a partição [.filename]#/usr# e pressione kbd:[D] para excluí-la. +Se isso é mais ou menos o que você precisa, é muito fácil ajustar para o journaling. Basta usar as teclas de seta para mover o destaque para a partição [.filename]#/usr# e pressionar kbd:[D] para excluí-la. -Agora, mova o realce para o nome do disco na parte superior da tela e pressione kbd:[C] para criar uma nova partição para [.filename]#/usr#. Esta nova partição deve ser menor em 1 GB (se você pretende registrar apenas [.filename]#/usr#), ou 2 GB (se você pretende registrar ambos [.filename]#/usr# e [.filename]#/var#). No pop-up exibido, opte por criar um sistema de arquivos e digite [.filename]#/usr# como o ponto de montagem. +Agora, mova o destaque para o nome do disco no topo da tela e pressione kbd:[C] para criar uma nova partição para [.filename]#/usr#. Essa nova partição deve ser menor em 1 GB (se você pretende jornalizar apenas [.filename]#/usr#) ou 2 GB (se você pretende jornalizar tanto [.filename]#/usr# quanto [.filename]#/var#). No pop-up que aparece, opte por criar um sistema de arquivos e digite [.filename]#/usr# como ponto de montagem. [NOTE] ==== -Você deve fazer o journal da partição [.filename]#/var#? Normalmente, o journaling faz sentido em partições grandes. Você pode decidir não fazer o journal do [.filename]#/var#, embora fazê-lo em um desktop típico não cause nenhum dano. Se o sistema de arquivos é usado levemente (bastante provável para um desktop) você pode querer alocar menos espaço em disco para o seu journal. +Você deve jornalizar a partição [.filename]#/var#? Normalmente, o journaling faz sentido em partições bastante grandes. Você pode optar por não jornalizar [.filename]#/var#, embora fazê-lo em um desktop típico não cause problemas. Se o sistema de arquivos tiver um uso leve (o que é bastante provável para um desktop), você pode desejar alocar menos espaço em disco para o seu journal. -Em nosso exemplo, nós fizemos o journal em ambos [.filename]#/usr# e [.filename]#/var#. Você pode, naturalmente, ajustar o procedimento às suas próprias necessidades. +No nosso exemplo, nós aplicamos o journaling nas partições [.filename]#/usr# e [.filename]#/var#. Você pode, é claro, ajustar o procedimento de acordo com suas próprias necessidades. ==== -Para manter as coisas o mais fáceis o possível, vamos usar o sysinstall para criar as partições necessárias para o journaling. No entanto, durante a instalação, o sysinstall insiste em pedir um ponto de montagem para cada partição criada. Neste ponto, você não tem nenhum ponto de montagem para as partições que irão manter os journals, e na realidade você __nem precisa deles__. Estas não são partições que iremos montar em algum lugar. +Para facilitar o processo o máximo possível, vamos usar o sysinstall para criar as partições necessárias para o journaling. No entanto, durante a instalação, o sysinstall insiste em solicitar um ponto de montagem para cada partição que você cria. Neste momento, você não possui nenhum ponto de montagem para as partições que irão armazenar os journals e, na realidade, você nem mesmo precisa deles. Essas não são partições que serão montadas em algum lugar. -Para evitar esses problemas com o sysinstall, vamos criar as partições de journal como espaço de troca. O swap nunca é montado, e o sysinstall não tem problemas para criar tantas partições de troca quantas forem necessárias. Após a primeira reinicialização, o [.filename]#/etc/fstab# terá que ser editado, e as entradas extras do espaço de troca serão removidas. +Para evitar esses problemas com o sysinstall, vamos criar as partições de journal como espaço de swap. O swap nunca é montado, e o sysinstall não tem problemas em criar quantas partições de swap forem necessárias. Após o primeiro reinício, será necessário editar o arquivo [.filename]#/etc/fstab# e remover as entradas de espaço de swap adicionais. -Para criar o swap, use novamente as teclas de seta para mover o realce para a parte superior da tela do Disklabel, para que o nome do disco seja realçado. Em seguida, pressione kbd:[N], insira o tamanho desejado (_1024M_) e selecione "swap space" no menu pop-up exibido. Repita para cada journal que você deseja criar. Em nosso exemplo, criamos duas partições para fornecer os diários de [.filename]#/usr# e [.filename]#/var#. O resultado final é mostrado na seguinte captura de tela: +Para criar a partição de swap, novamente use as teclas de seta para mover o destaque para o topo da tela do Disklabel, de modo que o próprio nome do disco seja destacado. Em seguida, pressione kbd:[N], insira o tamanho desejado (_1024M_) e selecione "swap space" no menu pop-up que aparece. Repita esse processo para cada journal que você deseja criar. No nosso exemplo, criaremos duas partições para fornecer os journals de [.filename]#/usr# e [.filename]#/var#. O resultado final é mostrado na captura de tela a seguir: image::disklabel2.png[] -Quando tiver concluído a criação das partições, sugerimos que você anote os nomes das partições e os pontos de montagem, para que possa consultar facilmente essas informações durante a fase de configuração. Isso ajudará a reduzir os erros que podem danificar sua instalação. A tabela a seguir mostra nossas anotações para a configuração de exemplo: +Quando você tiver concluído a criação das partições, sugerimos que anote os nomes das partições e os pontos de montagem para que você possa se referir facilmente a essas informações durante a fase de configuração. Isso ajudará a evitar erros que possam danificar sua instalação. A tabela a seguir mostra nossas anotações para a configuração de exemplo: .Partições e Journals [cols="1,1,1", options="header"] |=== -| Partições -| Ponto de montagem +| Partição +| Ponto de Montagem | Journal |ad0s1d @@ -145,12 +148,12 @@ Quando tiver concluído a criação das partições, sugerimos que você anote o |ad0s1g |=== -Continue a instalação como faria normalmente. No entanto, sugerimos que você adie a instalação de softwares de terceiros (pacotes) até que você configure completamente o journaling. +Continue a instalação como você normalmente faria. No entanto, sugerimos que você adie a instalação de softwares de terceiros (pacotes) até ter configurado completamente o journaling. [[first-boot]] === Inicializando pela primeira vez -Seu sistema irá iniciar normalmente, mas você precisará editar o [.filename]#/etc/fstab# para remover as partições extras de swap que você criou para os journals. Normalmente, a partição swap que você irá usar é aquela com o sufixo "b" (por exemplo, ad0s1b no nosso exemplo). Remova todas as outras entradas de espaço swap e reinicialize para que o FreeBSD pare de usá-las. +Seu sistema inicializará normalmente, mas você precisará editar o arquivo [.filename]#/etc/fstab# e remover as partições de swap extras que você criou para os journals. Normalmente, a partição de swap que você realmente usará é aquela com o sufixo "b" (por exemplo, ad0s1b em nosso exemplo). Remova todas as outras entradas de espaço de swap e reinicie para que o FreeBSD deixe de usá-las. Quando o sistema voltar a funcionar, estaremos prontos para configurar o journaling. @@ -158,32 +161,32 @@ Quando o sistema voltar a funcionar, estaremos prontos para configurar o journal == Configurando o journaling [[running-gjournal]] -=== Executando o `gjournal` +=== Executando o comando `gjournal` -Tendo preparado todas as partições requeridas, é bastante fácil configurar o journaling. Nós precisaremos mudar para o modo de single user, então entre como `root` e digite: +Depois de preparar todas as partições necessárias, é bastante fácil configurar o journaling. Será necessário mudar para o modo de usuário único (single user mode). Para isso, faça o login como `root` e digite o seguinte comando: -[source,shell] +[source, shell] .... # shutdown now .... -Pressione kbd:[Enter] para obter o shell padrão. Nós precisaremos desmontar as partições que serão registradas no diário, no nosso exemplo [.filename]#/usr# e [.filename]#/var#: +Pressione kbd:[Enter] para obter o shell padrão. Agora, você precisará desmontar as partições que serão jornalizadas, no nosso exemplo [.filename]#/usr# e [.filename]#/var#: -[source,shell] +[source, shell] .... # umount /usr /var .... Carregue o módulo necessário para o journaling: -[source,shell] +[source, shell] .... # gjournal load .... -Agora, use suas anotações para determinar qual partição será usada para cada diário. Em nosso exemplo, [.filename]#/usr# é [.filename]#ad0s1f# e seu journal será [.filename]#ad0s1g#, enquanto [.filename]#/var# é [.filename]#ad0s1d# e será journaled para [.filename]#ad0s1h#. Os seguintes comandos são necessários: +Agora, use suas anotações para determinar qual partição será usada para cada journal. No nosso exemplo, [.filename]#/usr# é [.filename]#ad0s1f# e seu journal será [.filename]#ad0s1g#, enquanto [.filename]#/var# é [.filename]#ad0s1d# e será jornalizada em [.filename]#ad0s1h#. Os seguintes comandos são necessários: -[source,shell] +[source, shell] .... # gjournal label ad0s1f ad0s1g GEOM_JOURNAL: Journal 2948326772: ad0s1f contains data. @@ -196,9 +199,9 @@ GEOM_JOURNAL: Journal 3193218002: ad0s1h contains journal. [NOTE] ==== -Se o último setor de qualquer partição for usado, o `gjournal` retornará um erro. Você terá que executar o comando usando o sinalizador `-f` para forçar uma substituição, ou seja: +Se o último setor de qualquer uma das partições estiver em uso, o `gjournal` retornará um erro. Nesse caso, você precisará executar o comando usando a opção `-f` para forçar a sobrescrita. Por exemplo: -[source,shell] +[source, shell] .... # gjournal label -f ad0s1d ad0s1h .... @@ -206,9 +209,9 @@ Se o último setor de qualquer partição for usado, o `gjournal` retornará um Como esta é uma nova instalação, é altamente improvável que qualquer coisa seja realmente sobrescrita. ==== -Neste ponto, dois novos dispositivos são criados, a saber [.filename]#ad0s1d.journal# e [.filename]#ad0s1f.journal#. Os quais representam as partições [.filename]#/var# e [.filename]#/usr# que temos que montar. Antes de montar, devemos definir o flag de Journal e limpar o flag de Soft Updates: +Neste ponto, dois novos dispositivos são criados, chamados [.filename]#ad0s1d.journal# e [.filename]#ad0s1f.journal#. Eles representam as partições [.filename]#/var# e [.filename]#/usr# que devemos montar. No entanto, antes de montá-los, precisamos definir a flag de journaling neles e desativar a flag de Soft Updates: -[source,shell] +[source, shell] .... # tunefs -J enable -n disable ad0s1d.journal tunefs: gjournal set @@ -219,15 +222,15 @@ tunefs: gjournal set tunefs: soft updates cleared .... -Agora, monte os novos dispositivos manualmente em seus respectivos locais (note que agora podemos usar a opção de montagem `async`): +Agora, monte manualmente os novos dispositivos em seus respectivos locais (observe que agora podemos usar a opção de montagem `async`): -[source,shell] +[source, shell] .... # mount -o async /dev/ad0s1d.journal /var # mount -o async /dev/ad0s1f.journal /usr .... -Edite o [.filename]#/etc/fstab# e atualize as entradas para [.filename]#/usr# e [.filename]#/var#: +Edite o arquivo [.filename]#/etc/fstab# e atualize as entradas para [.filename]#/usr# e [.filename]#/var#: [.programlisting] .... @@ -240,16 +243,16 @@ Edite o [.filename]#/etc/fstab# e atualize as entradas para [.filename]#/usr# e Certifique-se de que as entradas acima estão corretas ou você terá problemas para inicializar normalmente após o reboot! ==== -Finalmente, edite o [.filename]#/boot/loader.conf# e adicione a seguinte linha para que o módulo man:gjournal[8] seja carregado em cada boot: +Por fim, edite o arquivo [.filename]#/boot/loader.conf# e adicione a seguinte linha para carregar o módulo man:gjournal[8] em cada inicialização do sistema: [.programlisting] .... geom_journal_load="YES" .... -Parabéns! Seu sistema está agora configurado para journaling. Você pode digitar `exit` para retornar ao modo multiusuário ou reinicializar para testar sua configuração (recomendado). Durante a inicialização, você verá mensagens como as seguintes: +Parabéns! Seu sistema está agora configurado para o journaling. Você pode digitar `exit` para retornar ao modo multiusuário ou reiniciar para testar sua configuração (recomendado). Durante a inicialização, você verá mensagens como as seguintes: -[source,shell] +[source, shell] .... ad0: 76293MB XEC XE800JD-00HBC0 08.02D08 at ata0-master SATA150 GEOM_JOURNAL: Journal 2948326772: ad0s1g contains journal. @@ -262,35 +265,35 @@ GEOM_JOURNAL: Journal ad0s1f clean. Após um encerramento não limpo, as mensagens variam ligeiramente, ou seja: -[source,shell] +[source, shell] .... GEOM_JOURNAL: Journal ad0s1d consistent. .... -Isso geralmente significa que o man:gjournal[8] usou as informações no journal provider para retornar o sistema de arquivos a um estado consistente. +Isso geralmente significa que o man:gjournal[8] utilizou as informações no journal provider para restaurar o sistema de arquivos a um estado consistente. [[gjournal-new]] === Fazendo journaling de partições recém-criadas -Embora o procedimento acima seja necessário para partições que fazem uso de journaling e que já contêm dados, o journaling de uma partição vazia é um pouco mais fácil, uma vez que os dados e o journal provider podem ser armazenados na mesma partição. Por exemplo, suponha que um novo disco tenha sido instalado e uma nova partição [.filename]#/dev/ad1s1d# tenha sido criada. Criar o journal seria tão simples quanto: +Enquanto o procedimento acima é necessário para jornalizar partições que já contêm dados, jornalizar uma partição vazia é um pouco mais fácil, pois tanto o provedor de dados quanto o provedor de journal podem ser armazenados na mesma partição. Por exemplo, suponha que um novo disco tenha sido instalado e uma nova partição [.filename]#/dev/ad1s1d# tenha sido criada. Criar o journal seria tão simples quanto: -[source,shell] +[source, shell] .... # gjournal label ad1s1d .... -O tamanho do journal será 1 GB por padrão. Você pode ajustá-lo usando a opção `-s`. O valor pode ser dado em bytes, ou acrescentado por `K`, `M` ou `G` para indicar Kilobytes, Megabytes ou Gigabytes, respectivamente. Note que o comando `gjournal` não permitirá que você crie journals de tamanhos pequenos e inadequados. +O tamanho do journal será de 1 GB por padrão. Você pode ajustá-lo usando a opção `-s`. O valor pode ser dado em bytes, ou pode ser seguido por `K`, `M` ou `G` para representar Kilobytes, Megabytes ou Gigabytes, respectivamente. Note que o `gjournal` não permitirá que você crie tamanhos de journal excessivamente pequenos e inadequados. Por exemplo, para criar um journal de 2 GB, você poderia usar o seguinte comando: -[source,shell] +[source, shell] .... # gjournal label -s 2G ad1s1d .... -Você pode criar um sistema de arquivos em sua nova partição e ativar o journaling usando a opção `-J`: +Em seguida, você pode criar um sistema de arquivos na sua nova partição e habilitar o journaling usando a opção `-J`: -[source,shell] +[source, shell] .... # newfs -J /dev/ad1s1d.journal .... @@ -298,17 +301,18 @@ Você pode criar um sistema de arquivos em sua nova partição e ativar o journa [[configure-kernel]] === Adicionando suporte ao journaling no seu kernel personalizado -Se você não deseja carregar o `geom_journal` como um módulo, você pode construir suas funções diretamente em seu kernel. Edite seu arquivo de configuração do kernel personalizado e verifique se ele inclui estas duas linhas: +Se você não deseja carregar `geom_journal` como um módulo, você pode incorporar suas funções diretamente no seu kernel. Edite o arquivo de configuração do seu kernel personalizado e verifique se ele inclui as seguintes linhas: [.programlisting] .... options UFS_GJOURNAL # Note: This is already in GENERIC + options GEOM_JOURNAL # You will have to add this one .... -Recompile e reinstale seu kernel seguindo as instruções extref:{handbook}kernelconfig[relevantes no Handbook do FreeBSD, kernelconfig]. +Recompile e reinstale o seu kernel seguindo as instruções relevantes no Handbook do FreeBSD -Não se esqueça de remover a entrada relevante "load" do [.filename]#/boot/loader.conf# se você a usou anteriormente. +Não se esqueça de remover a entrada relevante de "load" do arquivo [.filename]#/boot/loader.conf# se você a tiver usado anteriormente. [[troubleshooting-gjournal]] == Solução de problemas com journaling @@ -317,22 +321,23 @@ A seção a seguir aborda as perguntas mais frequentes relacionadas a problemas === Estou recebendo um kernel panic durante períodos de alta atividade de disco. Como isso está relacionado ao journaling? -O journal provavelmente se enche antes que ele tenha a chance de ser enviado (descarregado) para o disco. Lembre-se de que o tamanho do journal depende da carga de uso e não do tamanho do provedor de dados. Se a atividade do disco for alta, você precisará de uma partição maior para o journal. Veja a nota na seção <>. +O journal provavelmente fica cheio antes de ter a chance de ser confirmado (gravado) no disco. Lembre-se de que o tamanho do journal depende da carga de uso e não do tamanho do provedor de dados. Se a atividade do disco for intensa, será necessário uma partição maior para o journal. Consulte a nota na seção <> para mais informações. === Eu cometi algum erro durante a configuração e não consigo inicializar normalmente agora. Isso pode ser resolvido de alguma forma? -Você esqueceu (ou escreveu incorretamente) a entrada em [.filename]#/boot/loader.conf#, ou existem erros no seu arquivo [.filename]#/etc/fstab#. Estes erros geralmente são fáceis de corrigir. Pressione kbd:[Enter] para acessar o shell padrão do modo single user. Em seguida, localize a raiz do problema: +Parece que você esqueceu (ou digitou incorretamente) a entrada no arquivo [.filename]#/boot/loader.conf# ou existem erros no arquivo [.filename]#/etc/fstab#. Esses erros geralmente são fáceis de corrigir. Pressione kbd:[Enter] para acessar o shell do sistema no modo de usuário unico. Em seguida, localize a raiz do problema: -[source,shell] +[source, shell] .... # cat /boot/loader.conf .... -Se a entrada `geom_journal_load` estiver ausente ou incorreta, os dispositivos registrados nunca serão criados. Carregue o módulo manualmente, monte todas as partições e continue com a inicialização do modo multi usuário: +Se a entrada `geom_journal_load` estiver ausente ou digitada incorretamente, os dispositivos com journaling não serão criados. Carregue o módulo manualmente, monte todas as partições e continue com a inicialização em modo multiusuário: -[source,shell] +[source, shell] .... # gjournal load + GEOM_JOURNAL: Journal 2948326772: ad0s1g contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1h contains journal. GEOM_JOURNAL: Journal 3193218002: ad0s1d contains data. @@ -345,36 +350,36 @@ GEOM_JOURNAL: Journal ad0s1f clean. (boot continues) .... -Se, por outro lado, esta entrada estiver correta, dê uma olhada em [.filename]#/etc/fstab#. Você provavelmente encontrará uma entrada incorreta ou faltando. Nesse caso, monte todas as partições restantes manualmente e continue com o boot em modo multi-usuários. +Por outro lado, se essa entrada estiver correta, verifique o arquivo [.filename]#/etc/fstab#. Provavelmente você encontrará uma entrada ausente ou digitada incorretamente. Nesse caso, monte todas as partições restantes manualmente e continue com a inicialização em modo multiusuário. === Posso remover o registro no journal e retornar ao meu sistema de arquivos padrão com o Soft Updates? -Certo. Use o procedimento a seguir, que inverte as alterações. As partições que você criou para os provedores de journal podem ser usadas para outros propósitos, se você desejar. +Claro. Use o seguinte procedimento, que reverte as alterações. As partições que você criou para os provedores de journal podem ser usadas para outros fins, se desejar. -Faça login como `root` e alterne para o modo de usuário único: +Faça login como `root` e altere para o modo de usuário único: -[source,shell] +[source, shell] .... # shutdown now .... Desmonte as partições journaled: -[source,shell] +[source, shell] .... # umount /usr /var .... Sincronize os journals: -[source,shell] +[source, shell] .... # gjournal sync .... Pare os provedores de journaling: -[source,shell] +[source, shell] .... # gjournal stop ad0s1d.journal # gjournal stop ad0s1f.journal @@ -382,7 +387,7 @@ Pare os provedores de journaling: Limpe os metadados de journaling de todos os dispositivos usados: -[source,shell] +[source, shell] .... # gjournal clear ad0s1d # gjournal clear ad0s1f @@ -392,7 +397,7 @@ Limpe os metadados de journaling de todos os dispositivos usados: Limpe o sinalizador de journaling do sistema de arquivos e restaure a flag do Soft Updates: -[source,shell] +[source, shell] .... # tunefs -J disable -n enable ad0s1d tunefs: gjournal cleared @@ -405,13 +410,13 @@ tunefs: soft updates set Remonte os dispositivos antigos à mão: -[source,shell] +[source, shell] .... # mount -o rw /dev/ad0s1d /var # mount -o rw /dev/ad0s1f /usr .... -Edite o [.filename]#/etc/fstab# e restaure-o ao seu estado original: +Edite o arquivo [.filename]#/etc/fstab# e restaure-o para seu estado original: [.programlisting] .... @@ -419,14 +424,14 @@ Edite o [.filename]#/etc/fstab# e restaure-o ao seu estado original: /dev/ad0s1d /var ufs rw 2 2 .... -Finalmente, edite o [.filename]#/boot/loader.conf#, remova a entrada que carrega o módulo `geom_journal` e reinicie. +Finalmente, edite o arquivo [.filename]#/boot/loader.conf#, remova a entrada que carrega o módulo `geom_journal` e reinicie o sistema. [[further-reading]] == Leitura Adicional -Journaling é um recurso relativamente novo do FreeBSD e, como tal, ainda não está muito bem documentado. Você pode, no entanto, encontrar as seguintes referências adicionais úteis: +O journaling é um recurso relativamente novo no FreeBSD e, portanto, ainda não está muito bem documentado. No entanto, você pode encontrar as seguintes referências adicionais úteis: -* Uma extref:{handbook}geom[nova seção sobre journaling, geom-gjournal] agora faz parte do Handbook do FreeBSD. -* https://lists.freebsd.org/pipermail/freebsd-current/2006-June/064043.html[Este post] em http://lists.FreeBSD.org/mailman/listinfo/freebsd-current[freebsd-current] pelo desenvolvedor do man:gjournal[8], Paweł Jakub Dawidek mailto:pjd@FreeBSD.org[pjd@FreeBSD.org]. -* https://lists.freebsd.org/pipermail/freebsd-questions/2008-April/173501.html[Este post] em http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions[freebsd-questions] por Ivan Voras mailto:ivoras@FreeBSD.org[ivoras@FreeBSD.org]. -* As páginas de manual do man:gjournal[8] e man:geom[8]. +* A extref:{handbook}[nova seção sobre journaling, geom-gjournal] agora faz parte do FreeBSD Handbook. +* https://lists.freebsd.org/pipermail/freebsd-current/2006-June/064043.html[Esta mensagem] na {freebsd-current} enviada por um desenvolvedor do man:gjournal[8]'s, `{pjd}`. +* https://lists.freebsd.org/pipermail/freebsd-questions/2008-April/173501.html[Esta mensagem] na {freebsd-questions} enviada por `{ivoras}`. +* As páginas de manual man:gjournal[8] e man:geom[8]. diff --git a/documentation/content/pt-br/articles/gjournal-desktop/_index.po b/documentation/content/pt-br/articles/gjournal-desktop/_index.po new file mode 100644 index 0000000000..ce86348ed1 --- /dev/null +++ b/documentation/content/pt-br/articles/gjournal-desktop/_index.po @@ -0,0 +1,1348 @@ +# SOME DESCRIPTIVE TITLE +# Copyright (C) YEAR The FreeBSD Project +# This file is distributed under the same license as the FreeBSD Documentation package. +# Danilo G. Baio , 2021. +# Edson Brandi , 2023. +# "Danilo G. Baio" , 2023. +msgid "" +msgstr "" +"Project-Id-Version: FreeBSD Documentation VERSION\n" +"POT-Creation-Date: 2022-02-01 10:28-0300\n" +"PO-Revision-Date: 2023-05-15 19:36+0000\n" +"Last-Translator: Edson Brandi \n" +"Language-Team: Portuguese (Brazil) \n" +"Language: pt_BR\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Plural-Forms: nplurals=2; plural=n > 1;\n" +"X-Generator: Weblate 4.17\n" + +#. type: Title = +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:1 +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:11 +#, no-wrap +msgid "Implementing UFS Journaling on a Desktop PC" +msgstr "Implementando o UFS Journaling em um Desktop PC" + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:44 +msgid "Abstract" +msgstr "Resumo" + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:50 +msgid "" +"A journaling file system uses a log to record all transactions that take " +"place in the file system, and preserves its integrity in the event of a " +"system crash or power failure. Although it is still possible to lose " +"unsaved changes to files, journaling almost completely eliminates the " +"possibility of file system corruption caused by an unclean shutdown. It " +"also shortens to a minimum the time required for after-failure file system " +"checking. Although the UFS file system employed by FreeBSD does not " +"implement journaling itself, the new journal class of the GEOM framework in " +"FreeBSD 7._X_ can be used to provide file system independent journaling. " +"This article explains how to implement UFS journaling on a typical desktop " +"PC scenario." +msgstr "" +"Um sistema de arquivos com journaling utiliza um log para registrar todas as " +"transações que ocorrem no sistema de arquivos e preserva sua integridade em " +"caso de falha do sistema ou queda de energia. Embora ainda seja possível " +"perder alterações não salvas em arquivos, o journaling quase elimina " +"completamente a possibilidade de corrupção do sistema de arquivos causada " +"por uma desligamento incorreto. Ele também reduz ao mínimo o tempo " +"necessário para a verificação do sistema de arquivos após uma falha. Embora " +"o sistema de arquivos UFS utilizado pelo FreeBSD não implemente o journaling " +"por si só, a nova classe de journaling do framework GEOM no FreeBSD 7._X_ " +"pode ser usada para fornecer o journaling independente do sistema de " +"arquivos. Este artigo explica como implementar o journaling do UFS em um " +"cenário típico de um PC desktop." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:52 +msgid "'''" +msgstr "'''" + +#. type: Title == +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:56 +#, no-wrap +msgid "Introduction" +msgstr "Introdução" + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:61 +msgid "" +"While professional servers are usually well protected from unforeseen " +"shutdowns, the typical desktop is at the mercy of power failures, accidental " +"resets, and other user related incidents that can lead to unclean " +"shutdowns. Soft Updates usually protect the file system efficiently in such " +"cases, although most of the times a lengthy background check is required. " +"On rare occasions, file system corruption reaches a point where user " +"intervention is required and data may be lost." +msgstr "" +"Enquanto servidores profissionais geralmente estão bem protegidos contra " +"desligamentos imprevistos, os desktops típicos estão sujeitos a quedas de " +"energia, reinicializações acidentais e outros incidentes relacionados ao " +"usuário que podem levar a desligamentos incorretos. As Soft Updates " +"geralmente protegem o sistema de arquivos de forma eficiente nesses casos, " +"embora na maioria das vezes seja necessária uma verificação em segundo plano " +"demorada. Em raras ocasiões, a corrupção do sistema de arquivos atinge um " +"ponto em que é necessária a intervenção do usuário e dados podem ser " +"perdidos." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:63 +msgid "" +"The new journaling capability provided by GEOM can greatly assist in such " +"scenarios, by virtually eliminating the time required for file system " +"checking, and ensuring that the file system is quickly restored to a " +"consistent state." +msgstr "" +"O novo recurso de journaling fornecido pela GEOM pode ajudar bastante nesses " +"cenários, praticamente eliminando o tempo necessário para a verificação do " +"sistema de arquivos e garantindo que o sistema de arquivos seja rapidamente " +"restaurado para um estado consistente." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:67 +msgid "" +"This article describes a procedure for implementing UFS journaling on a " +"typical desktop PC scenario (one hard disk used for both operating system " +"and data). It should be followed during a fresh installation of FreeBSD. " +"The steps are simple enough and do not require overly complex interaction " +"with the command line." +msgstr "" +"Este artigo descreve um procedimento para implementar o journaling do UFS em " +"um cenário típico de um PC desktop (um disco rígido usado tanto para o " +"sistema operacional quanto para os dados). Ele deve ser seguido durante uma " +"nova instalação do FreeBSD. Os passos são simples o suficiente e não exigem " +"interações excessivamente complexas com a linha de comando." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:69 +msgid "After reading this article, you will know:" +msgstr "Depois de ler este artigo, você saberá:" + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:71 +msgid "" +"How to reserve space for journaling during a new installation of FreeBSD." +msgstr "" +"Como reservar espaço para o journaling durante uma nova instalação do " +"FreeBSD." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:72 +msgid "" +"How to load and enable the `geom_journal` module (or build support for it in " +"your custom kernel)." +msgstr "" +"Como carregar e ativar o módulo `geom_journal` (ou compilar o suporte para " +"ele em seu kernel personalizado)." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:73 +msgid "" +"How to convert your existing file systems to utilize journaling, and what " +"options to use in [.filename]#/etc/fstab# to mount them." +msgstr "" +"Como converter seus sistemas de arquivos existentes para utilizar journaling " +"e quais opções usar no arquivo [.filename]#/etc/fstab# para montá-los." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:74 +msgid "How to implement journaling in new (empty) partitions." +msgstr "Como implementar o journaling em novas partições (vazias)." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:75 +msgid "How to troubleshoot common problems associated with journaling." +msgstr "Como solucionar problemas comuns associados ao journaling." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:77 +msgid "Before reading this article, you should be able to:" +msgstr "Antes de ler este artigo, você deve ser capaz de:" + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:79 +msgid "Understand basic UNIX(R) and FreeBSD concepts." +msgstr "Entender os conceitos básicos do UNIX(R) e do FreeBSD." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:80 +msgid "" +"Be familiar with the installation procedure of FreeBSD and the sysinstall " +"utility." +msgstr "" +"Estar familiarizado com o procedimento de instalação do FreeBSD e com a " +"ferramenta sysinstall." + +#. type: delimited block = 4 +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:86 +msgid "" +"The procedure described here is intended for preparing a new installation " +"where no actual user data is stored on the disk yet. While it is possible " +"to modify and extend this procedure for systems already in production, you " +"should _backup_ all important data before doing so. Messing around with " +"disks and partitions at a low level can lead to fatal mistakes and data loss." +msgstr "" +"A procedimento descrito aqui destina-se a preparar uma nova instalação na " +"qual ainda não existe nenhum dado do usuário armazenado no disco. Embora " +"seja possível modificar e estender este procedimento para sistemas já em " +"produção, você deve fazer um _backup_ de todos os dados importantes antes de " +"fazê-lo. Mexer com discos e partições em um nível baixo pode levar a erros " +"fatais e a perda de dados." + +#. type: Title == +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:89 +#, no-wrap +msgid "Understanding Journaling in FreeBSD" +msgstr "Compreendendo o journaling no FreeBSD" + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:93 +msgid "" +"The journaling provided by GEOM in FreeBSD 7._X_ is not file system specific " +"(unlike for example the ext3 file system in Linux(R)) but is functioning at " +"the block level. Though this means it can be applied to different file " +"systems, for FreeBSD 7.0-RELEASE, it can only be used on UFS2." +msgstr "" +"O journaling fornecido pelo GEOM no FreeBSD 7._X_ não é específico do " +"sistema de arquivos (ao contrário do sistema de arquivos ext3 no Linux(R)), " +"mas funciona no nível de bloco. Embora isso signifique que ele possa ser " +"aplicado a diferentes sistemas de arquivos, no FreeBSD 7.0-RELEASE, ele só " +"pode ser usado no UFS2." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:97 +msgid "" +"This functionality is provided by loading the [.filename]#geom_journal.ko# " +"module into the kernel (or building it into a custom kernel) and using the " +"`gjournal` command to configure the file systems. In general, you would " +"like to journal large file systems, like [.filename]#/usr#. You will need " +"however (see the following section) to reserve some free disk space." +msgstr "" +"Essa funcionalidade é fornecida carregando o módulo [.filename]#geom_journal." +"ko# no kernel (ou compilando-o em um kernel personalizado) e usando o " +"comando `gjournal` para configurar os sistemas de arquivos. Em geral, você " +"gostaria de registrar grandes sistemas de arquivos, como o [.filename]#/usr#" +". No entanto, você precisará reservar algum espaço livre em disco (consulte " +"a próxima seção)." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:104 +msgid "" +"When a file system is journaled, some disk space is needed to keep the " +"journal itself. The disk space that holds the actual data is referred to as " +"the __data provider__, while the one that holds the journal is referred to " +"as the __journal provider__. The data and journal providers need to be on " +"different partitions when journaling an existing (non-empty) partition. " +"When journaling a new partition, you have the option to use a single " +"provider for both data and journal. In any case, the `gjournal` command " +"combines both providers to create the final journaled file system. For " +"example:" +msgstr "" +"Quando um sistema de arquivos é jornalizado, é necessário um espaço em disco " +"para armazenar o próprio journal. O espaço em disco que contém os dados " +"reais é chamado de __provedor de dados__ (data provider), enquanto o que " +"contém o journal é chamado de __provedor de journal__ (journal provider). Os " +"provedores de dados e de journal precisam estar em partições diferentes ao " +"jornalizar uma partição existente (não vazia). Ao jornalizar uma nova " +"partição, você tem a opção de usar um único provedor para ambos os dados e o " +"journal. Em qualquer caso, o comando `gjournal` combina ambos os provedores " +"para criar o sistema de arquivos final com journaling. Por exemplo:" + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:106 +msgid "" +"You wish to journal your [.filename]#/usr# file system, stored in [." +"filename]#/dev/ad0s1f# (which already contains data)." +msgstr "" +"Você deseja fazer o journaling do sistema de arquivos [.filename]#/usr#, " +"armazenado em [.filename]#/dev/ad0s1f# (que já contém dados)." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:107 +msgid "" +"You reserved some free disk space in a partition in [.filename]#/dev/ad0s1g#." +msgstr "" +"Você reservou um espaço livre em disco em uma partição em [/dev/ad0s1g]." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:108 +msgid "" +"Using `gjournal`, a new [.filename]#/dev/ad0s1f.journal# device is created " +"where [.filename]#/dev/ad0s1f# is the data provider, and [.filename]#/dev/" +"ad0s1g# is the journal provider. This new device is then used for all " +"subsequent file operations." +msgstr "" +"Usando `gjournal`, um novo dispositivo [.filename]#/dev/ad0s1f.journal# é " +"criado, onde [.filename]#/dev/ad0s1f# é o provedor de dados e [.filename]#/" +"dev/ad0s1g# é o provedor de journal. Esse novo dispositivo é então usado " +"para todas as operações de arquivo subsequentes." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:112 +msgid "" +"The amount of disk space you need to reserve for the journal provider " +"depends on the usage load of the file system and not on the size of the data " +"provider. For example on a typical office desktop, a 1 GB journal provider " +"for the [.filename]#/usr# file system will suffice, while a machine that " +"deals with heavy disk I/O (i.e. video editing) may need more. A kernel " +"panic will occur if the journal space is exhausted before it has a chance to " +"be committed." +msgstr "" +"A quantidade de espaço em disco que você precisa reservar para o provedor de " +"journal depende da carga de uso do sistema de arquivos e não do tamanho do " +"provedor de dados. Por exemplo, em um desktop de escritório típico, um " +"provedor de journal de 1 GB para o sistema de arquivos [.filename]#/usr# " +"será suficiente, enquanto uma máquina que lida com intensas operações E/S de " +"disco (por exemplo, edição de vídeo) pode precisar de mais espaço. Ocorrerá " +"um kernel panic se o espaço do journal for esgotado antes que ele tenha a " +"chance de ser confirmado (committed)." + +#. type: delimited block = 4 +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:119 +msgid "" +"The journal sizes suggested here, are highly unlikely to cause problems in " +"typical desktop use (such as web browsing, word processing and playback of " +"media files). If your workload includes intense disk activity, use the " +"following rule for maximum reliability: Your RAM size should fit in 30% of " +"the journal provider's space. For example, if your system has 1 GB RAM, " +"create an approximately 3.3 GB journal provider. (Multiply your RAM size " +"with 3.3 to obtain the size of the journal)." +msgstr "" +"Os tamanhos de journal sugeridos aqui são altamente improváveis de causar " +"problemas em uso típico de desktop, como navegação na web, processamento de " +"texto e reprodução de arquivos de mídia. Se a sua carga de trabalho inclui " +"atividade intensa de disco, utilize a seguinte regra para obter máxima " +"confiabilidade: o tamanho da sua memória RAM deve caber em 30% do espaço do " +"provedor de journal. Por exemplo, se o seu sistema possui 1 GB de RAM, crie " +"um provedor de journal de aproximadamente 3,3 GB (multiplique o tamanho da " +"sua RAM por 3,3 para obter o tamanho do journal)." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:122 +msgid "" +"For more information about journaling, please read the manual page of man:" +"gjournal[8]." +msgstr "" +"Para obter mais informações sobre o journaling, por favor, leia a página do " +"manual man:gjournal[8]." + +#. type: Title == +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:124 +#, no-wrap +msgid "Steps During the Installation of FreeBSD" +msgstr "Etapas durante a instalação do FreeBSD" + +#. type: Title === +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:126 +#, no-wrap +msgid "Reserving Space for Journaling" +msgstr "Reservando espaço para o journaling" + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:130 +msgid "" +"A typical desktop machine usually has one hard disk that stores both the OS " +"and user data. Arguably, the default partitioning scheme selected by " +"sysinstall is more or less suitable: A desktop machine does not need a large " +"[.filename]#/var# partition, while [.filename]#/usr# is allocated the bulk " +"of the disk space, since user data and a lot of packages are installed into " +"its subdirectories." +msgstr "" +"Uma máquina desktop típica geralmente possui um único disco rígido que " +"armazena tanto o sistema operacional quanto os dados do usuário. " +"Argumentavelmente, o esquema de particionamento padrão selecionado pelo " +"sysinstall é mais ou menos adequado: uma máquina desktop não precisa de uma " +"partição [.filename]#/var# grande, enquanto a partição [.filename]#/usr# é " +"alocada para a maior parte do espaço em disco, uma vez que os dados do " +"usuário e muitos pacotes são instalados em seus subdiretórios." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:134 +msgid "" +"The default partitioning (the one obtained by pressing kbd:[A] at the " +"FreeBSD partition editor, called Disklabel) does not leave any unallocated " +"space. Each partition that will be journaled, requires another partition " +"for the journal. Since the [.filename]#/usr# partition is the largest, it " +"makes sense to shrink this partition slightly, to obtain the space required " +"for journaling." +msgstr "" +"A partição padrão (aquela obtida ao pressionar kbd:[A] no editor de partição " +"do FreeBSD, chamado Disklabel) não deixa nenhum espaço não alocado. Cada " +"partição que será jornalizada requer outra partição para o journal. Como a " +"partição [.filename]#/usr# é a maior, faz sentido reduzir levemente essa " +"partição para obter o espaço necessário para o journaling." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:137 +msgid "" +"In our example, an 80 GB disk is used. The following screenshot shows the " +"default partitions created by Disklabel during installation:" +msgstr "" +"No nosso exemplo, um disco de 80 GB está sendo utilizado. A captura de tela " +"a seguir mostra as partições padrões criadas pelo Disklabel durante a " +"instalação:" + +#. type: Target for macro image +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:138 +#, no-wrap +msgid "disklabel1.png" +msgstr "disklabel1.png" + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:142 +msgid "" +"If this is more or less what you need, it is very easy to adjust for " +"journaling. Simply use the arrow keys to move the highlight to the [." +"filename]#/usr# partition and press kbd:[D] to delete it." +msgstr "" +"Se isso é mais ou menos o que você precisa, é muito fácil ajustar para o " +"journaling. Basta usar as teclas de seta para mover o destaque para a " +"partição [.filename]#/usr# e pressionar kbd:[D] para excluí-la." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:146 +msgid "" +"Now, move the highlight to the disk name at the top of the screen and press " +"kbd:[C] to create a new partition for [.filename]#/usr#. This new partition " +"should be smaller by 1 GB (if you intend to journal [.filename]#/usr# only), " +"or 2 GB (if you intend to journal both [.filename]#/usr# and [.filename]#/" +"var#). From the pop-up that appears, opt to create a file system, and type " +"[.filename]#/usr# as the mount point." +msgstr "" +"Agora, mova o destaque para o nome do disco no topo da tela e pressione " +"kbd:[C] para criar uma nova partição para [.filename]#/usr#. Essa nova " +"partição deve ser menor em 1 GB (se você pretende jornalizar apenas [." +"filename]#/usr#) ou 2 GB (se você pretende jornalizar tanto [.filename]#/usr#" +" quanto [.filename]#/var#). No pop-up que aparece, opte por criar um sistema " +"de arquivos e digite [.filename]#/usr# como ponto de montagem." + +#. type: delimited block = 4 +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:152 +msgid "" +"Should you journal the [.filename]#/var# partition? Normally, journaling " +"makes sense on quite large partitions. You may decide not to journal [." +"filename]#/var#, although doing so on a typical desktop will cause no harm. " +"If the file system is lightly used (quite probable for a desktop) you may " +"wish to allocate less disk space for its journal." +msgstr "" +"Você deve jornalizar a partição [.filename]#/var#? Normalmente, o journaling " +"faz sentido em partições bastante grandes. Você pode optar por não " +"jornalizar [.filename]#/var#, embora fazê-lo em um desktop típico não cause " +"problemas. Se o sistema de arquivos tiver um uso leve (o que é bastante " +"provável para um desktop), você pode desejar alocar menos espaço em disco " +"para o seu journal." + +#. type: delimited block = 4 +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:155 +msgid "" +"In our example, we journal both [.filename]#/usr# and [.filename]#/var#. " +"You may of course adjust the procedure to your own needs." +msgstr "" +"No nosso exemplo, nós aplicamos o journaling nas partições [.filename]#/usr# " +"e [.filename]#/var#. Você pode, é claro, ajustar o procedimento de acordo " +"com suas próprias necessidades." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:161 +msgid "" +"To keep things as easy going as possible, we are going to use sysinstall to " +"create the partitions required for journaling. However, during " +"installation, sysinstall insists on asking a mount point for each partition " +"you create. At this point, you do not have any mount points for the " +"partitions that will hold the journals, and in reality you __do not even " +"need them__. These are not partitions that we are ever going to mount " +"somewhere." +msgstr "" +"Para facilitar o processo o máximo possível, vamos usar o sysinstall para " +"criar as partições necessárias para o journaling. No entanto, durante a " +"instalação, o sysinstall insiste em solicitar um ponto de montagem para cada " +"partição que você cria. Neste momento, você não possui nenhum ponto de " +"montagem para as partições que irão armazenar os journals e, na realidade, " +"você nem mesmo precisa deles. Essas não são partições que serão montadas em " +"algum lugar." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:165 +msgid "" +"To avoid these problems with sysinstall, we are going to create the journal " +"partitions as swap space. Swap is never mounted, and sysinstall has no " +"problem creating as many swap partitions as needed. After the first reboot, " +"[.filename]#/etc/fstab# will have to be edited, and the extra swap space " +"entries removed." +msgstr "" +"Para evitar esses problemas com o sysinstall, vamos criar as partições de " +"journal como espaço de swap. O swap nunca é montado, e o sysinstall não tem " +"problemas em criar quantas partições de swap forem necessárias. Após o " +"primeiro reinício, será necessário editar o arquivo [.filename]#/etc/fstab# " +"e remover as entradas de espaço de swap adicionais." + +#. type: Plain text +#: documentation/content/en/articles/gjournal-desktop/_index.adoc:171 +msgid "" +"To create the swap, again use the arrow keys to move the highlight to the " +"top of Disklabel screen, so that the disk name itself is highlighted. Then " +"press kbd:[N], enter the desired size (_1024M_), and select \"swap space\" " +"from the pop-up menu that appears. Repeat for every journal you wish to " +"create. In our example, we create two partitions to provide for the " +"journals of [.filename]#/usr# and [.filename]#/var#. The final result is " +"shown in the following screenshot:" +msgstr "" +"Para criar a partição de swap, novamente use as teclas de seta para mover o " +"destaque para o topo da tela do Disklabel, de modo que o próprio nome do " +"disco seja destacado. Em seguida, pressione kbd:[N], insira o tamanho " +"desejado (_1024M_) e selecione \"swap space\" no menu pop-up que aparece. " +"Repita esse processo para cada journal que você deseja criar. No nosso " +"exemplo, criaremos duas partições para fornecer os journals de [." +"filename]#/usr# e [.filename]#/var#. O resultado final é mostrado na captura " +"de tela a seguir:" + +#. type: Target for macro image *** 843 LINES SKIPPED *** From nobody Tue May 16 02:34:56 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QL0h105zZz4BQ1w for ; Tue, 16 May 2023 02:34:57 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QL0h06m83z3pVd; Tue, 16 May 2023 02:34:56 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684204496; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ezZDbqP7msjANkLcRUjwwJmOnNSdWVh90CIMjdNBus0=; b=gTogl2toENvCIa3LMcSZ/2g+X51XRst7xxQ/zhVLXMMVDCJZr1XUeBLMjRVkssXrTKX7i0 fWDytAobpvDQFj/2UwZMbTxrzDBdlblkJaB7mvTCBawnj9CLk4Rqye3QO5WY+0scn7Z0ew uNTvrqWGuCrEUooZNSZYoHys2fx2FpB1gBgaNCHIcD9Ukej8EJMJ3reqf4+Me6D0CPmljV LHBW6uwZqtKkeC0d8dlG1hN5YW7F2tBuj2eqslyRbOk5Y02WgS+uui2kUe7MjV9NLzWT2S t5ITKnbKW/mpCAywlvw092hK7xJ9pEF0JZmNj8OzsEH5O1L6JBDVKDG9y2/Ufg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684204496; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ezZDbqP7msjANkLcRUjwwJmOnNSdWVh90CIMjdNBus0=; b=s7vkk3YP1HiCbExynIeajPPCIjg8x8UB2EP2jYlCgzqsnt4S9jIGqprsiNxtbZCkb1XLFJ RkAVu1WOlSRkDPEB3oZpY8BwywkKDXY5zmZYx85/PE1M2BXR9uTk/gPXjQR5hNre04mEdF VF8QFt5KX8WhsPBLNliwJzPYN3uEzpB1GdeA51gceCaXm2auDmFM8ITsFIQaFUjD1/8j+z WZ/AdmnJebAL306If47x1JYpsRcue6kLLCZxNvGj5m0quO0EkiVMrg32gdxpq5qxJ6fMyo PCNnfVXWZoMQNTuVu0nGxurB/VeyiSBIb0cbQGc+/i71OzUlHAagAEmMTZnPIw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684204496; a=rsa-sha256; cv=none; b=Ky91AHu8e+YlkCtBkf/HbO5m6YYcXxKZ2AGIOt/Js/0H32zczdt3zZ4SjK/wqxXAS/8x2+ OztJlUrx7TqeGBtAAKKLowzznaEx/dFPSxtKr4jxpn66FqwycGi9F3m9TS+kiZgW1fQLT2 rAoadXVWHyKQFuDwbIR4YXe09TLMRBQ1+hvcDERyoJdeOnhyuailtbprsqK/cSG03PFIQU VjPvAu+ZUbp93jhxL4W6TCr9bxLVGbt76/4ixISCehqdFk28GcJXIxP9ZlC3mvGxithIBJ YoU+j4Ze7OqXoy+pR60TRym53dLzEeWwczUIuJKt2OPh+jgibZn77rOz+CifrQ== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QL0h05YJLz14lH; Tue, 16 May 2023 02:34:56 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 34G2YuQx042204; Tue, 16 May 2023 02:34:56 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 34G2YuqU042203; Tue, 16 May 2023 02:34:56 GMT (envelope-from git) Date: Tue, 16 May 2023 02:34:56 GMT Message-Id: <202305160234.34G2YuqU042203@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Graham Perrin Subject: git: 24b32e8dc6 - main - Remove non-working note box markup within a table List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: grahamperrin X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 24b32e8dc6c546f64f5855fd26893d0d5ef39bb3 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by grahamperrin: URL: https://cgit.FreeBSD.org/doc/commit/?id=24b32e8dc6c546f64f5855fd26893d0d5ef39bb3 commit 24b32e8dc6c546f64f5855fd26893d0d5ef39bb3 Author: Graham Perrin AuthorDate: 2023-05-16 02:21:53 +0000 Commit: Graham Perrin CommitDate: 2023-05-16 02:21:53 +0000 Remove non-working note box markup within a table From https://web.archive.org/web/20211112014222/https://docs.freebsd.org/en/books/handbook/zfs/#zfs-term-quota and from https://web.archive.org/web/20211120235121/https://docs.freebsd.org/en/books/handbook/zfs/#zfs-term-quota it seems that note box markup (below) ceased working, within a table, some time between 12th and 20th November 2021. [NOTE] ==== … ==== https://openzfs.github.io/openzfs-docs/man/7/zfsprops.7.html#quota looks fine without using a note box, so let's not attempt to remake the box in the documentation portal. --- documentation/content/en/books/handbook/zfs/_index.adoc | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/documentation/content/en/books/handbook/zfs/_index.adoc b/documentation/content/en/books/handbook/zfs/_index.adoc index 378987e169..343c49ce9c 100644 --- a/documentation/content/en/books/handbook/zfs/_index.adoc +++ b/documentation/content/en/books/handbook/zfs/_index.adoc @@ -2819,10 +2819,7 @@ ZFS supports different types of quotas: the dataset quota, the <; Tue, 16 May 2023 06:58:55 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QL6Xb6Mmtz4D0f; Tue, 16 May 2023 06:58:55 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684220335; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=m0/u5fQgz5OdR5be6lcFb8oJkVQfNnTtAB2RcrWDtK0=; b=sj2zNk41CyDqPtLi03D0iMKPbDTctHk6BNPR8MYtvhsZ+ex7vvzrXcveAw3a57Ya6JJZru 4zS4eb2IDuqHkBczazD87Lr3SjSxDP5H+OTkVohiDiXtvJ1DCQHIoxSnNmwqOli+mTgINb xnO6ld/+jtKR7kCtXoM4z3jtkvOyQD/YFYr1V9adoyJaG1ZzN00X1DyLG6ahNRi0YYhbBR cTxYpC5BwPDtkuMZOLh6tJi90YtRi9J7vo+Z1s+LncQkgGxLh+IRuS5NZSSmxjBImx+Sgw ulN2V1mZYKiI13qpbz5pPBgtn08Ah6INLNrafdoIEej+e8yZFE9kvaAkzz7daA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684220335; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=m0/u5fQgz5OdR5be6lcFb8oJkVQfNnTtAB2RcrWDtK0=; b=Jdw1CvuiOyTuZ+gnZ/LvOZC3f+G+Z8x6Om4HPYTUYPv0I1KY8VNATL20B4fXchyFp1s+Uw dKSX47Tf7qgxDKW7DymmuFFixObEgaRZEo/adxsSXBJSJ3mg8/2oezSvI6IhtPeo0ulyeJ EFhcHtrUkd8qRjbtxKQiMy9Ii5RvE+93Va5hkvZUahKQLgCOPy4vVE+I8gbkib3oGfx/qZ BQL67X2bHTkjxq3dHjGl04DQBXM8QxXN7cxLwtpD1JKyjPftN28ZdP5XSP8RN6x4goBFpC 4OBLjpwY7y1q9qCrONqBuOcZWL1HwQcgbN5W15hwM1ewVzBHaYWQh3NNK1buXw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684220335; a=rsa-sha256; cv=none; b=AyG7Vd6JwmNbWRAcO6aST4CWQ6TVLvSuqH4W6tCsxMXKUDTb7abmueWrrHLmXxnIto9GdF V75L1Jgb+k6OTaIn88GoViPjpsrZPTMtP2c/RDrPoZDChS//BZXFucVmSQPfTixdNskJnO b0T0c2WwI4vxsQJ6use91npa0Hj982nUBXkLpuJJ8sG9KuqFRNTxyO3Qh5UzzUMtexuYx+ M47o8EbdY6SyZ/7WJ5BwvimV6kjnuqbiYVo28iH2os2Wx7oVSDVCPuhroNotkacbYV4RlL eqY3nnbjnj2Ub0ltukjLmpaWqGrCw8xsePTtt5KkHL0Wr/zAO7RSMLPgH0pYhQ== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QL6Xb5PRtz1CR4; Tue, 16 May 2023 06:58:55 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 34G6wtP0071636; Tue, 16 May 2023 06:58:55 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 34G6wtST071635; Tue, 16 May 2023 06:58:55 GMT (envelope-from git) Date: Tue, 16 May 2023 06:58:55 GMT Message-Id: <202305160658.34G6wtST071635@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Graham Perrin Subject: git: c3aecad294 - main - =?utf-8?Q?FreeBSD=20Handbook:=20ZFS=20=E2=80=A6=20Terminology:=20markup?= List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: grahamperrin X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: c3aecad294e54495abd52dc95488e63127235b18 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by grahamperrin: URL: https://cgit.FreeBSD.org/doc/commit/?id=c3aecad294e54495abd52dc95488e63127235b18 commit c3aecad294e54495abd52dc95488e63127235b18 Author: Graham Perrin AuthorDate: 2023-05-16 06:47:54 +0000 Commit: Graham Perrin CommitDate: 2023-05-16 06:47:54 +0000 FreeBSD Handbook: ZFS … Terminology: markup The ` keystroke alone no longer produces the ` character in my desktop environment. I'll seek a fix for the input misbehaviour. In the meantime, here's a fix for a commit that should have included the character. Fixes: 24b32e8dc6 Remove non-working note box markup within a table --- documentation/content/en/books/handbook/zfs/_index.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/content/en/books/handbook/zfs/_index.adoc b/documentation/content/en/books/handbook/zfs/_index.adoc index 343c49ce9c..bf55c48c58 100644 --- a/documentation/content/en/books/handbook/zfs/_index.adoc +++ b/documentation/content/en/books/handbook/zfs/_index.adoc @@ -2819,7 +2819,7 @@ ZFS supports different types of quotas: the dataset quota, the <; Tue, 16 May 2023 17:27:32 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QLNTw3RtFz426H; Tue, 16 May 2023 17:27:32 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684258052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=oOq87DNBkE5w1qhYC3z4V4bBP1bFHLVapV3kZAgztZI=; b=uHkGmhw5tSma3yW1tVgD2NcpZkDKCacSbk4WhOPMwLyAeBrF0pHjSOCrrTxQUUhsUaNHiZ MHcvxTGK4xwBZjJMtkOwXvDB2wkbcZ+dahNt0kiGpowogOaE+GN4x/UuM/JaOLcISX4IWq n52REHClji2ltziQy+0PIeHS4iDyvWsA65vKhisioROX04W/9o/GQLBP71suivoDxbIfjq ivDI3AZe1FibTmPcLPar0ySBswQN682JWLBSidSChfIx5rlMJbyyMXv3lBo8yzwNSUiP1P +7ubT+JHDbnOcfMl5co4aH+JiahA5AUXWD+0F+h7UKzbEirLKomsRbqH5SfNeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684258052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=oOq87DNBkE5w1qhYC3z4V4bBP1bFHLVapV3kZAgztZI=; b=N7YTqvLaqqcbIeSOp/m9LOY0QimiYzuGiMdJnFimVZgDNqsKagfauNnd6i9vsdr+YlgAL9 r/BXtots6fJFhl94gCkuO9kUAEWGxIRUOt2m3DvVXfYoT5aTj9MGymrmh7QDK0hexLnhum GhTweJ8o7BGajKjJLb494kgNAl5OveXP/ZEDFnMfbfRpL8DYumy6AanY23hCIoKug8LKc0 RaJhCpe0Ah+lvdUlJhVYO3NNokBDkKYmj6M5Pbw3UxCuI5J5SIrNm6JaJuoZPCy9Idw2so 4vgOUSIdl3M4WYKMYI7Q/6Aizc23aOwyt90jnNtNXwo0OesObUwxyesXN1yPrw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684258052; a=rsa-sha256; cv=none; b=BODZKqYl5H8RGuSwcNpAMHyVQZrYRRCK2s76A4OGSjEk/jWDBbYV62QQxOz+SyJILHYhYS 4+Pig8sfbYFjfzT75TCJo8UVts1R+3jNeromLPJocUV1D2OSKOQG6YRo7d+MnDaSIiHVzY 500SCBiMMeoxCcmgKviDYxD+Z+mxn5f2/GW6hIP2G7LaoBYDIhfhnVC5Dc9rP4gipu/t4R MFBRl/isCSAk2hpwcdarw73WxLvhDqsVOyN0bMqD58vKVlnX4n2FqFSXPupa1vppj49tM9 Se+d+9QLrRr9wKwtk/Xpb46bNn8UvJ7+9xo4vie8PFWbJojHvs10kt/n1vWDpQ== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QLNTw2Jj3zWD5; Tue, 16 May 2023 17:27:32 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 34GHRWTW008559; Tue, 16 May 2023 17:27:32 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 34GHRWtd008558; Tue, 16 May 2023 17:27:32 GMT (envelope-from git) Date: Tue, 16 May 2023 17:27:32 GMT Message-Id: <202305161727.34GHRWtd008558@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Graham Perrin Subject: git: d3d1c94c8a - main - Git and related corrections and improvements List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: grahamperrin X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: d3d1c94c8aa0db821bb1497aef0a42ffad0aadcb Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by grahamperrin: URL: https://cgit.FreeBSD.org/doc/commit/?id=d3d1c94c8aa0db821bb1497aef0a42ffad0aadcb commit d3d1c94c8aa0db821bb1497aef0a42ffad0aadcb Author: Graham Perrin AuthorDate: 2023-05-16 17:05:23 +0000 Commit: Graham Perrin CommitDate: 2023-05-16 17:05:23 +0000 Git and related corrections and improvements df53ae0fdd98e9452095ac2fdaf95fcfac8c9c7f (2023-04-23): * removed portsnap * encourages use of Git. This round of Git-oriented corrections and changes is, essentially, timed to precede creation of the releng/14.0 branch. Not intended to be comprehensive. Attention to things such as: * HEAD (not a branch) and main (branch) * main (not a branch) and mainline * repositories (there are three) * ports latest, current (not CURRENT) and quarterly * FREEBSD-CURRENT and FREEBSD-STABLE * master * things that were relevant only around the time of migration to Git * markup * grammar. Under https://docs.freebsd.org/en/articles/committers-guide/#_rebasing_your_change_against_latest_freebsd_source_tree a list of items was misrepresented as a single paragraph with asterisk characters in its midst. Reviewed by: carlavilla, imp Approved by: imp Pull Request: https://github.com/freebsd/freebsd-doc/pull/182 Differential revision: https://reviews.freebsd.org/D40026 --- .../en/articles/committers-guide/_index.adoc | 185 +++++++++------------ .../en/books/handbook/cutting-edge/_index.adoc | 2 +- .../content/en/books/handbook/glossary.adoc | 2 +- .../content/en/books/handbook/ports/_index.adoc | 28 ++-- 4 files changed, 94 insertions(+), 123 deletions(-) diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc index 8cdd145f75..47d7060859 100644 --- a/documentation/content/en/articles/committers-guide/_index.adoc +++ b/documentation/content/en/articles/committers-guide/_index.adoc @@ -434,13 +434,24 @@ There are two ways to download. Most people will want to do a deep clone of the repository. However, there are times when you may wish to do a shallow clone. -===== Branch names -The branch names in the new Git repository are similar to the old names. -For the stable branches, they are stable/X where X is the major release (like 11 or 12). -The main branch in the new repository is 'main'. -The main branch in the old GitHub mirror was 'master', but is now 'main'. -Both reflect the defaults of Git at the time they were created. -The 'main' branch is the default branch if you omit the '-b branch' or '--branch branch' options below. +===== Branch Names +FreeBSD-CURRENT uses the `main` branch. + +`main` is the default branch. + +For FreeBSD-STABLE, branch names include `stable/12` and `stable/13`. + +For FreeBSD-RELEASE, release engineering branch names include `releng/12.4` and `releng/13.2`. + +https://www.freebsd.org/releng/[] shows: + +* `main` and `stable/⋯` branches open +* `releng/⋯` branches, each of which is frozen when a release is tagged. + +Examples: + +* tag https://cgit.freebsd.org/src/tag/?h=release/13.1.0[release/13.1.0] on the https://cgit.freebsd.org/src/log/?h=releng/13.1[releng/13.1] branch +* tag https://cgit.freebsd.org/src/tag/?h=release/13.2.0[release/13.2.0] on the https://cgit.freebsd.org/src/log/?h=releng/13.2[releng/13.2] branch. ===== Repositories Please see the <> for the latest information on where to get FreeBSD sources. @@ -455,12 +466,12 @@ It is the easiest to do. It also allows you to use Git's worktree feature to have all your active branches checked out into separate directories but with only one copy of the repository. [source,shell] .... -% git clone -o freebsd $URL -b branch [dir] +% git clone -o freebsd $URL -b branch [] .... -is how you make a deep clone. -'branch' should be one of the branches listed in the previous section. -It is optional if it is the main branch. -'dir' is an optional directory to place it in (the default will be the name of the repo you are cloning (src, doc, etc)). +-- will create a deep clone. +`branch` should be one of the branches listed in the previous section. +If no `branch` is given: the default (`main`) will be used. +If no `` is given: the name of the new directory will match the name of the repo ([.filename]#doc#, [.filename]#ports# or [.filename]#src#). You will want a deep clone if you are interested in the history, plan on making local changes, or plan on working on more than one branch. It is the easiest to keep up to date as well. @@ -481,7 +492,7 @@ However, see below for a significant limitation of this approach. This clones the repository, but only has the most recent version in the repository. The rest of the history is not downloaded. -Should you change your mind later, you can do 'git fetch --unshallow' to get the old history. +Should you change your mind later, you can do `git fetch --unshallow` to get the old history. [WARNING] ==== @@ -516,15 +527,15 @@ This pulls in all the revisions since your last update. .... will update the tree. In Git, a 'fast forward' merge is one that only needs to set a new branch pointer and doesn't need to re-create the commits. -By always doing a 'fast forward' merge/pull, you'll ensure that you have an exact copy of the FreeBSD tree. +By always doing a fast forward merge/pull, you'll ensure that you have an exact copy of the FreeBSD tree. This will be important if you want to maintain local patches. See below for how to manage local changes. -The simplest is to use --autostash on the 'git pull' command, but more sophisticated options are available. +The simplest is to use `--autostash` on the `git pull` command, but more sophisticated options are available. ==== Selecting a Specific Version -In Git, the 'git checkout' checks out both branches and specific versions. +In Git, `git checkout` checks out both branches and specific versions. Git's versions are the long hashes rather than a sequential number. When you checkout a specific version, just specify the hash you want on the command line (the git log command can help you decide which hash you might want): @@ -558,28 +569,28 @@ Sometimes, things go wrong. The last version worked, but the one you just updated to does not. A developer may ask you to bisect the problem to track down which commit caused the regression. -Git makes bisecting changes easy with a powerful 'git bisect' command. +Git makes bisecting changes easy with a powerful `git bisect` command. Here's a brief outline of how to use it. For more information, you can view https://www.metaltoad.com/blog/beginners-guide-git-bisect-process-elimination or https://git-scm.com/docs/git-bisect for more details. The man git-bisect page is good at describing what can go wrong, what to do when versions won't build, when you want to use terms other than 'good' and 'bad', etc, none of which will be covered here. `git bisect start --first-parent` will start the bisection process. Next, you need to tell a range to go through. -'git bisect good XXXXXX' will tell it the working version and 'git bisect bad XXXXX' will tell it the bad version. +`git bisect good XXXXXX` will tell it the working version and `git bisect bad XXXXX` will tell it the bad version. The bad version will almost always be HEAD (a special tag for what you have checked out). The good version will be the last one you checked out. The `--first-parent` argument is necessary so that subsequent `git bisect` commands do not try to check out a vendor branch which lacks the full FreeBSD source tree. [TIP] ==== -If you want to know the last version you checked out, you should use 'git reflog': +If you want to know the last version you checked out, you should use `git reflog`: [source,shell] .... 5ef0bd68b515 (HEAD -> main, freebsd/main, freebsd/HEAD) HEAD@{0}: pull --ff-only: Fast-forward a8163e165c5b (upstream/main) HEAD@{1}: checkout: moving from b6fb97efb682994f59b21fe4efb3fcfc0e5b9eeb to main ... .... -shows me moving the working tree to the main branch (a816...) and then updating from upstream (to 5ef0...). +shows me moving the working tree to the `main` branch (a816...) and then updating from upstream (to 5ef0...). In this case, bad would be HEAD (or 5rf0bd68) and good would be a8163e165. As you can see from the output, HEAD@{1} also often works, but isn't foolproof if you have done other things to your Git tree after updating, but before you discover the need to bisect. ==== @@ -596,11 +607,11 @@ Bisecting: 1722 revisions left to test after this (roughly 11 steps) .... You would then build/install that version. -If it's good you'd type 'git bisect good' otherwise 'git bisect bad'. -If the version doesn't compile, type 'git bisect skip'. +If it's good you'd type `git bisect good` otherwise `git bisect bad`. +If the version doesn't compile, type `git bisect skip`. You will get a similar message to the above after each step. When you are done, report the bad version to the developer (or fix the bug yourself and send a patch). -'git bisect reset' will end the process and return you back to where you started (usually tip of main). +`git bisect reset` will end the process and return you back to where you started (usually tip of `main`). Again, the git-bisect manual (linked above) is a good resource for when things go wrong or for unusual cases. [[git-gpg-signing]] @@ -661,8 +672,8 @@ The cgit repository web interface for use with web browsers is at https://cgit.F The production Git repository is at https://git.FreeBSD.org/ports.git and at ssh://anongit@git.FreeBSD.org/ports.git (or anongit@git.FreeBSD.org:ports.git). There is also a mirror on GitHub, see extref:{handbook}/mirrors[External mirrors, mirrors] for an overview. -The 'current' branch is 'main' . -The quarterly branches are named 'yyyyQn' for year 'yyyy' and quarter 'n'. +The _latest_ branch is `main`. +The _quarterly_ branches are named `yyyyQn` for year 'yyyy' and quarter 'n'. [[port-commit-message-formats]] ===== Commit message formats @@ -703,16 +714,16 @@ However, if you have local changes, you can use the same tool to manage them as All changes that you have not pushed are local and can easily be modified (git rebase, discussed below does this). ===== Keeping local changes -The simplest way to keep local changes (especially trivial ones) is to use 'git stash'. -In its simplest form, you use 'git stash' to record the changes (which pushes them onto the stash stack). +The simplest way to keep local changes (especially trivial ones) is to use `git stash`. +In its simplest form, you use `git stash` to record the changes (which pushes them onto the stash stack). Most people use this to save changes before updating the tree as described above. -They then use 'git stash apply' to re-apply them to the tree. -The stash is a stack of changes that can be examined with 'git stash list'. +They then use `git stash apply` to re-apply them to the tree. +The stash is a stack of changes that can be examined with `git stash list`. The git-stash man page (https://git-scm.com/docs/git-stash) has all the details. This method is suitable when you have tiny tweaks to the tree. When you have anything non trivial, you'll likely be better off keeping a local branch and rebasing. -Stashing is also integrated with the 'git pull' command: just add '--autostash' to the command line. +Stashing is also integrated with the `git pull` command: just add `--autostash` to the command line. ===== Keeping a local branch [[keeping_a_local_branch]] @@ -723,7 +734,7 @@ Git also allows one to merge, along with the same problems. That's one way to manage the branch, but it's the least flexible. In addition to merging, Git supports the concept of 'rebasing' which avoids these issues. -The 'git rebase' command replays all the commits of a branch at a newer location on the parent branch. +The `git rebase` command replays all the commits of a branch at a newer location on the parent branch. We will cover the most common scenarios that arise using it. ====== Create a branch @@ -760,7 +771,7 @@ The commit will pop you into an editor to describe what you've done. Once you enter that, you have your own **local** branch in the Git repo. Build and install it like you normally would, following the directions in the handbook. Git differs from other version control systems in that you have to tell it explicitly which files to commit. -I have opted to do it on the commit command line, but you can also do it with 'git add' which many of the more in depth tutorials cover. +I have opted to do it on the commit command line, but you can also do it with `git add` which many of the more in depth tutorials cover. ====== Time to update @@ -837,7 +848,7 @@ If the commit message is still accurate, just exit the editor. If you get stuck during the rebase, do not panic. git rebase --abort will take you back to a clean slate. It is important, though, to start with an unmodified tree. -An aside: The above mentioned 'git reflog' comes in handy here, as it will have a list of all the (intermediate) commits that you can view or inspect or cherry-pick. +An aside: The above mentioned `git reflog` comes in handy here, as it will have a list of all the (intermediate) commits that you can view or inspect or cherry-pick. For more on this topic, https://www.freecodecamp.org/news/the-ultimate-guide-to-git-merge-and-git-rebase/ provides a rather extensive treatment. It is a good resource for issues that arise occasionally but are too obscure for this guide. @@ -853,7 +864,7 @@ If you have a deep clone, the following will suffice: If you have a local branch, though, there are one or two caveats. First, rebase will rewrite history, so you will likely want to do something to save it. Second, jumping branches tends to cause more conflicts. -If we pretend the example above was relative to stable/12, then to move to main, I'd suggest the following: +If we pretend the example above was relative to stable/12, then to move to `main`, I'd suggest the following: [source,shell] .... % git checkout no-color-ls @@ -863,50 +874,9 @@ If we pretend the example above was relative to stable/12, then to move to main, What the above does is checkout no-color-ls. Then create a new name for it (no-color-ls-stable-12) in case you need to get back to it. -Then you rebase onto the main branch. +Then you rebase onto the `main` branch. This will find all the commits to the current no-color-ls branch (back to where it meets up with the stable/12 branch) and then it will -replay them onto the main branch creating a new no-color-ls branch there (which is why I had you create a place holder name). - -===== Migrating from an existing Git clone -If you have work based on a previous Git conversion or a locally running git-svn conversion, migrating to new repository can encounter problems because Git has no knowledge about the connection between the two. - -When you have only a few local changes, the easiest way would be to cherry-pick those changes to the new base: -[source,shell] -.... -% git checkout main -% git cherry-pick old_branch..your_branch -.... -Or alternatively, do the same thing with rebase: -[source,shell] -.... -% git rebase --onto main master your_branch -.... - -If you do have a lot of changes, you would probably want to perform a merge instead. -The idea is to create a merge point that consolidates the history of the old_branch, and the new FreeBSD repository (main). - -You can find out by looking up the same commit that are found on both parents: -[source,shell] -.... -% git show old_branch -.... -You will see a commit message, now search for that in the new branch: -[source,shell] -.... -% git log --grep="commit message on old_branch" freebsd/main -.... -You would help locate the commit hash on the new main branch, create a helper branch (in the example we call it 'stage') from that hash: -[source,shell] -.... -% git checkout -b stage _hash_found_from_git_log_ -.... -Then perform a merge of the old branch: -[source,shell] -.... -% git merge -s ours -m "Mark old branch as merged" old_branch -.... -With that, it's possible to merge your work branch or the main branch in any order without problem. -Eventually, when you are ready to commit your work back to main, you can perform a rebase to main, or do a squash commit by combining everything into one commit. +replay them onto the `main` branch creating a new no-color-ls branch there (which is why I had you create a place holder name). [[mfc-with-git]] === MFC (Merge From Current) Procedures @@ -989,9 +959,9 @@ Once the MFC is complete, you can delete the temporary branch: ==== MFC a vendor import -Vendor imports are the only thing in the tree that creates a merge commit in the main line. +Vendor imports are the only thing in the tree that creates a merge commit in the `main` branch. Cherry picking merge commits into stable/XX presents an additional difficulty because there are two parents for a merge commit. -Generally, you'll want the first parent's diff since that's the diff to mainline (though there may be some exceptions). +Generally, you'll want the first parent's diff since that's the diff to `main` (though there may be some exceptions). [source,shell] .... @@ -1000,9 +970,9 @@ Generally, you'll want the first parent's diff since that's the diff to mainline is typically what you want. This will tell cherry-pick to apply the correct diff. -There are some, hopefully, rare cases where it's possible that the mainline was merged backwards by the conversion script. -Should that be the case (and we've not found any yet), you'd change the above to '-m 2' to pickup the proper parent. -Just do +There are some, hopefully, rare cases where it's possible that the `main` branch was merged backwards by the conversion script. +Should that be the case (and we've not found any yet), you'd change the above to `-m 2` to pickup the proper parent. +Just do: [source,shell] .... % git cherry-pick --abort @@ -1019,7 +989,7 @@ then the easiest way is to use `git reset --hard` like so: % git reset --hard freebsd/stable/12 .... though if you have some revs you want to keep, and others you don't, -using 'git rebase -i' is better. +using `git rebase -i` is better. ==== Considerations when MFCing @@ -1031,7 +1001,7 @@ When committing source commits to stable and releng branches, we have the follow With Subversion, we used the following practices to achieve these goals: -* Using 'MFC' and 'MFS' tags to mark commits that merged changes from another branch. +* Using `MFC` and `MFS` tags to mark commits that merged changes from another branch. * Squashing fixup commits into the main commit when merging a change. * Recording mergeinfo so that `svn mergeinfo --show-revs` worked. @@ -1046,7 +1016,7 @@ Instead, when this document refers to "merge commits", it means a commit origina Git provides some built-in support for this via the `git cherry` and `git log --cherry` commands. These commands compare the raw diffs of commits (but not other metadata such as log messages) to determine if two commits are identical. -This works well when each commit from head is landed as a single commit to a stable branch, but it falls over if multiple commits from main are squashed together as a single commit to a stable branch. +This works well when each commit from `main` is landed as a single commit to a stable branch, but it falls over if multiple commits from `main` are squashed together as a single commit to a stable branch. The project makes extensive use of `git cherry-pick -x` with all lines preserved to work around these difficulties and is working on automated tooling to take advantage of this. ==== Commit message standards @@ -1066,7 +1036,7 @@ Should it include the metadata from the original commit unchanged, or should it Historical practice has varied, though some of the variance is by field. For example, MFCs that are relevant to a PR generally include the PR field in the MFC so that MFC commits are included in the bug tracker's audit trail. Other fields are less clear. -For example, Phabricator shows the diff of the last commit tagged to a review, so including Phabricator URLs replaces the `main` commit with the landed commits. +For example, Phabricator shows the diff of the last commit tagged to a review, so including Phabricator URLs replaces the main commit with the landed commits. The list of reviewers is also not clear. If a reviewer has approved a change to `main`, does that mean they have approved the MFC commit? Is that true if it's identical code only, or with merely trivial rework? It's clearly not true for more extensive reworks. Even for identical code what if the commit doesn't conflict but introduces an ABI change? A reviewer may have ok'd a commit for `main` due to the ABI breakage but may not approve of merging the same commit as-is. @@ -1179,16 +1149,17 @@ Regular `git rebase` or `git pull --rebase` doesn't know how to rebase a merge c so instead of that you would have to recreate the commit. The following steps should be taken to easily recreate the merge commit as if `git rebase --merge-commits` worked properly: + * cd to the top of the repo * Create a side branch `XXX` with the **contents** of the merged tree. * Update this side branch `XXX` to be merged and up-to-date with FreeBSD's `main` branch. ** In the worst case scenario, you would still have to resolve merge conflicts, if there was any, but this should be really rare. ** Resolve conflicts, and collapse multiple commits down to 1 if need be (without conflicts, there's no collapse needed) -* checkout main +* checkout `main` * create a branch `YYY` (allows for easier unwinding if things go wrong) * Re-do the subtree merge * Instead of resolving any conflicts from the subtree merge, checkout the contents of XXX on top of it. -** The trailing '.' is important, as is being at the top level of the repo. +** The trailing `.` is important, as is being at the top level of the repo. ** Rather than switching branches to XXX, it splats the contents of XXX on top of the repo * Commit the results with the prior commit message (the example assumes there's only one merge on the XXX branch). * Make sure the branches are the same. @@ -1228,7 +1199,7 @@ After review, when you are sure it is a good change, you can push it to the Free [source,shell] .... -% git push freebsd YYY:main # put the commit on upstream's main branch +% git push freebsd YYY:main # put the commit on upstream's 'main' branch % git branch -D XXX # Throw away the throw-a-way branches. % git branch -D YYY .... @@ -1351,7 +1322,7 @@ Here 'good' means: . All the right files, and none of the wrong ones, were merged into contrib/glorbnitz. . No other changes are in the tree. -. The commit messages look <>. It should contain a summary of what's changed since the last merge to the FreeBSD main line and any caveats. +. The commit messages look <>. It should contain a summary of what's changed since the last merge to the FreeBSD `main` branch and any caveats. . UPDATING should be updated if there is anything of note, such as user visible changes, important upgrade concerns, etc. [NOTE] @@ -1368,7 +1339,7 @@ When you checkout `main` make sure that you have no diffs. It's a lot easier to commit those to a branch (or use `git stash`) before doing the following. If you are used to `git pull`, we strongly recommend using the `--ff-only` option, and further setting it as the default option. -Alternatively, `git pull --rebase` is useful if you have changes staged in the main branch. +Alternatively, `git pull --rebase` is useful if you have changes staged in the `main` branch. [source,shell] .... @@ -1397,7 +1368,7 @@ The longer form is also recommended. % git merge --ff-only freebsd/main .... -These commands reset your tree to the main branch, and then update it from where you pulled the tree from originally. +These commands reset your tree to the `main` branch, and then update it from where you pulled the tree from originally. It's important to switch to `main` before doing this so it moves forward. Now, it's time to move the changes forward: @@ -1434,9 +1405,9 @@ freefall% gen-gitconfig.sh on freefall.freebsd.org to get a recipe that you can use directly, assuming /usr/local/bin is in the PATH. -The below command merges the `working` branch into the upstream main line. +The below command merges the `working` branch into the upstream `main` branch. It's important that you curate your changes to be just like you want them in the FreeBSD source repo before doing this. -This syntax pushes the `working` branch to main, moving the `main` branch forward. +This syntax pushes the `working` branch to `main`, moving the `main` branch forward. You will only be able to do this if this results in a linear change to `main` (e.g. no merges). [source,shell] @@ -1555,9 +1526,9 @@ Here's https://adventurist.me/posts/00296[a good writeup] that goes into more de ==== Developers -===== Ooops! I committed to `main` instead of a branch. +===== Ooops! I committed to `main`, instead of another branch. -**Q:** From time to time, I goof up and commit to main instead of to a branch. What do I do? +**Q:** From time to time, I goof up and mistakenly commit to the `main` branch. What do I do? **A:** First, don't panic. @@ -1598,7 +1569,7 @@ cherry-pick it over. **Q:** But what if I want to commit a few changes to `main`, but keep the rest in `wilma` for some reason? **A:** The same technique above also works if you are wanting to 'land' parts of the branch you are working on into `main` before the rest of the branch is ready (say you noticed an unrelated typo, or fixed an incidental bug). -You can cherry pick those changes into main, then push to the parent repository. +You can cherry pick those changes into `main`, then push to the parent repository. Once you've done that, cleanup couldn't be simpler: just `git rebase -i`. Git will notice you've done this and skip the common changes automatically (even if you had to change the commit message or tweak the commit slightly). There's no need to switch back to wilma to adjust it: just rebase! @@ -1675,8 +1646,8 @@ You can also stack: .... and you are ready to try again. -The 'checkout -B' with the hash combines checking out and creating a branch for it. -The -B instead of -b forces the movement of a pre-existing branch. +The `checkout -B` with the hash combines checking out and creating a branch for it. +The `-B` instead of `-b` forces the movement of a pre-existing branch. Either way works, which is what's great (and awful) about Git. One reason I tend to use `git checkout -B xxxx hash` instead of checking out the hash, and then creating / moving the branch is purely to avoid the slightly distressing message about detached heads: @@ -1703,7 +1674,7 @@ this produces the same effect, but I have to read a lot more and severed heads a ===== Ooops! I did a `git pull` and it created a merge commit, what do I do? -**Q:** I was on autopilot and did a `git pull` for my development tree and that created a merge commit on the mainline. +**Q:** I was on autopilot and did a `git pull` for my development tree and that created a merge commit on `main`. How do I recover? **A:** This can happen when you invoke the pull with your development branch checked out. @@ -1853,7 +1824,7 @@ However, there are two disadvantages to this if you want to use it for anything First, this is a 'bare repository' which has the repository database, but no checked out worktree. This is great for mirroring, but terrible for day to day work. -There's a number of ways around this with 'git worktree': +There's a number of ways around this with `git worktree`: [source,shell] .... @@ -1890,7 +1861,7 @@ To setup your repository to do that: git config --add remote.freebsd.fetch '+refs/*:refs/freebsd/*' .... -which will put everything in the upstream repository into your local repository's 'refs/freebsd/' namespace. +which will put everything in the upstream repository into your local repository's `refs/freebsd/` namespace. Please note, that this also grabs all the unconverted vendor branches and the number of refs associated with them is quite large. You'll need to refer to these 'refs' with their full name because they aren't in and of Git's regular namespaces. @@ -1907,7 +1878,7 @@ would look at the log for the vendor branch for zlib starting at 1.2.10. One of the keys to good software development on a project as large as FreeBSD is the ability to collaborate with others before you push your changes to the tree. The FreeBSD project's Git repositories do not, yet, allow user-created branches to be pushed to the repository, and therefore if you wish to share your changes with others you must use another mechanism, such as a hosted GitLab or GitHub, in order to share changes in a user-generated branch. -The following instructions show how to set up a user-generated branch, based on the FreeBSD main branch, and push it to GitHub. +The following instructions show how to set up a user-generated branch, based on the FreeBSD `main` branch, and push it to GitHub. Before you begin, make sure that your local Git repo is up to date and has the correct origins set <> @@ -2340,7 +2311,7 @@ Detailed information on how to access these branches can be found in < /usr/local/etc/pkg/repos/FreeBSD.conf .... -Then run this command to update the local package repositories catalogues for the Latest branch: +Then run this command to update the local package repositories catalogues: [source,shell] .... -# pkg update -f +# pkg update .... [[pkg-configuration]] @@ -675,13 +675,13 @@ By default, the Ports Collection itself is stored as a subdirectory of `/usr/por [WARNING] ==== Before installing and using the Ports Collection, please be aware that it is generally ill-advised to use the Ports Collection in conjunction with the binary packages provided via pkg to install software. -pkg, by default, tracks quarterly branch-releases of the ports tree and not HEAD. -Dependencies could be different for a port in HEAD compared to its counterpart in a quarterly branch release and this could result in conflicts between dependencies installed by pkg and those from the Ports Collection. -If the Ports Collection and pkg must be used in conjunction, then be sure that your Ports Collection and pkg are on the same branch release of the ports tree. +In RELEASE versions of FreeBSD: man:pkg.conf[5] defaults to quarterly, not latest. +Dependencies could be different for a port in latest, compared to its counterpart (if any) in quarterly, and this could result in conflicts between dependencies installed by pkg and those from the Ports Collection. +If the Ports Collection and pkg must be used in conjunction, then be sure that your Ports Collection and pkg are on the same branch of the ports tree. ==== The Ports Collection contains directories for software categories. -Inside each category are subdirectories for individual applications. +Within each category are subdirectories for individual applications. Each application subdirectory contains a set of files that tells FreeBSD how to compile and install that program, called a _ports skeleton_. Each port skeleton includes these files and directories: @@ -727,14 +727,14 @@ If the ports tree is not available, or pkg is being used to manage packages, Git # pkg install git .... + -. Check out a copy of the HEAD branch of the ports tree: +. Check out the `main` branch of the ports repo: + [source,shell] .... # git clone https://git.FreeBSD.org/ports.git /usr/ports .... + -. Or, check out a copy of a quarterly branch: +. Or, check out a quarterly branch: + [source,shell] .... From nobody Wed May 17 09:28:50 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QLnq64kHJz4C79H for ; Wed, 17 May 2023 09:28:50 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QLnq64Mzwz3xSD; Wed, 17 May 2023 09:28:50 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684315730; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=6oF/etlYOxwbHahnxag2nn/U4k8ZcxWxRKBanOOLTRk=; b=fY8gIrJC/TkOohiFV0tFjLwr/9u3wjEP/NAsSFhGfTnVjasUgYsZgQAtxVwQc2KvMx+ixA GLaa1V189CR+RMZDOdCm2Gtz2g4Py0fiZzwqwKKVnrdN8E0oZc2bnUOa3xki6A0GrXzSjR yaHEhfXLtl69XEYJKpAy36x22ajRaU1vlJQvGCsAwILMSsDQM/brgDV2tSlB1aQtaJt1ms DfTdXH3dOhLqlYJEf65DFgI8+Ty0VsITNP0oItHGRhSPKUGqXs+Oqa+XoOU1qIs6JfN9Dh F8s76p4VFR3ED/nGqIZqo3aETCRN9uylMMAswGcR0rrfY8AKeHi/4t5rOOVAKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684315730; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=6oF/etlYOxwbHahnxag2nn/U4k8ZcxWxRKBanOOLTRk=; b=ww651T5lMW4NZjly0HobYTYRfvGwhBAOjsCBTGKx1r90yRTGBCfP50Q4m91vw9g7YIJmCF Dp3S7TmmXs8VVjer8PDUB3wxZLtFVQfRiOTWQEUJ8eIs8v307yewRlGNyQpPBQNrCqG1qF mh67+Ny6WZVHcYNTAt685SFJnGqHVphLW25ahZlrwLabphLSkx3LLulzsTDlNHUoDOvywK RyCa6FDa7JvSEOU3/SlINDgc3SvRNa/31kqpYbqkyEUEVJv+GIJEj0qWh3cMam0jvY3YPi zMAxKtZ/SNPmvsV7A4WtWgssy7Nqk7haqFv9kZNgj/dGuso/8UfaAGTorodxeg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684315730; a=rsa-sha256; cv=none; b=mGh8JQYC30pN4uuofjWYAH52ZuAtQJ2WxQseh3jkpLltAYbsypg6gYWZpxVBZC7cMNpNuK nq6ZQ+tYNW52EKopgVb6KWAzOkX0WE1pTGgTAQrfYJYCZZbKKs4e5Dm0JYHrVJNdq7eO+N SXywTUNl8tz+auqBKsnNEv8aK2UdP7O79dZ4jCejtOOFpJ+v8uEB0NS+o9IdOXHEr1AwHF gOQgo6tlwH7MMd26qNDBjqqO+ohSY4LMS35VLQV7oymz2sN72iYj+LPPWL1fNe79Tid1Gw PZ+Ty5jGJPTcjjG5umLsbAxxy356HjGH+2HVyK+ZQB2bIUWG6P/1wt5OUwfv2A== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QLnq63SHTzyVc; Wed, 17 May 2023 09:28:50 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 34H9SoPv090532; Wed, 17 May 2023 09:28:50 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 34H9SoL1090531; Wed, 17 May 2023 09:28:50 GMT (envelope-from git) Date: Wed, 17 May 2023 09:28:50 GMT Message-Id: <202305170928.34H9SoL1090531@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Muhammad Moinur Rahman Subject: git: 740a779dcc - main - porters-handbook/versions: Pet vale List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: bofh X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 740a779dcc535a86a735e8eae051169cbe1bb0bd Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by bofh: URL: https://cgit.FreeBSD.org/doc/commit/?id=740a779dcc535a86a735e8eae051169cbe1bb0bd commit 740a779dcc535a86a735e8eae051169cbe1bb0bd Author: Muhammad Moinur Rahman AuthorDate: 2023-05-17 09:26:40 +0000 Commit: Muhammad Moinur Rahman CommitDate: 2023-05-17 09:28:32 +0000 porters-handbook/versions: Pet vale - Find the terms that are only used once in our entire doc set and mark those with back ticks so they are not marked as spelling mistakes by Vale - Reduce pronouns usage and change accordingly - Use Conscious language - Fix spelling mistakes - Fix repeated words - Fix EOL Spaces - Reduce contractions - Bypass Vale.Terms rule in 3 cases where it should be written as freebsd instead of FreeBSD Approved by: bcr (mentor) Differential Revision: https://reviews.freebsd.org/D40080 --- .../en/books/porters-handbook/versions/_index.adoc | 372 +++++++++++---------- 1 file changed, 189 insertions(+), 183 deletions(-) diff --git a/documentation/content/en/books/porters-handbook/versions/_index.adoc b/documentation/content/en/books/porters-handbook/versions/_index.adoc index 1617a30f36..d0f8e0f258 100644 --- a/documentation/content/en/books/porters-handbook/versions/_index.adoc +++ b/documentation/content/en/books/porters-handbook/versions/_index.adoc @@ -103,7 +103,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1400008 |gitref:e152bbecb221a592e7dbcabe3d1170a60f0d0dfe[repository="src",length=12] |April 11, 2021 -|14.0-CURRENT after changing the internal KAPI between the krpc and NFS modules. +|14.0-CURRENT after changing the internal KAPI between the `krpc` and NFS modules. |1400009 |gitref:9ca874cf740ee68c5742df8b5f9e20910085c011[repository="src",length=12] @@ -113,7 +113,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1400010 |gitref:a3a02acde1009f03dc78e979e051acee9f9247c2[repository="src",length=12] |April 21, 2021 -|14.0-CURRENT after changing the man:sndstat[4] ioctls nvlist schema and definitions. +|14.0-CURRENT after changing the man:sndstat[4] ioctls `nvlist` schema and definitions. |1400015 |gitref:d72cd275187c6399caf0ca4125292dc7e55fa478[repository="src",length=12] @@ -153,7 +153,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1400022 |gitref:40cc9a3a6b81a65a03712dfd93bbed48552a97ad[repository="src",length=12] |June 11, 2021 -|14.0-CURRENT after commit gitref:e1a907a25cfa422c0d1acaf9f91352ada04f4bca[repository="src",length=12] changed the internal KAPI between the krpc and nfsserver modules. +|14.0-CURRENT after commit gitref:e1a907a25cfa422c0d1acaf9f91352ada04f4bca[repository="src",length=12] changed the internal KAPI between the `krpc` and nfsserver modules. |1400023 |gitref:d409305fa3838fb39b38c26fc085fb729b8766d5[repository="src",length=12] @@ -228,7 +228,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1400037 |gitref:2b68eb8e1dbbdaf6a0df1c83b26f5403ca52d4c3[repository="src",length=12] |October 11, 2021 -|14.0-CURRENT after removal of thread argument from man:VOP_STAT[9] and fo_stat. +|14.0-CURRENT after removal of thread argument from man:VOP_STAT[9] and `fo_stat`. |1400038 |gitref:0d6516b453469ce1d92ec903c4c4df9ee08be0f9[repository="src",length=12] @@ -293,7 +293,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1400050 |gitref:213e91399b7998554d787bb290109ebe602aa279[repository="src",length=12] |January 25, 2022 -|14.0-CURRENT after iflib adds the feature that a driver can set its own TX queue selection function as ift_txq_select in struct if_txrx. +|14.0-CURRENT after iflib adds the feature that a driver can set its own TX queue selection function as `ift_txq_select` in struct `if_txrx`. |1400051 |gitref:59d465e200bb7058dfdb183c061730c10dd5bc03[repository="src",length=12] @@ -313,12 +313,12 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1400054 |gitref:50bb3a33d879536e86e8a23365f070ef00b5cb32[repository="src",length=12] |March 28, 2022 -|14.0-CURRENT after changing irq_work_queue to return a bool in LinuxKPI to match 5.10 API. +|14.0-CURRENT after changing `irq_work_queue` to return a bool in LinuxKPI to match 5.10 API. |1400055 |gitref:d69af4758be912625ec08656ba64eb90a98c9a7f[repository="src",length=12] |March 29, 2022 -|14.0-CURRENT after adding for_each_sgtable_dma_sg and for_each_sgtable_dma_page to LinuxKPI +|14.0-CURRENT after adding `for_each_sgtable_dma_sg` and `for_each_sgtable_dma_page` to LinuxKPI |1400056 |gitref:ab8ac4c28574a42a2891b2e2341f802949c1fb57[repository="src",length=12] @@ -353,7 +353,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1400062 |gitref:8c309d48aabf1cb469334c7716033f177a2715c0[repository="src",length=12] |June 18, 2022 -|14.0-CURRENT after struct kinfo_file changes. +|14.0-CURRENT after struct `kinfo_file` changes. |1400063 |gitref:8cff8e6e13a6d3ccff40fc0d8d97f5aef22a8f4d[repository="src",length=12] @@ -393,7 +393,7 @@ Here is a convenient list of `__FreeBSD_version` values as defined in https://cg |1400072 |gitref:8a96874eeeee5195b0b0952b77227bef6a26d1a6[repository="src",length=12] |September 22, 2022 -|14.0-CURRENT after qsort_r prototype modified to match POSIX. +|14.0-CURRENT after `qsort_r` prototype modified to match POSIX. |1400073 |gitref:9c950139051298831ce19d01ea5fb33ec6ea7f89[repository="src",length=12] @@ -471,7 +471,7 @@ Template: |1300003 |link:https://svnweb.freebsd.org/changeset/base/340055[340055] |November 2, 2018 -|13.0-CURRENT after vop_symlink API change (`a_target` is now `const`.) +|13.0-CURRENT after `vop_symlink` API change (`a_target` is now `const`.) |1300004 |link:https://svnweb.freebsd.org/changeset/base/340841[340841] @@ -516,7 +516,7 @@ Template: |1300012 |link:https://svnweb.freebsd.org/changeset/base/344062[344062] |February 12, 2019 -|13.0-CURRENT after `taskqgroup_attach()` and `taskqgroup_attach_cpu()` take a device_t and a struct resource pointer as arguments for denoting device interrupts. +|13.0-CURRENT after `taskqgroup_attach()` and `taskqgroup_attach_cpu()` take a `device_t` and a struct resource pointer as arguments for denoting device interrupts. |1300013 |link:https://svnweb.freebsd.org/changeset/base/344300[344300] @@ -546,7 +546,7 @@ Template: |1300018 |link:https://svnweb.freebsd.org/changeset/base/346012[346012] |March 16, 2019 -|13.0-CURRENT after introduction of funlinkat syscall in link:https://svnweb.freebsd.org/changeset/base/345982[345982]. +|13.0-CURRENT after introduction of `funlinkat` syscall in link:https://svnweb.freebsd.org/changeset/base/345982[345982]. |1300019 |link:https://svnweb.freebsd.org/changeset/base/346282[346282] @@ -591,12 +591,12 @@ Template: |1300027 |link:https://svnweb.freebsd.org/changeset/base/347601[347601] |May 14, 2019 -|13.0-CURRENT after adding prepare to pm_ops in LinuxKPI. +|13.0-CURRENT after adding prepare to `pm_ops` in LinuxKPI. |1300028 |link:https://svnweb.freebsd.org/changeset/base/347925[347925] |May 17, 2019 -|13.0-CURRENT after removal of bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, and xe drivers. +|13.0-CURRENT after removal of `bm`, `cs`, de, ed, `ep`, ex, `fe`, `pcn`, sf, `sn`, `tl`, `tx`, `txp`, `vx`, `wb`, and xe drivers. |1300029 |link:https://svnweb.freebsd.org/changeset/base/347984[347984] @@ -631,7 +631,7 @@ Template: |1300035 |link:https://svnweb.freebsd.org/changeset/base/349846[349846] |July 8, 2019 -|13.0-CURRENT after merging the vm_page hold and wire mechanisms. +|13.0-CURRENT after merging the `vm_page` hold and wire mechanisms. |1300036 |link:https://svnweb.freebsd.org/changeset/base/349972[349972] @@ -696,7 +696,7 @@ Template: |1300047 |link:https://svnweb.freebsd.org/changeset/base/352110[352110] |September 9, 2019 -|13.0-CURRENT after changing the synchonization rules for vm_page reference counting.. +|13.0-CURRENT after changing the synchronization rules for `vm_page` reference counting.. |1300048 |link:https://svnweb.freebsd.org/changeset/base/352700[352700] @@ -751,12 +751,12 @@ Template: |1300058 |link:https://svnweb.freebsd.org/changeset/base/354820[354820] |November 18, 2019 -|13.0-CURRENT after widening the vm_page aflags field to 16 bits. +|13.0-CURRENT after widening the `vm_page` `aflags` field to 16 bits. |1300059 |link:https://svnweb.freebsd.org/changeset/base/354835[354835] |November 18, 2019 -|13.0-CURRENT after converting the in-tree sysent targets to use the new [.filename]#makesyscalls.lua#. +|13.0-CURRENT after converting the in-tree `sysent` targets to use the new [.filename]#makesyscalls.lua#. |1300060 |link:https://svnweb.freebsd.org/changeset/base/354922[354922] @@ -786,7 +786,7 @@ Template: |1300065 |link:https://svnweb.freebsd.org/changeset/base/355643[355643] |December 12, 2019 -|13.0-CURRENT after adding sigsetop extensions commonly found in musl libc and glibc. +|13.0-CURRENT after adding `sigsetop` extensions commonly found in musl libc and glibc. |1300066 |link:https://svnweb.freebsd.org/changeset/base/355679[355679] @@ -841,7 +841,7 @@ Template: |1300076 |link:https://svnweb.freebsd.org/changeset/base/356511[356511] |January 8, 2020 -|13.0-CURRENT after pushing vnop implementation into the fileop layer in man:posix_fallocate[2]. +|13.0-CURRENT after pushing `vnop` implementation into the `fileop` layer in man:posix_fallocate[2]. |(not changed) |link:https://svnweb.freebsd.org/changeset/base/357396[357396] @@ -866,7 +866,7 @@ Template: |1300080 |link:https://svnweb.freebsd.org/changeset/base/358172[358172] |February 20, 2020 -|13.0-CURRENT after adding realpathat syscall to VFS. +|13.0-CURRENT after adding `realpathat` syscall to VFS. |1300081 |link:https://svnweb.freebsd.org/changeset/base/358218[358218] @@ -926,7 +926,7 @@ Template: |1300092 |link:https://svnweb.freebsd.org/changeset/base/359920[359920] |April 14, 2020 -|13.0-CURRENT after reworking unmapped mbufs in KTLS to carry ext_pgs in the mbuf itself. +|13.0-CURRENT after reworking unmapped mbufs in KTLS to carry `ext_pgs` in the mbuf itself. |1300093 |link:https://svnweb.freebsd.org/changeset/base/360418[360418] @@ -981,12 +981,12 @@ Template: |1300103 |link:https://svnweb.freebsd.org/changeset/base/363757[363757] |August 1, 2020 -|13.0-CURRENT after making rights mandatory for NDINIT_ALL. +|13.0-CURRENT after making rights mandatory for NDINIT_ALL. |1300104 |link:https://svnweb.freebsd.org/changeset/base/363783[363783] |August 2, 2020 -|13.0-CURRENT after vnode layout changes. +|13.0-CURRENT after vnode layout changes. |1300105 |link:https://svnweb.freebsd.org/changeset/base/363894[363894] @@ -1006,12 +1006,12 @@ Template: |1300108 |link:https://svnweb.freebsd.org/changeset/base/364233[364233] |August 14, 2020 -|13.0-CURRENT after adding a few wait_bit functions to the linuxkpi, which are needed for DRM from Linux v5.4. +|13.0-CURRENT after adding a few `wait_bit` functions to the linuxkpi, which are needed for DRM from Linux v5.4. |1300109 |link:https://svnweb.freebsd.org/changeset/base/364274[364274] |August 16, 2020 -|13.0-CURRENT after `vget()` argument removal and namei flags renumbering. +|13.0-CURRENT after `vget()` argument removal and `namei` flags renumbering. |(not changed) |link:https://svnweb.freebsd.org/changeset/base/364284[364284] @@ -1036,7 +1036,7 @@ Template: |1300113 |link:https://svnweb.freebsd.org/changeset/base/364753[364753] |August 25, 2020 -|13.0-CURRENT after adding atomic and bswap functions to libcompiler_rt. +|13.0-CURRENT after adding atomic and `bswap` functions to libcompiler_rt. |1300114 |link:https://svnweb.freebsd.org/changeset/base/365459[365459] @@ -1056,7 +1056,7 @@ Template: |1300117 |link:https://svnweb.freebsd.org/changeset/base/366070[366070] |September 23, 2020 -|13.0-CURRENT after reimplementing purgevfs to iterate vnodes instead of the entire hash. +|13.0-CURRENT after reimplementing `purgevfs` to iterate vnodes instead of the entire hash. |1300118 |link:https://svnweb.freebsd.org/changeset/base/366374[366374] @@ -1116,12 +1116,12 @@ Template: |1300129 |link:https://svnweb.freebsd.org/changeset/base/367627[367627] |November 12, 2020 -|13.0-CURRENT after retiring malloc_last_fail. +|13.0-CURRENT after retiring `malloc_last_fail`. |1300130 |link:https://svnweb.freebsd.org/changeset/base/367777[367777] |November 17, 2020 -|13.0-CURRENT after p_pd / pwddesc split from p_fd / filedesc. +|13.0-CURRENT after `p_pd` / `pwddesc` split from `p_fd` / filedesc. |1300131 |link:https://svnweb.freebsd.org/changeset/base/368417[368417] @@ -1151,7 +1151,7 @@ Template: |1300136 |gitref:72c551930be195b5ea982c1b16767f54388424f2[repository="src",length=12] |January 17, 2021 -|13.0-CURRENT after reimplementing LinuxKPI's `irq_work` queue on top of fast taskqueue. +|13.0-CURRENT after reimplementing LinuxKPI's `irq_work` queue on top of fast `taskqueue`. |1300137 |gitref:010196adcfaf2bb610725394d40691874b4ff2af[repository="src",length=12] @@ -1231,7 +1231,7 @@ Template: |1300511 |gitref:2622570aeb3d162812d72f7ef192c322cd8b73ef[repository="src",length=12] |July 7, 2021 -|13.0-STABLE after changing `softdep_prelink()` to only do sync if another thread changed the vnode metadata since previous prelink. +|13.0-STABLE after changing `softdep_prelink()` to only do sync if another thread changed the vnode metadata since previous `prelink`. |1300512 |gitref:f72db34d2295080f57a283858125aa906c0d409e[repository="src",length=12] @@ -1331,7 +1331,7 @@ Template: |1301506 |gitref:8e6cfc632cf6f9fc906df9d825649443939b55c6[repository="src",length=12] |July 13, 2022 -|13.1-STABLE after after adding and . +|13.1-STABLE after adding and . |1301507 |gitref:9cbba5950123f3afedcc5f24c43956e7a26f22f4[repository="src",length=12] @@ -1356,7 +1356,7 @@ Template: |1301511 |gitref:17333d92643d998d1c6a2dc5f6b1508b6507ad31[repository="src",length=12] |December 17, 2022 -|13.1-STABLE after adding a new rc: machine_id to generate `/etc/machine-id`. +|13.1-STABLE after adding a new rc: `machine_id` to generate `/etc/machine-id`. |1302500 |gitref:c243de11cf7c4bb3d67bbc1655b149037e5b04f1[repository="src",length=12] @@ -1381,7 +1381,7 @@ Template: |1302504 |gitref:d6852eed98ed32ad51120a22aa1ebdf0601917b3[repository="src",length=12] |March 12, 2023 -|13.2-STABLE after merging machine-id into hostid_save. +|13.2-STABLE after merging machine-id into `hostid_save`. |1302505 |gitref:85e32e957fcca01d50e29e543584909795c1acef[repository="src",length=12] @@ -1464,7 +1464,7 @@ Template: |1200010 |link:https://svnweb.freebsd.org/changeset/base/306276[306276] |September 23, 2016 -|12.0-CURRENT after mounting man:msdosfs[5] with longnames support by default. +|12.0-CURRENT after mounting man:msdosfs[5] with `longnames` support by default. |1200011 |link:https://svnweb.freebsd.org/changeset/base/306556[306556] @@ -1479,7 +1479,7 @@ Template: |1200013 |link:https://svnweb.freebsd.org/changeset/base/307140[307140] |October 12, 2016 -|12.0-CURRENT after installing header files required development with libzfs_core. +|12.0-CURRENT after installing header files required development with `libzfs_core`. |1200014 |link:https://svnweb.freebsd.org/changeset/base/307529[307529] @@ -1499,7 +1499,7 @@ Template: |1200017 |link:https://svnweb.freebsd.org/changeset/base/309124[309124] |November 25, 2016 -|12.0-CURRENT after upgrading our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.0 release, and adding lld 3.9.0. +|12.0-CURRENT after upgrading copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.0 release, and adding lld 3.9.0. |1200018 |link:https://svnweb.freebsd.org/changeset/base/309676[309676] @@ -1534,7 +1534,7 @@ Template: |1200023 |link:https://svnweb.freebsd.org/changeset/base/314564[314564] |March 2, 2017 -|12.0-CURRENT after upgrading our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0. +|12.0-CURRENT after upgrading copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0. |1200024 |link:https://svnweb.freebsd.org/changeset/base/314865[314865] @@ -1709,7 +1709,7 @@ Template: |1200058 |link:https://svnweb.freebsd.org/changeset/base/329166[329166] |February 12, 2018 -|12.0-CURRENT after the lua loader was committed. +|12.0-CURRENT after the Lua loader was committed. |1200059 |link:https://svnweb.freebsd.org/changeset/base/330299[330299] @@ -1794,12 +1794,12 @@ Template: |1200075 |link:https://svnweb.freebsd.org/changeset/base/336538[336538] |July 19, 2018 -|12.0-CURRENT after zfsloader being folded into loader, and after adding ntpd:ntpd as uid:gid 123:123, and after removing arm big-endian support (MACHINE_ARCH=armeb). +|12.0-CURRENT after `zfsloader` being folded into loader, and after adding ntpd:ntpd as uid:gid 123:123, and after removing arm big-endian support (MACHINE_ARCH=armeb). |1200076 |link:https://svnweb.freebsd.org/changeset/base/336914[336914] |July 30, 2018 -|12.0-CURRENT after KPI changes to timespecadd. +|12.0-CURRENT after KPI changes to `timespecadd`. |1200077 |link:https://svnweb.freebsd.org/changeset/base/337576[337576] @@ -1868,7 +1868,7 @@ Template: |1200503 |link:https://svnweb.freebsd.org/changeset/base/344152[344152] -|Febrary 15, 2019 +|February 15, 2019 |12-STABLE after merge of fixing man:renameat[2] for CAPABILITIES kernels. |1200504 @@ -1894,7 +1894,7 @@ Template: |1200508 |link:https://svnweb.freebsd.org/changeset/base/346784[346784] |April 27, 2019 -|12-STABLE after ether_gen_addr availability. +|12-STABLE after `ether_gen_addr` availability. |1200509 |link:https://svnweb.freebsd.org/changeset/base/347790[347790] @@ -1909,7 +1909,7 @@ Template: |1200511 |link:https://svnweb.freebsd.org/changeset/base/348243[348243] |May 24, 2019 -|12-STABLE after MFC of link:https://svnweb.freebsd.org/changeset/base/347843[347843]: adding group_leader member to struct task_struct to the LinuxKPI. +|12-STABLE after MFC of link:https://svnweb.freebsd.org/changeset/base/347843[347843]: adding `group_leader` member to struct `task_struct` to the LinuxKPI. |1200512 |link:https://svnweb.freebsd.org/changeset/base/348245[348245] @@ -1969,7 +1969,7 @@ Template: |1201502 |link:https://svnweb.freebsd.org/changeset/base/354613[354613] |November 11, 2019 -|12-STABLE after enabling device class group attributes in the LinuxKPI. +|12-STABLE after enabling device class group attributes in the LinuxKPI. |1201503 |link:https://svnweb.freebsd.org/changeset/base/354928[354928] @@ -1984,7 +1984,7 @@ Template: |1201505 |link:https://svnweb.freebsd.org/changeset/base/355899[355899] |December 19, 2019 -|12-STABLE after adding sigsetop extensions commonly found in musl libc and glibc. +|12-STABLE after adding `sigsetop` extensions commonly found in musl libc and glibc. |1201506 |link:https://svnweb.freebsd.org/changeset/base/355968[355968] @@ -2084,7 +2084,7 @@ Template: |1201525 |link:https://svnweb.freebsd.org/changeset/base/365471[365471] |September 8, 2020 -|12-STABLE after adding atomic and bswap functions to libcompiler_rt. +|12-STABLE after adding atomic and `bswap` functions to libcompiler_rt. |1201526 |link:https://svnweb.freebsd.org/changeset/base/365608[365608] @@ -2149,7 +2149,7 @@ Template: |1203501 |gitref:b148c7b87148b653fdbef9c5aa591b9abcd99e26[repository="src",length=12] |December 22, 2021 -|12-STABLE after adding atomic and bswap functions to libcompiler_rt. +|12-STABLE after adding atomic and `bswap` functions to libcompiler_rt. |1203502 |gitref:4772e4135cb3fe7f25531894f3b02f35ec086bda[repository="src",length=12] @@ -2272,7 +2272,7 @@ Template: |1100011 |link:https://svnweb.freebsd.org/changeset/base/263102[263102] |March 13, 2014 -|11.0-CURRENT after ABI change in struct if_data. +|11.0-CURRENT after ABI change in struct `if_data`. |1100012 |link:https://svnweb.freebsd.org/changeset/base/263140[263140] @@ -2317,7 +2317,7 @@ Template: |1100020 |link:https://svnweb.freebsd.org/changeset/base/265215[265215] |May 1, 2014 -|11.0-CURRENT after removing lindev in favor of having /dev/full by default (rev link:https://svnweb.freebsd.org/changeset/base/265212[265212]). +|11.0-CURRENT after removing `lindev` in favor of having /dev/full by default (rev link:https://svnweb.freebsd.org/changeset/base/265212[265212]). |1100021 |link:https://svnweb.freebsd.org/changeset/base/266151[266151] @@ -2437,7 +2437,7 @@ Template: |1100044 |link:https://svnweb.freebsd.org/changeset/base/274116[274116] |November 4, 2014 -|11.0-CURRENT after adding new libraries/utilities (dpv and figpar) for data throughput visualization. +|11.0-CURRENT after adding new libraries/utilities (`dpv` and `figpar`) for data throughput visualization. |1100045 |link:https://svnweb.freebsd.org/changeset/base/274162[274162] @@ -2502,7 +2502,7 @@ Template: |1100057 |link:https://svnweb.freebsd.org/changeset/base/277897[277897] |January 29, 2015 -|11.0-CURRENT after removal of d_thread_t. +|11.0-CURRENT after removal of `d_thread_t`. |1100058 |link:https://svnweb.freebsd.org/changeset/base/278228[278228] @@ -2622,7 +2622,7 @@ Template: |1100081 |link:https://svnweb.freebsd.org/changeset/base/289415[289415] |October 16, 2015 -|11.0-CURRENT after undating ZFS to support resumable send/receive (rev link:https://svnweb.freebsd.org/changeset/base/289362[289362]). +|11.0-CURRENT after `undating` ZFS to support resumable send/receive (rev link:https://svnweb.freebsd.org/changeset/base/289362[289362]). |1100082 |link:https://svnweb.freebsd.org/changeset/base/289594[289594] @@ -2677,7 +2677,7 @@ Template: |1100092 |link:https://svnweb.freebsd.org/changeset/base/292499[292499] |December 19, 2015 -|11.0-CURRENT after removal of vm_pageout_grow_cache (rev link:https://svnweb.freebsd.org/changeset/base/292469[292469]). +|11.0-CURRENT after removal of `vm_pageout_grow_cache` (rev link:https://svnweb.freebsd.org/changeset/base/292469[292469]). |1100093 |link:https://svnweb.freebsd.org/changeset/base/292966[292966] @@ -2707,7 +2707,7 @@ Template: |1100098 |link:https://svnweb.freebsd.org/changeset/base/295682[295682] |February 16, 2016 -|11.0-CURRENT after API change to rman (rev link:https://svnweb.freebsd.org/changeset/base/294883[294883]). +|11.0-CURRENT after API change to `rman` (rev link:https://svnweb.freebsd.org/changeset/base/294883[294883]). |1100099 |link:https://svnweb.freebsd.org/changeset/base/295739[295739] @@ -2722,7 +2722,7 @@ Template: |1100101 |link:https://svnweb.freebsd.org/changeset/base/296417[296417] |March 5, 2016 -|11.0-CURRENT after upgrading our copies of clang, llvm, lldb and compiler-rt to 3.8.0 release. +|11.0-CURRENT after upgrading copies of clang, llvm, lldb and compiler-rt to 3.8.0 release. |1100102 |link:https://svnweb.freebsd.org/changeset/base/296749[296749] @@ -2732,17 +2732,17 @@ Template: |1100103 |link:https://svnweb.freebsd.org/changeset/base/297000[297000] |March 18, 2016 -|11.0-CURRENT after using uintmax_t for rman ranges. +|11.0-CURRENT after using `uintmax_t` for `rman` ranges. |1100104 |link:https://svnweb.freebsd.org/changeset/base/297156[297156] |March 21, 2016 -|11.0-CURRENT after tracking filemon usage via a proc.p_filemon pointer rather than its own lists. +|11.0-CURRENT after tracking `filemon` usage via a proc.p_filemon pointer rather than its own lists. |1100105 |link:https://svnweb.freebsd.org/changeset/base/297602[297602] |April 6, 2016 -|11.0-CURRENT after fixing sed functions `i` and `a` from discarding leading white space. +|11.0-CURRENT after fixing sed functions `i` and `a` from discarding leading space. |1100106 |link:https://svnweb.freebsd.org/changeset/base/298486[298486] @@ -2752,7 +2752,7 @@ Template: |1100107 |link:https://svnweb.freebsd.org/changeset/base/299090[299090] |May 4, 2016 -|11.0-CURRENT after improving performance and functionality of the man:bitstring[3] api. +|11.0-CURRENT after improving performance and functionality of the man:bitstring[3] API. |1100108 |link:https://svnweb.freebsd.org/changeset/base/299530[299530] @@ -2772,12 +2772,12 @@ Template: |1100111 |link:https://svnweb.freebsd.org/changeset/base/300303[300303] |May 20, 2016 -|11.0-CURRENT after removing brk and sbrk from arm64. +|11.0-CURRENT after removing `brk` and `sbrk` from arm64. |1100112 |link:https://svnweb.freebsd.org/changeset/base/300539[300539] |May 23, 2016 -|11.0-CURRENT after adding bit_count to the man:bitstring[3] API. +|11.0-CURRENT after adding `bit_count` to the man:bitstring[3] API. |1100113 |link:https://svnweb.freebsd.org/changeset/base/300701[300701] @@ -2812,7 +2812,7 @@ Template: |1100119 |link:https://svnweb.freebsd.org/changeset/base/302150[302150] |June 23, 2016 -|11.0-CURRENT after switching geom_disk to using a pool mutex. +|11.0-CURRENT after switching `geom_disk` to using a pool mutex. |1100120 |link:https://svnweb.freebsd.org/changeset/base/302153[302153] @@ -2832,7 +2832,7 @@ Template: |1100501 |link:https://svnweb.freebsd.org/changeset/base/304609[304609] |August 22, 2016 -|11.0-STABLE after adding C++11 thread_local support. +|11.0-STABLE after adding C++11 `thread_local` support. |1100502 |link:https://svnweb.freebsd.org/changeset/base/304865[304865] @@ -2857,7 +2857,7 @@ Template: |1100506 |link:https://svnweb.freebsd.org/changeset/base/308048[308048] |October 28, 2016 -|11.0-STABLE after installing header files required development with libzfs_core. +|11.0-STABLE after installing header files required development with `libzfs_core`. |1100507 |link:https://svnweb.freebsd.org/changeset/base/310120[310120] @@ -2867,7 +2867,7 @@ Template: |1100508 |link:https://svnweb.freebsd.org/changeset/base/310618[310618] |December 26, 2016 -|11.0-STABLE after upgrading our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.1 release, and adding lld 3.9.1. +|11.0-STABLE after upgrading copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.1 release, and adding lld 3.9.1. |1100509 |link:https://svnweb.freebsd.org/changeset/base/311186[311186] @@ -2972,7 +2972,7 @@ Template: |1101512 |link:https://svnweb.freebsd.org/changeset/base/331219[331219] |March 19, 2018 -|11-STABLE after merging retpoline support from the upstream llvm, clang and lld 5.0 branches. +|11-STABLE after merging `retpoline` support from the upstream llvm, clang and lld 5.0 branches. |1101513 |link:https://svnweb.freebsd.org/changeset/base/331838[331838] @@ -2982,12 +2982,12 @@ Template: |1101514 |link:https://svnweb.freebsd.org/changeset/base/332089[332089] |April 5, 2018 -|11-STABLE after merging link:https://svnweb.freebsd.org/changeset/base/328331[328331], adding a new and incompatible interpretation of ${name}_limits in rc scripts. +|11-STABLE after merging link:https://svnweb.freebsd.org/changeset/base/328331[328331], adding a new and incompatible interpretation of `${name}_limits` in rc scripts. |1101515 |link:https://svnweb.freebsd.org/changeset/base/332363[332363] |April 10, 2018 -|11-STABLE after reverting link:https://svnweb.freebsd.org/changeset/base/331880[331880], removing the new and incompatible interpretation of ${name}_limits in rc scripts. +|11-STABLE after reverting link:https://svnweb.freebsd.org/changeset/base/331880[331880], removing the new and incompatible interpretation of `${name}_limits` in rc scripts. |1101516 |link:https://svnweb.freebsd.org/changeset/base/334392[334392] @@ -3042,7 +3042,7 @@ Template: |1102508 |link:https://svnweb.freebsd.org/changeset/base/346784[346784] |April 27, 2019 -|11-STABLE after ether_gen_addr availability. +|11-STABLE after `ether_gen_addr` availability. |1102509 |link:https://svnweb.freebsd.org/changeset/base/347212[347212] @@ -3082,12 +3082,12 @@ Template: |1103504 |link:https://svnweb.freebsd.org/changeset/base/354616[354616] |November 11, 2019 -|11-STABLE after enabling device class group attributes in the LinuxKPI. +|11-STABLE after enabling device class group attributes in the LinuxKPI. |1103505 |link:https://svnweb.freebsd.org/changeset/base/355899[355899] |December 19, 2019 -|11-STABLE after adding sigsetop extensions commonly found in musl libc and glibc. +|11-STABLE after adding `sigsetop` extensions commonly found in musl libc and glibc. |1103506 |link:https://svnweb.freebsd.org/changeset/base/356395[356395] @@ -3162,7 +3162,7 @@ Template: |1104506 |link:https://svnweb.freebsd.org/changeset/base/365471[365471] |September 8, 2020 -|11-STABLE after adding atomic and bswap functions to libcompiler_rt. +|11-STABLE after adding atomic and `bswap` functions to libcompiler_rt. |1104507 |link:https://svnweb.freebsd.org/changeset/base/365661[365661] @@ -3215,7 +3215,7 @@ Template: |1000003 |link:https://svnweb.freebsd.org/changeset/base/228571[228571] |December 16, 2011 -|10-CURRENT after major changes to man:carp[4], changing size of struct in_aliasreq, struct in6_aliasreq (rev link:https://svnweb.freebsd.org/changeset/base/228571[228571]) and straitening arguments check of SIOCAIFADDR (rev link:https://svnweb.freebsd.org/changeset/base/228574[228574]). +|10-CURRENT after major changes to man:carp[4], changing size of struct `in_aliasreq`, struct in6_aliasreq (rev link:https://svnweb.freebsd.org/changeset/base/228571[228571]) and straitening arguments check of SIOCAIFADDR (rev link:https://svnweb.freebsd.org/changeset/base/228574[228574]). |1000004 |link:https://svnweb.freebsd.org/changeset/base/229204[229204] @@ -3250,7 +3250,7 @@ Template: |1000010 |link:https://svnweb.freebsd.org/changeset/base/233757[233757] |March 31, 2012 -|10-CURRENT after xlocale cleanup. +|10-CURRENT after `xlocale` cleanup. |1000011 |link:https://svnweb.freebsd.org/changeset/base/234355[234355] @@ -3265,7 +3265,7 @@ Template: |1000013 |link:https://svnweb.freebsd.org/changeset/base/235788[235788] |May 22, 2012 -|10-CURRENT after byacc import. +|10-CURRENT after `byacc` import. |1000014 |link:https://svnweb.freebsd.org/changeset/base/237631[237631] @@ -3305,7 +3305,7 @@ Template: |1000020 |link:https://svnweb.freebsd.org/changeset/base/241610[241610] |October 16, 2012 -|10-CURRENT after the network interface cloning KPI changed and struct if_clone becoming opaque. +|10-CURRENT after the network interface cloning KPI changed and struct `if_clone` becoming opaque. |1000021 |link:https://svnweb.freebsd.org/changeset/base/241897[241897] @@ -3360,7 +3360,7 @@ Template: |1000031 |link:https://svnweb.freebsd.org/changeset/base/249943[249943] |April 26, 2013 -|10-CURRENT after the dst parameter of the ifnet `if_output` method was changed to take const qualifier (rev link:https://svnweb.freebsd.org/changeset/base/249925[249925]). +|10-CURRENT after the `dst` parameter of the ifnet `if_output` method was changed to take const qualifier (rev link:https://svnweb.freebsd.org/changeset/base/249925[249925]). |1000032 |link:https://svnweb.freebsd.org/changeset/base/250163[250163] @@ -3405,7 +3405,7 @@ Template: |1000040 |link:https://svnweb.freebsd.org/changeset/base/253638[253638] |July 24, 2013 -|10-CURRENT after addition of libusb pkgconf files. +|10-CURRENT after addition of libusb `pkgconf` files. |1000041 |link:https://svnweb.freebsd.org/changeset/base/253970[253970] @@ -3640,7 +3640,7 @@ Template: |1001507 |link:https://svnweb.freebsd.org/changeset/base/277790[277790] |January 27, 2015 -|10-STABLE after changes to the UDP tunneling callback to provide a context pointer and the source sockaddr. +|10-STABLE after changes to the UDP tunneling callback to provide a context pointer and the source `sockaddr`. |1001508 |link:https://svnweb.freebsd.org/changeset/base/278974[278974] @@ -3650,7 +3650,9 @@ Template: |1001509 |link:https://svnweb.freebsd.org/changeset/base/279287[279287] |February 25, 2015 +pass:[] |10-STABLE after FreeBSD-EN-15:01.vt, FreeBSD-EN-15:02.openssl, FreeBSD-EN-15:03.freebsd-update, FreeBSD-SA-15:04.igmp, and FreeBSD-SA-15:05.bind. +pass:[] |1001510 |link:https://svnweb.freebsd.org/changeset/base/279329[279329] @@ -3715,7 +3717,7 @@ Template: |1002501 |link:https://svnweb.freebsd.org/changeset/base/289005[289005] |October 8, 2015 -|10-STABLE after merge of ZFS changes that affected the internal interface of zfeature_info structure (rev link:https://svnweb.freebsd.org/changeset/base/288572[288572]). +|10-STABLE after merge of ZFS changes that affected the internal interface of `zfeature_info` structure (rev link:https://svnweb.freebsd.org/changeset/base/288572[288572]). |1002502 |link:https://svnweb.freebsd.org/changeset/base/291243[291243] @@ -3770,7 +3772,7 @@ Template: |1003501 |link:https://svnweb.freebsd.org/changeset/base/298299[298299] |June 19, 2016 -|10-STABLE after adding kdbcontrol's -P option (rev link:https://svnweb.freebsd.org/changeset/base/298297[298297]). +|10-STABLE after adding -P option for `kdbcontrol` (rev link:https://svnweb.freebsd.org/changeset/base/298297[298297]). |1003502 |link:https://svnweb.freebsd.org/changeset/base/299966[299966] @@ -3780,12 +3782,12 @@ Template: |1003503 |link:https://svnweb.freebsd.org/changeset/base/300235[300235] |June 19, 2016 -|10-STABLE after allowing MK_ overrides (rev link:https://svnweb.freebsd.org/changeset/base/300233[300233]). +|10-STABLE after allowing `MK_` overrides (rev link:https://svnweb.freebsd.org/changeset/base/300233[300233]). |1003504 |link:https://svnweb.freebsd.org/changeset/base/302066[302066] |June 21, 2016 -|10-STABLE after MFC of filemon changes from 11-CURRENT. +|10-STABLE after MFC of `filemon` changes from 11-CURRENT. |1003505 |link:https://svnweb.freebsd.org/changeset/base/302228[302228] @@ -3795,7 +3797,7 @@ Template: |1003506 |link:https://svnweb.freebsd.org/changeset/base/304611[304611] |August 22, 2016 -|10-STABLE after adding C++11 thread_local support. +|10-STABLE after adding C++11 `thread_local` support. |1003507 |link:https://svnweb.freebsd.org/changeset/base/304864[304864] @@ -3898,12 +3900,12 @@ Template: |900002 |link:https://svnweb.freebsd.org/changeset/base/197430[197430] |September 23, 2009 -|9.0-CURRENT after implementing the EVFILT_USER kevent filter functionality. +|9.0-CURRENT after implementing the EVFILT_USER `kevent` filter functionality. |900003 |link:https://svnweb.freebsd.org/changeset/base/200039[200039] |December 2, 2009 -|9.0-CURRENT after addition of man:sigpause[2] and PIE support in csu. +|9.0-CURRENT after addition of man:sigpause[2] and PIE support in `csu`. |900004 |link:https://svnweb.freebsd.org/changeset/base/200185[200185] @@ -3923,7 +3925,7 @@ Template: |900007 |link:https://svnweb.freebsd.org/changeset/base/202219[202219] |January 13, 2010 -|9.0-CURRENT after the removal of man:utmp[5] and the addition of utmpx (see man:getutxent[3]) for improved logging of user logins and system events. +|9.0-CURRENT after the removal of man:utmp[5] and the addition of `utmpx` (see man:getutxent[3]) for improved logging of user logins and system events. |900008 |link:https://svnweb.freebsd.org/changeset/base/202722[202722] @@ -3943,7 +3945,7 @@ Template: |900011 |link:https://svnweb.freebsd.org/changeset/base/207410[207410] |April 24, 2010 -|9.0-CURRENT after adding soft-updates journalling. +|9.0-CURRENT after adding soft-updates journaling. |900012 |link:https://svnweb.freebsd.org/changeset/base/207842[207842] @@ -3968,7 +3970,7 @@ Template: |900016 |link:https://svnweb.freebsd.org/changeset/base/210565[210565] |July 28, 2010 -|9.0-CURRENT after adding mti_zone to struct malloc_type_internal. +|9.0-CURRENT after adding `mti_zone` to struct `malloc_type_internal`. |900017 |link:https://svnweb.freebsd.org/changeset/base/211701[211701] @@ -3978,7 +3980,7 @@ Template: |900018 |link:https://svnweb.freebsd.org/changeset/base/211735[211735] |August 24, 2010 -|9.0-CURRENT after the man:pthread_kill[3] -generated signal is identified as SI_LWP in si_code. Previously, si_code was SI_USER. +|9.0-CURRENT after the man:pthread_kill[3] -generated signal is identified as SI_LWP in `si_code`. Previously, `si_code` was SI_USER. |900019 |link:https://svnweb.freebsd.org/changeset/base/211937[211937] @@ -3988,7 +3990,7 @@ Template: |900020 |link:https://svnweb.freebsd.org/changeset/base/212381[212381] |September 9, 2010 -|9.0-CURRENT after adding drain functionality to sbufs, which also changed the layout of struct sbuf. +|9.0-CURRENT after adding drain functionality to `sbufs`, which also changed the layout of struct `sbuf`. |900021 |link:https://svnweb.freebsd.org/changeset/base/212568[212568] @@ -4018,7 +4020,7 @@ Template: |900026 |link:https://svnweb.freebsd.org/changeset/base/216088[216088] |November 30, 2010 -|9.0-CURRENT after the introduction of Serial Management Protocol (SMP) passthrough and the XPT_SMP_IO and XPT_GDEV_ADVINFO CAM CCBs. +|9.0-CURRENT after the introduction of Serial Management Protocol (SMP) passthrough and the XPT_SMP_IO and XPT_GDEV_ADVINFO CAM `CCBs`. |900027 |link:https://svnweb.freebsd.org/changeset/base/216212[216212] @@ -4048,7 +4050,7 @@ Template: |900032 |link:https://svnweb.freebsd.org/changeset/base/218425[218425] |February 8, 2011 -|9.0-CURRENT after the removal of the uio_yield prototype and symbol. +|9.0-CURRENT after the removal of the `uio_yield` prototype and symbol. |900033 |link:https://svnweb.freebsd.org/changeset/base/218822[218822] @@ -4058,7 +4060,7 @@ Template: |900034 |link:https://svnweb.freebsd.org/changeset/base/219406[219406] |March 8, 2011 -|9.0-CURRENT after the struct sysvec (sv_schedtail) changes. +|9.0-CURRENT after the struct `sysvec` (`sv_schedtail`) changes. |900035 |link:https://svnweb.freebsd.org/changeset/base/220150[220150] @@ -4183,7 +4185,7 @@ Template: |901505 |link:https://svnweb.freebsd.org/changeset/base/251687[251687] |June 13, 2013 -|9.1-STABLE after fixes in ctfmerge bootstrapping (rev link:https://svnweb.freebsd.org/changeset/base/249243[249243]). +|9.1-STABLE after fixes in `ctfmerge` bootstrapping (rev link:https://svnweb.freebsd.org/changeset/base/249243[249243]). |902001 |link:https://svnweb.freebsd.org/changeset/base/253912[253912] @@ -4298,7 +4300,9 @@ Template: |903508 |link:https://svnweb.freebsd.org/changeset/base/279287[279287] |February 25, 2015 +pass:[] |9-STABLE after FreeBSD-EN-15:01.vt, FreeBSD-EN-15:02.openssl, FreeBSD-EN-15:03.freebsd-update, FreeBSD-SA-15:04.igmp, and FreeBSD-SA-15:05.bind. +pass:[] |903509 |link:https://svnweb.freebsd.org/changeset/base/296219[296219] @@ -4331,7 +4335,7 @@ Template: |800000 |link:https://svnweb.freebsd.org/changeset/base/172531[172531] |October 11, 2007 -|8.0-CURRENT. Separating wide and single byte ctype. +|8.0-CURRENT. Separating wide and single byte `ctype`. |800001 |link:https://svnweb.freebsd.org/changeset/base/172688[172688] @@ -4361,7 +4365,7 @@ Template: |800006 |link:https://svnweb.freebsd.org/changeset/base/174399[174399] |December 7, 2007 -|8.0-CURRENT after the addition of callgraph capture functionality to man:hwpmc[4]. +|8.0-CURRENT after the addition of `callgraph` capture functionality to man:hwpmc[4]. |800007 |link:https://svnweb.freebsd.org/changeset/base/174901[174901] @@ -4421,7 +4425,7 @@ Template: |800018 |link:https://svnweb.freebsd.org/changeset/base/176112[176112] |February 8, 2008 -|8.0-CURRENT after the addition of m_collapse. +|8.0-CURRENT after the addition of `m_collapse`. |800019 |link:https://svnweb.freebsd.org/changeset/base/176124[176124] @@ -4461,17 +4465,17 @@ Template: |800026 |link:https://svnweb.freebsd.org/changeset/base/177086[177086] |March 12, 2008 -|8.0-CURRENT after changing the priority parameter to cv_broadcastpri such that 0 means no priority. +|8.0-CURRENT after changing the priority parameter to `cv_broadcastpri` such that 0 means no priority. |800027 |link:https://svnweb.freebsd.org/changeset/base/177551[177551] |March 24, 2008 -|8.0-CURRENT after changing the bpf monitoring ABI when zerocopy bpf buffers were added. +|8.0-CURRENT after changing the bpf monitoring ABI when `zerocopy` bpf buffers were added. |800028 |link:https://svnweb.freebsd.org/changeset/base/177637[177637] |March 26, 2008 -|8.0-CURRENT after adding l_sysid to struct flock. +|8.0-CURRENT after adding `l_sysid` to struct flock. |800029 |link:https://svnweb.freebsd.org/changeset/base/177688[177688] @@ -4491,7 +4495,7 @@ Template: |800032 |link:https://svnweb.freebsd.org/changeset/base/178006[178006] |April 8, 2008 -|8.0-CURRENT after the implementation of the openat and related syscalls, introduction of the O_EXEC flag for the man:open[2], and providing the corresponding linux compatibility syscalls. +|8.0-CURRENT after the implementation of the `openat` and related syscalls, introduction of the O_EXEC flag for the man:open[2], and providing the corresponding Linux compatibility syscalls. |800033 |link:https://svnweb.freebsd.org/changeset/base/178017[178017] @@ -4511,7 +4515,7 @@ Template: |800036 |link:https://svnweb.freebsd.org/changeset/base/178362[178362] |April 20, 2008 -|8.0-CURRENT after switchover of 802.11 wireless to multi-bss support (aka vaps). +|8.0-CURRENT after switchover of 802.11 wireless to multi-bss support (aka `vaps`). |800037 |link:https://svnweb.freebsd.org/changeset/base/178892[178892] @@ -4521,17 +4525,17 @@ Template: |800038 |link:https://svnweb.freebsd.org/changeset/base/179316[179316] |May 26, 2008 -|8.0-CURRENT after removal of netatm and ISDN4BSD. Also, the addition of the Compact C Type (CTF) tools. +|8.0-CURRENT after removal of `netatm` and ISDN4BSD. Also, the addition of the Compact C Type (CTF) tools. |800039 |link:https://svnweb.freebsd.org/changeset/base/179784[179784] |June 14, 2008 -|8.0-CURRENT after removal of sgtty. +|8.0-CURRENT after removal of `sgtty`. |800040 |link:https://svnweb.freebsd.org/changeset/base/180025[180025] |June 26, 2008 -|8.0-CURRENT with kernel NFS lockd client. +|8.0-CURRENT with kernel NFS `lockd` client. |800041 |link:https://svnweb.freebsd.org/changeset/base/180691[180691] @@ -4551,7 +4555,7 @@ Template: |800044 |link:https://svnweb.freebsd.org/changeset/base/181803[181803] |August 17, 2008 -|8.0-CURRENT after the commit of the first step of the vimage project renaming global variables to be virtualized with a V_ prefix with macros to map them back to their global names. +|8.0-CURRENT after the commit of the first step of the VIMAGE project renaming global variables to be virtualized with a `V_` prefix with macros to map them back to their global names. |800045 |link:https://svnweb.freebsd.org/changeset/base/181905[181905] @@ -4571,7 +4575,7 @@ Template: |800048 |link:https://svnweb.freebsd.org/changeset/base/183091[183091] |September 16, 2008 -|8.0-CURRENT after converting the kernel NFS mount code to accept individual mount options in the man:nmount[2] iovec, not just one big struct nfs_args. +|8.0-CURRENT after converting the kernel NFS mount code to accept individual mount options in the man:nmount[2] `iovec`, not just one big struct nfs_args. *** 646 LINES SKIPPED *** From nobody Wed May 17 12:34:10 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QLswz1XpPz4B4lQ for ; Wed, 17 May 2023 12:34:11 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QLswz14q8z4KTv; Wed, 17 May 2023 12:34:11 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684326851; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=rVMJfW2S4EGikq8xDMyx6UJP4Ish1hNFOFrTYoE/6Aw=; b=JKpFTzKTYsiNHbozKs/EtA6X7VRJDk+oDSm2sVZl8aSjZAOHYUG1EpeUzIe6rtssFeS2Kb yIxqB+6lO6RO48/JEbLJt5RK7MybCoMmdAT/EWFP3bXSZi2aP62VUgRwtaSWlBsrcn4pQw h+yl/QaeBKynXQ8sj8IJ7TPfZfwBp0j/FDdv880X4PCHYHy66/pNQ0tDIE3L0d8dBMzj15 JrI26L+XxPvGkFBYyb/k0hfMnk9D3i81M0cS7js+BeZXcFrVmTo+iQMycTy2prKfxG4Rc0 m6B4zzn13Inl14YOFcw2+9Ps9Z2AP/Zz5wbelKUz2NNTC4KYsIGlslrVUm5QYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684326851; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=rVMJfW2S4EGikq8xDMyx6UJP4Ish1hNFOFrTYoE/6Aw=; b=wZzW9tZgshYbmt5cBLR5ZghK/QL6CBX0mu+qpNIJS2i1+8KCid3/Z9QCmDfbxFMovXnyVg Ymnpu7jJolQ1+aF76FoASv31PJZDjZvuars2x4C8004svShC2mSJPYmNoK1QgeCLxo38af 0cQfdGYfuBXCyQE6XzQ7D2Y12C+OP8IoJCuRGoEqGV2/7qL9jSzo3PMYq+iKvlCFPyTdTA ii67MAir0hUuUBq77oG/WAw0VJnJkyM36z34LyauPEh/qFn+loONgnSA+A1Zn7ESqy9RwA vIIuOKhjHArIfyA7dIMr+AfF89+meUApEO4Wi4bjsUv+Eq02/yh9i6Hih7PGSw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684326851; a=rsa-sha256; cv=none; b=CXqAmTLrhLqghAtjyDjggVBcPy6lH83Swbo8etRfsol5+CiTQya7aMK0XRjDNrY7ipkcjr Tot7mPL9HkfQ600Vmd+QXgoVwb83cYraMCWHuZ5F/S16MXdgTpZZ+jKVK81n1mxWaAMrAp V7Lo9PwUWqVI8AzR2iGT/ONcEcfb2IxN+Q3nWH0dK4bK/3bo/zHQfRK9/quE0n/pGLsUfl KCoZvIk3cSxtn+ITXwrXI/UM43COUtb0OrBbzV1lh9BMo5yxpXHFHGQGq/rwFUusx7B+H2 2pTTRxamdBC/VDQVqWB8a6P3brKOPI14B7ygBf1BFmMsRtj/oUBsyxnaVuv0eA== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QLswz07Tsz13xy; Wed, 17 May 2023 12:34:11 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 34HCYAm7002882; Wed, 17 May 2023 12:34:10 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 34HCYAMG002881; Wed, 17 May 2023 12:34:10 GMT (envelope-from git) Date: Wed, 17 May 2023 12:34:10 GMT Message-Id: <202305171234.34HCYAMG002881@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Muhammad Moinur Rahman Subject: git: 0c364a4706 - main - .vale/styles: Update accept.txt vocab terms List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: bofh X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 0c364a470600b8fe8a30954f3ee3b41501596a30 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by bofh: URL: https://cgit.FreeBSD.org/doc/commit/?id=0c364a470600b8fe8a30954f3ee3b41501596a30 commit 0c364a470600b8fe8a30954f3ee3b41501596a30 Author: Muhammad Moinur Rahman AuthorDate: 2023-05-17 12:32:22 +0000 Commit: Muhammad Moinur Rahman CommitDate: 2023-05-17 12:32:22 +0000 .vale/styles: Update accept.txt vocab terms - Add new terms from phb/testing - Fix binutil keyword [1] Reported by: ceri [1] --- .vale/styles/Vocab/Terms/accept.txt | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/.vale/styles/Vocab/Terms/accept.txt b/.vale/styles/Vocab/Terms/accept.txt index e9b7998ab4..db89dd2f8e 100644 --- a/.vale/styles/Vocab/Terms/accept.txt +++ b/.vale/styles/Vocab/Terms/accept.txt @@ -6,6 +6,7 @@ Adaptec Belkin Biba Broadcom +CPUs? DTDs DTrace FreeBSD @@ -28,7 +29,7 @@ Safeport Setkey USB VIMAGE -[Bn]inutil +[Bb]inutil [Cc]allouts? [Dd]atagram [Dd]eallocat(?:e|ion) @@ -38,9 +39,11 @@ VIMAGE [Jj]ourna(?:led|ling) [Kk]help [Kk]obj +[M]akefile [Mm]map [Mm]ulticast [Nn]et(?:graph|map) +[Pp]ort(?:clippy|fmt|lint) [Uu]serland [Vv]irtualiz(?:ation|es|ed|ing) [Vv]node @@ -68,6 +71,7 @@ demultiplexer dereference devclass disklabel +distfiles? dpcpu drm enums @@ -126,14 +130,18 @@ nfsd nfsserver openmp passthrough +patchlevel pcb pfil pmc +portlint portsnap powerpc powerstate procfs +plist pluggable +poudriere pkg_install readline reentrant From nobody Wed May 17 12:35:38 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QLsyq1SkKz4B4nw for ; Wed, 17 May 2023 12:35:47 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QLsyq0gp5z4KVD; Wed, 17 May 2023 12:35:47 +0000 (UTC) (envelope-from bofh@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684326947; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/qTErJl5qoPx+toEzWlaHteqO1ZB+FKatCC5udLYXcM=; b=CmFWHxJSFBUroTelDefju77xoKILt9NsKsNiepP5+Z3fJsdDEvfN1PkfOTjXJjIN9OW9f4 42+Ge4+QQQZck2fmRdu/s8oUQbYKA26Vgaptx1lB0hlaXAwzUYijanjN8M83o+AcGMxmmr AAN2a0F7ni91MB5h0J/em25Qlmv0trGmakfp4m9Z1LfqKTXLkU2ZUzgTQQX5WbWuT53BoJ ezNtzOByfyDWbmarFofFvleAO0G39GjwrKYd200GC6uginuVNeVXNz5u2cfJfP0IpPad96 5zHAvVlEaiWWXRl533Oqu1Y8UvJ/zEcZSrOJnHOhpWdSysIppOpZi5wqGfbgPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684326947; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/qTErJl5qoPx+toEzWlaHteqO1ZB+FKatCC5udLYXcM=; b=YkC6KF+niKblrU2COGNNLqUFGw0DEwOZL4j4dDfc2MrmBdnXTWojlU7EI1l+1JpOxI9O2T y0XdUEQ50ta7mKr2Nm9B7t6RVR+17cOLOa6tfOeMurHt7HjFbpJ8ZIvkqd6XoXS3v2X/UW +BK5k5Vu935CKFWTBSmSXl0M55tIyfaVJ9zauHFVNotH+JkLHKlmEcLZGaAzVniRg0Zau4 RpCyIn7emzhqgt/weYktlPLytePNXGwyZ3BNVodV2ZXCBvmbMSBkD5HcdDnOxnGl+3T+04 S8NSPImFGmyQmhR7wxClvXjW7G1f1fVNo0olF+dJdPZqeokmqSWvgLgo1uCUhw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684326947; a=rsa-sha256; cv=none; b=LEArXXTcwmrxy/af5qN25Wswe4JNS6LHgCfu1+4NAWrCBgGtTOtlZGv9FwaK4fkfGoCmly 7t4Zqop+6+EUIdzOYRY7FhLdWraoxXaVZKmUTxMXtRGHM3w9ozfKySMfPNKt6FW8ox4+oV cxfHTl0bx2wIzrmtTt3OmdmG7Zw59rRVoevTl4W0GwcgNk59BkxF8TR1omTsGVMVJSRFeH 68X5JZ7AWTW3jC9imxi/6VnABLUk9d8BSCwBynTbs26u7QvYB0et7GC6GDYellkaVyDEOZ 4/u42wSIvURIchcFxgbsB7rS7I4diF7baAa1bXypNxOe/DDgVYqncATxwSMtmg== Received: from mx.bofh.network (mx.bofh.network [5.9.249.227]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mx.bofh.network", Issuer "R3" (verified OK)) (Authenticated sender: bofh/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QLsyp4Mbszw8R; Wed, 17 May 2023 12:35:46 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from smtpclient.apple (gw.office.cyso.net [95.97.78.194]) by mx.bofh.network (OpenSMTPD) with ESMTPSA id a9be1bac (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO); Wed, 17 May 2023 12:35:39 +0000 (UTC) From: Moin Rahman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: git: 0c364a4706 - main - .vale/styles: Update accept.txt vocab terms Date: Wed, 17 May 2023 14:35:38 +0200 References: <202305171234.34HCYAMG002881@gitrepo.freebsd.org> To: "doc-committers@freebsd.org" , "dev-commits-doc-all@freebsd.org" In-Reply-To: <202305171234.34HCYAMG002881@gitrepo.freebsd.org> Message-Id: X-Mailer: Apple Mail (2.3696.120.41.1.1) X-ThisMailContainsUnwantedMimeParts: N Approved by: bcr, carlavilla (blanket) > On May 17, 2023, at 2:34 PM, Muhammad Moinur Rahman = wrote: >=20 > The branch main has been updated by bofh: >=20 > URL: = https://cgit.FreeBSD.org/doc/commit/?id=3D0c364a470600b8fe8a30954f3ee3b415= 01596a30 >=20 > commit 0c364a470600b8fe8a30954f3ee3b41501596a30 > Author: Muhammad Moinur Rahman > AuthorDate: 2023-05-17 12:32:22 +0000 > Commit: Muhammad Moinur Rahman > CommitDate: 2023-05-17 12:32:22 +0000 >=20 > .vale/styles: Update accept.txt vocab terms >=20 > - Add new terms from phb/testing > - Fix binutil keyword [1] >=20 > Reported by: ceri [1] > --- > .vale/styles/Vocab/Terms/accept.txt | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) >=20 > diff --git a/.vale/styles/Vocab/Terms/accept.txt = b/.vale/styles/Vocab/Terms/accept.txt > index e9b7998ab4..db89dd2f8e 100644 > --- a/.vale/styles/Vocab/Terms/accept.txt > +++ b/.vale/styles/Vocab/Terms/accept.txt > @@ -6,6 +6,7 @@ Adaptec > Belkin > Biba > Broadcom > +CPUs? > DTDs > DTrace > FreeBSD > @@ -28,7 +29,7 @@ Safeport > Setkey > USB > VIMAGE > -[Bn]inutil > +[Bb]inutil > [Cc]allouts? > [Dd]atagram > [Dd]eallocat(?:e|ion) > @@ -38,9 +39,11 @@ VIMAGE > [Jj]ourna(?:led|ling) > [Kk]help > [Kk]obj > +[M]akefile > [Mm]map > [Mm]ulticast > [Nn]et(?:graph|map) > +[Pp]ort(?:clippy|fmt|lint) > [Uu]serland > [Vv]irtualiz(?:ation|es|ed|ing) > [Vv]node > @@ -68,6 +71,7 @@ demultiplexer > dereference > devclass > disklabel > +distfiles? > dpcpu > drm > enums > @@ -126,14 +130,18 @@ nfsd > nfsserver > openmp > passthrough > +patchlevel > pcb > pfil > pmc > +portlint > portsnap > powerpc > powerstate > procfs > +plist > pluggable > +poudriere > pkg_install > readline > reentrant >=20 From nobody Wed May 17 13:22:47 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QLv135NZ5z4B7jW for ; Wed, 17 May 2023 13:22:47 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QLv13544hz3Gf9; Wed, 17 May 2023 13:22:47 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684329767; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=3UR5zBxj27tqmSTRTsyo9GPkCycegEHdXNeUn9TDskc=; b=uTiSSFiXETQ2hXDHXyr9sIz/eJvFHY7qT3Q18VF+L2z63sC0Ny29fhzte1QUO7u7X72vzT hUmsNhw4ueFkpwTAwtYRLOQMn2L1jSBW5+Aw8MTTVN+nzleBs7U3omyYTbDcgPInwKH4Tf ynRnmX8OQb3gMD4Q/uFpzae4PG/TBHGxTcbughe6haWW9JX6TBZEfinI8x5/ek9/f83Gdg qZ/CKz+vsBKAVoItkaXXkD+LQWwAFCFOvnSu10AxiyLN9kZYWL2Jj6ILOzq4wmrXJ670qy 9CXFwlr/+Qu6CGnIofYoUP6HBNo/zgZsxmwn7F9J6smPXzbs8n6A2n9W8OyG9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684329767; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=3UR5zBxj27tqmSTRTsyo9GPkCycegEHdXNeUn9TDskc=; b=EAZ0UA0+PGF+4SvsLDwOyVyrhkxm6GVEKImt7MmnD8An1shOVItNEtRRL5FNODnvot42rV 3pUO+664MkpPQBm19MH7IJrd4QTLCOMtijdztff4ll7dPlYfLz+UjwmYwzenE+IBYKEIbM +t64jd+Qx/WwUnKnEdt0AkH756W8Xuew5Rhl/VEcpgnjeSX7QPsM4ienJTkT32/WRPYwmY TO9A2cmhYEzRKTqv74oAlRlsxUQBno7vI0C0TYVa1DD4Sv705R1zqf5Rq5zDKDTZV6yOcd jhA3f1q36QlQgoK3nzLzBvPJosL0A8XeTQbXAefHAzwa+up8O3xoub1KpJnyzw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684329767; a=rsa-sha256; cv=none; b=lbE5hlQmSudCy71nG1y3wV+WJh6x2XjCI9lh9UiaeQxD96gtUu/DPiP1pbK7xFGT55t98L AmeTusBz3x5BtaNIcgLBckRRmkmxa06361pddTIMVLPQCGyZfzhiBdl+aZ/IoMixb8fjRZ QBpgHKLga1OFD8lgNTK2S093pcC5wK5ZW1bZL7QvjNZ3GnXy7EGwtLT5KzAl2H94SNVX2Y XUChdr6FqBsovgEA9+hPil1Hm33azVYFDkt+6uU+HuODgY/DrCjN29pxdxD8wg+akJUMf1 q+aemaOJKHifzz9Qmcppndszp3rMP7+FjX5WKAGtKBDJeP92BYGB18OD6ZWGSg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QLv1348rgz15N6; Wed, 17 May 2023 13:22:47 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 34HDMlp7085154; Wed, 17 May 2023 13:22:47 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 34HDMlam085153; Wed, 17 May 2023 13:22:47 GMT (envelope-from git) Date: Wed, 17 May 2023 13:22:47 GMT Message-Id: <202305171322.34HDMlam085153@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Muhammad Moinur Rahman Subject: git: 6e36b30773 - main - porters-handbook/testing: Pet vale List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: bofh X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 6e36b3077332facc9d6391d1c30e00db7d227641 Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by bofh: URL: https://cgit.FreeBSD.org/doc/commit/?id=6e36b3077332facc9d6391d1c30e00db7d227641 commit 6e36b3077332facc9d6391d1c30e00db7d227641 Author: Muhammad Moinur Rahman AuthorDate: 2023-05-17 13:20:33 +0000 Commit: Muhammad Moinur Rahman CommitDate: 2023-05-17 13:20:33 +0000 porters-handbook/testing: Pet vale - Remove repocopy/repocopied as this concept no longer exists after git migration - Fix semantic line breaks - Use the term poudriere as oposed to Poudriere recommended by the authors of poudriere - Remove optional configuration snippets like ZROOTFS/FREEBSD_HOST/SVN_HOST from poudriere.conf config file - Remove references to SVN/subversion and replace with relevant git terms - Remove references to SVN/subversion CAUTION/NOTE/TIP - Remove pronouns like you/they - Replace references to EOL 12.3-STABLE with 12.4-STABLE - Remove references to older poudriere version 3.1.20 Approved by: portmgr bcr(mentor) Differential Revision: https://reviews.freebsd.org/D40134 --- .../en/books/porters-handbook/testing/_index.adoc | 165 +++++++-------------- 1 file changed, 56 insertions(+), 109 deletions(-) diff --git a/documentation/content/en/books/porters-handbook/testing/_index.adoc b/documentation/content/en/books/porters-handbook/testing/_index.adoc index c23c29766c..c317d99221 100644 --- a/documentation/content/en/books/porters-handbook/testing/_index.adoc +++ b/documentation/content/en/books/porters-handbook/testing/_index.adoc @@ -79,11 +79,13 @@ Portfmt is a tool for automatically formatting [.filename]#Makefile#. Do check the port with crossref:quick-porting[porting-portlint,`portlint`] before submitting or committing it. `portlint` warns about many common errors, both functional and stylistic. -For a new (or repocopied) port, `portlint -A` is the most thorough; for an existing port, `portlint -C` is sufficient. +For a new port, `portlint -A` is the most thorough; for an existing port, `portlint -C` is sufficient. Since `portlint` uses heuristics to try to figure out errors, it can produce false positive warnings. In addition, occasionally something that is flagged as a problem really cannot be done in any other way due to limitations in the ports framework. +pass:[] When in doubt, the best thing to do is ask on {freebsd-ports}. +pass:[] [[testing-porttools]] == Port Tools @@ -92,7 +94,8 @@ The package:ports-mgmt/porttools[] program is part of the Ports Collection. `port` is the front-end script, which can help simplify the testing job. Whenever a new port or an update to an existing one needs testing, use `port test` to test the port, including the <> checking. -This command also detects and lists any files that are not listed in [.filename]#pkg-plist#. For example: +This command also detects and lists any files that are not listed in [.filename]#pkg-plist#. +For example: [source,shell] .... @@ -139,7 +142,7 @@ In addition, it is worth checking the same with the stage directory support (see * `stage-qa` checks for common problems like bad shebang, symlinks pointing outside the stage directory, setuid files, and non-stripped libraries... These tests will not find hard-coded paths inside the port's files, nor will it verify that `LOCALBASE` is being used to correctly refer to files from other ports. -The temporarily-installed port in [.filename]#/var/tmp/`make -V PORTNAME`# must be tested for proper operation to make sure there are no problems with paths. +The temporarily installed port in [.filename]#/var/tmp/`make -V PORTNAME`# must be tested for proper operation to make sure there are no problems with paths. `PREFIX` must not be set explicitly in a port's [.filename]#Makefile#. Users installing the port may have set `PREFIX` to a custom location, and the port must respect that setting. @@ -163,9 +166,9 @@ See <> for more information. ==== [[testing-poudriere]] -== Poudriere +== poudriere -For a ports contributor, Poudriere is one of the most important and helpful testing and build tools. +For a ports contributor, poudriere is one of the most important and helpful testing and build tools. Its main features include: * Bulk building of the entire ports tree, specific subsets of the ports tree, or a single port including its dependencies @@ -175,15 +178,15 @@ Its main features include: * Testing of port builds before submitting a patch to the FreeBSD bug tracker or committing to the ports tree * Testing for successful ports builds using different options -Because Poudriere performs its building in a clean man:jail[8] environment and uses man:zfs[8] features, +Because poudriere performs its building in a clean man:jail[8] environment and uses man:zfs[8] features, it has several advantages over traditional testing on the host system: * No pollution of the host environment: No leftover files, no accidental removals, no changes of existing configuration files. * Verify [.filename]#pkg-plist# for missing or superfluous entries -* Ports committers sometimes ask for a Poudriere log alongside a patch submission to assess whether the patch is ready for integration into the ports tree +* Ports committers sometimes ask for a poudriere log alongside a patch submission to assess whether the patch is ready for integration into the ports tree It is also quite straightforward to set up and use, has no dependencies, and will run on any supported FreeBSD release. -This section shows how to install, configure, and run Poudriere as part of the normal workflow of a ports contributor. +This section shows how to install, configure, and run poudriere as part of the normal workflow of a ports contributor. The examples in this section show a default file layout, as standard in FreeBSD. Substitute any local changes accordingly. @@ -191,9 +194,9 @@ The ports tree, represented by `${PORTSDIR}`, is located in [.filename]#/usr/por Both `${LOCALBASE}` and `${PREFIX}` are [.filename]#/usr/local# by default. [[testing-poudriere-installing]] -=== Installing Poudriere +=== Installing poudriere -Poudriere is available in the ports tree in package:ports-mgmt/poudriere[]. +poudriere is available in the ports tree in package:ports-mgmt/poudriere[]. It can be installed using man:pkg[8] or from ports: [source,shell] @@ -208,7 +211,7 @@ or # make -C /usr/ports/ports-mgmt/poudriere install clean .... -There is also a work-in-progress version of Poudriere which will eventually become the next release. +There is also a work-in-progress version of poudriere which will eventually become the next release. It is available in package:ports-mgmt/poudriere-devel[]. This development version is used for the official FreeBSD package builds, so it is well tested. It often has newer interesting features. @@ -219,7 +222,7 @@ in a way that will shorten a full build from 18 hours to 17 hours when using a h Those optimizations will not matter a lot when building ports on a desktop machine. [[testing-poudriere-setup]] -=== Setting Up Poudriere +=== Setting Up poudriere The port installs a default configuration file, [.filename]#/usr/local/etc/poudriere.conf#. Each parameter is documented in the configuration file and in man:poudriere[8]. @@ -228,31 +231,24 @@ Here is a minimal example config file: [.programlisting] .... ZPOOL=tank -ZROOTFS=/poudriere BASEFS=/poudriere DISTFILES_CACHE=/usr/ports/distfiles RESOLV_CONF=/etc/resolv.conf -FREEBSD_HOST=ftp://ftp.freebsd.org -SVN_HOST=svn.FreeBSD.org .... `ZPOOL`:: -The name of the ZFS storage pool which Poudriere shall use. +The name of the ZFS storage pool which poudriere shall use. Must be listed in the output of `zpool status`. -`ZROOTFS`:: -The root of Poudriere-managed file systems. -This entry will cause Poudriere to create man:zfs[8] file systems under `tank/poudriere`. - `BASEFS`:: -The root mount point for Poudriere file systems. -This entry will cause Poudriere to mount `tank/poudriere` to `/poudriere`. +The root mount point for poudriere file systems. +This entry will cause poudriere to mount `tank/poudriere` to `/poudriere`. `DISTFILES_CACHE`:: Defines where distfiles are stored. -In this example, Poudriere and the host share the distfiles storage directory. +In this example, poudriere and the host share the distfiles storage directory. This avoids downloading tarballs which are already present on the system. -Please create this directory if it does not already exist so that Poudriere can find it. +Please create this directory if it does not already exist so that poudriere can find it. `RESOLV_CONF`:: Use the host [.filename]#/etc/resolv.conf# inside jails for DNS. @@ -260,19 +256,10 @@ This is needed so jails can resolve the URLs of distfiles when downloading. It is not needed when using a proxy. Refer to the default configuration file for proxy configuration. -`FREEBSD_HOST`:: -The FTP/HTTP server to use when the jails are installed from FreeBSD releases and updated with man:freebsd-update[8]. -Choose a server location which is close, for example if the machine is located in Australia, use `ftp.au.freebsd.org`. - -`SVN_HOST`:: -The server from where jails are installed and updated when using Subversion. -Again, choose a nearby location. -A list of official Subversion mirrors can be found in the extref:{handbook}[FreeBSD Handbook Subversion section, svn-mirrors]. - [[testing-poudriere-create-jails]] -=== Creating Poudriere Jails +=== Creating poudriere Jails -Create the base jails which Poudriere will use for building: +Create the base jails which poudriere will use for building: [source,shell] .... @@ -289,21 +276,9 @@ mount it on [.filename]#/poudriere/jails/131Ramd64# and extract the `13.1-RELEAS .... Create `tank/poudriere/jails/12i386`, mount it on [.filename]#/poudriere/jails/12i386#, -then check out the tip of the Subversion branch of `FreeBSD-12-STABLE` from `SVN_HOST` in [.filename]#poudriere.conf# into [.filename]#/poudriere/jails/12i386/usr/src#, +then check out the tip of the Git branch of `FreeBSD-12-STABLE` from `GIT_HOST` in [.filename]#poudriere.conf# or the default `git.freebsd.org` into [.filename]#/poudriere/jails/12i386/usr/src#, then complete a `buildworld` and install it into [.filename]#/poudriere/jails/12i386#. -[TIP] -==== -If a specific Subversion revision is needed, append it to the version string. -For example: - -[source,shell] -.... -# poudriere jail -c -j 12i386 -v stable/12@123456 -a i386 -m git+https -.... - -==== - [NOTE] ==== While it is possible to build a newer version of FreeBSD on an older version, most of the time it will not run. @@ -313,38 +288,30 @@ Running `13.1-RELEASE` is not enough. [NOTE] ==== -To create a Poudriere jail for `14.0-CURRENT`: +To create a poudriere jail for `14.0-CURRENT`: [source,shell] .... # poudriere jail -c -j 14amd64 -v main -a amd64 -m git+https .... -In order to run a `14.0-CURRENT` Poudriere jail you must be running `14.0-CURRENT`. +In order to run a `14.0-CURRENT` poudriere jail the host must be running `14.0-CURRENT`. In general, newer kernels can build and run older jails. -For instance, a `14.0-CURRENT` kernel can build and run a `12.3-STABLE`. -Poudriere jail if the `COMPAT_FREEBSD12` kernel option was compiled in (on by default in `14.0-CURRENT`[.filename]#GENERIC# kernel config). +For instance, a `14.0-CURRENT` kernel can build and run a `12.4-STABLE` if the `COMPAT_FREEBSD12` kernel option was compiled in (on by default in `14.0-CURRENT`[.filename]#GENERIC# kernel config). ==== -[CAUTION] -==== -The default `svn` protocol works but is not very secure. -Using `svn+https` along with verifying the remote server's SSL fingerprint is advised. -It will ensure that the files used for building the jail are from a trusted source. -==== - -A list of jails currently known to Poudriere can be shown with `poudriere jail -l`: +A list of jails currently known to poudriere can be shown with `poudriere jail -l`: [source,shell] .... # poudriere jail -l JAILNAME VERSION ARCH METHOD 131Ramd64 13.1-RELEASE amd64 ftp -12i386 12.3-STABLE i386 git+https +12i386 12.4-STABLE i386 git+https .... [[testing-poudriere-maintaining-jails]] -=== Keeping Poudriere Jails Updated +=== Keeping poudriere Jails Updated Managing updates is very straightforward. The command: @@ -355,8 +322,10 @@ The command: .... updates the specified jail to the latest version available. +pass:[] For FreeBSD releases, update to the latest patchlevel with man:freebsd-update[8]. -For FreeBSD versions built from source, update to the latest Subversion revision in the branch. +pass:[] +For FreeBSD versions built from source, update to the latest git revision in the branch. [TIP] ==== @@ -371,10 +340,10 @@ For example, if the building machine has 6 CPUs, use: ==== [[testing-poudriere-ports-tree]] -=== Setting Up Ports Trees for Use with Poudriere +=== Setting Up Ports Trees for Use with poudriere -There are multiple ways to use ports trees in Poudriere. -The most straightforward way is to have Poudriere create a default ports tree for itself, using link:{handbook}mirrors/#git[Git]: +There are multiple ways to use ports trees in poudriere. +The most straightforward way is to have poudriere create a default ports tree for itself, using link:{handbook}mirrors/#git[Git]: [source,shell] .... @@ -400,37 +369,14 @@ To use another tree, add `-p _treename_` to the commands. The best way to deal with local modifications for a ports contributor is to use link:{handbook}mirrors/#git[Git]. As with the creation of jails, it is possible to use a different method for creating the ports tree. -To add an additional ports tree for testing local modifications and ports development, -checking out the tree via Subversion (as described above) is preferable. - -[NOTE] -==== -The http and https methods need package:devel/subversion[] built with the `SERF` option enabled. -It is enabled by default. -==== - -[TIP] -==== -The `svn` method allows extra qualifiers to tell Subversion exactly how to fetch data. -This is explained in man:poudriere[8]. -For instance, `poudriere ports -c -m svn+ssh -p subversive` uses SSH for the checkout. -==== +To add an additional ports tree for testing local modifications and ports development, checking out the tree via git (as described above) is preferable. [[testing-poudriere-ports-tree-manual]] -=== Using Manually Managed Ports Trees with Poudriere +=== Using Manually Managed Ports Trees with poudriere Depending on the workflow, it can be extremely helpful to use ports trees which are maintained manually. -For instance, if there is a local copy of the ports tree in [.filename]#/work/ports#, point Poudriere to the location: - -* For Poudriere older than version 3.1.20: -+ -[source,shell] -.... -# poudriere ports -c -F -f none -M /work/ports -p development -.... +For instance, if there is a local copy of the ports tree in [.filename]#/work/ports#, point poudriere to the location: -* For Poudriere version 3.1.20 and later: -+ [source,shell] .... # poudriere ports -c -m null -M /work/ports -p development @@ -447,12 +393,12 @@ development null 2020-07-20 05:06:33 /work/ports [NOTE] ==== -The dash or `null` in the `METHOD` column means that Poudriere will not update or change this ports tree, ever. +The dash or `null` in the `METHOD` column means that poudriere will not update or change this ports tree, ever. It is completely up to the user to maintain this tree, including all local modifications that may be used for testing new ports and submitting patches. ==== [[testing-poudriere-ports-tree-updating]] -=== Keeping Poudriere Ports Trees Updated +=== Keeping poudriere Ports Trees Updated As straightforward as with jails described earlier: @@ -465,8 +411,7 @@ Will update the given _PORTSTREE_, one tree given by the output of `poudriere -l [NOTE] ==== -Ports trees without a method, see <>, cannot be updated like this. -They must be updated manually by the porter. +Ports trees without a method, see <>, cannot be updated like this and must be updated manually by the porter. ==== [[testing-poudriere-testing-ports]] @@ -493,7 +438,7 @@ For convenience, a symbolic link [.filename]#/poudriere/data/logs/bulk/131Ri386- The link points to the latest _build-time_ directory. Also in this directory is an [.filename]#index.html# for observing the build process with a web browser. -By default, Poudriere cleans up the jails and leaves log files in the directories mentioned above. +By default, poudriere cleans up the jails and leaves log files in the directories mentioned above. To ease investigation, jails can be kept running after the build by adding `-i` to `testport`: [source,shell] @@ -503,8 +448,8 @@ To ease investigation, jails can be kept running after the build by adding `-i` After the build completes, and regardless of whether it was successful, a shell is provided within the jail. The shell is used to investigate further. -Poudriere can be told to leave the jail running after the build finishes with `-I`. -Poudriere will show the command to run when the jail is no longer needed. +poudriere can be told to leave the jail running after the build finishes with `-I`. +poudriere will show the command to run when the jail is no longer needed. It is then possible to man:jexec[8] into it: [source,shell] @@ -523,7 +468,8 @@ It is then possible to man:jexec[8] into it: .... An integral part of the FreeBSD ports build infrastructure is the ability to tweak ports to personal preferences with options. -These can be tested with Poudriere as well. Adding the `-c`: +These can be tested with poudriere as well. +Adding the `-c`: [source,shell] .... @@ -547,11 +493,11 @@ For all actions involving builds, a so-called _set_ can be specified using `-z _ A set refers to a fully independent build. This allows, for instance, usage of `testport` with non-standard options for the dependent ports. -To use sets, Poudriere expects an existing directory structure similar to `PORT_DBDIR`, defaults to [.filename]#/var/db/ports# in its configuration directory. +To use sets, poudriere expects an existing directory structure similar to `PORT_DBDIR`, defaults to [.filename]#/var/db/ports# in its configuration directory. This directory is then man:nullfs[5]-mounted into the jails where the ports and their dependencies are built. Usually a suitable starting point can be obtained by recursively copying the existing `PORT_DBDIR` to [.filename]#/usr/local/etc/poudriere.d/jailname-portname-setname-options#. This is described in detail in man:poudriere[8]. -For instance, testing package:www/firefox[] in a specific set named `devset`, add the `-z devset` parameter to the testport command: +For instance, testing package:www/firefox[] in a specific set named `devset`, add the `-z devset` parameter to the `testport` command: [source,shell] .... @@ -568,7 +514,7 @@ This will look for the existence of these directories in this order: * [.filename]#/usr/local/etc/poudriere.d/131Ramd64-options# * [.filename]#/usr/local/etc/poudriere.d/options# -From this list, Poudriere man:nullfs[5]-mounts the _first existing_ directory tree into the [.filename]#/var/db/ports# directory of the build jails. +From this list, poudriere man:nullfs[5]-mounts the _first existing_ directory tree into the [.filename]#/var/db/ports# directory of the build jails. Hence, all custom options are used for all the ports during this run of `testport`. After the directory structure for a set is provided, the options for a particular port can be altered. @@ -584,24 +530,25 @@ The selected options are saved to the `devset` set. [NOTE] ==== -Poudriere is very flexible in the option configuration. -They can be set for particular jails, ports trees, and for multiple ports by one command. +poudriere is very flexible in the option configuration. +poudriere can be set for particular jails, ports trees, and for multiple ports by one command. Refer to man:poudriere[8] for details. ==== [[testing-poudriere-make-conf]] === Providing a Custom [.filename]#make.conf# File -Similar to using sets, Poudriere will also use a custom [.filename]#make.conf# if it is provided. +Similar to using sets, poudriere will also use a custom [.filename]#make.conf# if it is provided. No special command line argument is necessary. -Instead, Poudriere looks for existing files matching a name scheme derived from the command line. For instance: +Instead, poudriere looks for existing files matching a name scheme derived from the command line. +For instance: [source,shell] .... # poudriere testport -j 131Ramd64 -p development -z devset -o www/firefox .... -causes Poudriere to check for the existence of these files in this order: +causes poudriere to check for the existence of these files in this order: * [.filename]#/usr/local/etc/poudriere.d/make.conf# * [.filename]#/usr/local/etc/poudriere.d/devset-make.conf# @@ -636,7 +583,7 @@ Note the use of `+=` so that if the variable is already set in the default [.fil [[testing-poudriere-pruning-distfiles]] === Pruning no Longer Needed Distfiles -Poudriere comes with a built-in mechanism to remove outdated distfiles that are no longer used by any port of a given tree. +poudriere comes with a built-in mechanism to remove outdated distfiles that are no longer used by any port of a given tree. The command [source,shell] From nobody Thu May 18 01:02:17 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QMBX95pB7z4BpJC for ; Thu, 18 May 2023 01:02:17 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QMBX93MnBz3rFG; Thu, 18 May 2023 01:02:17 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684371737; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=xygGi6GtITijpHlzoTZRh+eKtqGfHYO5mARCvLWVvtE=; b=bbAylull3SsaYLLC47jFhPdTu4bi0Tm8EKEakLZam89vyI3C4k6rBMc1fHlanZdxSl+TZ5 7fh+n9WqzoD8rAHyADMTK1ytbg6Q0rm62z64X5rhkHEKPnagjnquvaR9uwRYd89JP/BVrL 08+5oiLWxbXCs6uKj9Up/NpXUUiIJD3l1x5D4NtdyX6Lmuv3xP9bzxiM2t7C2iMJzX+Gh3 hyP1CxWAQg+Xg3S7jn+QVtCclrE2Wg9O4/A0r8cRjo4UkZFHePEezbE5/IFryjwXfTkYhp eu02MNpgSUd7w0Vsa+tmb+mQsfKhKUSY1xWMVqipKOA8iAEGGJBKA6ofyH/wAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684371737; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=xygGi6GtITijpHlzoTZRh+eKtqGfHYO5mARCvLWVvtE=; b=hSF/9ZtlAweEf4sI6NgAQb1mmySByjoaBeNygtWAQUNipSZX4Q8FmwMOMl2eOSGK1MwTVD 9JRo2MQRXUkCLg1TC2EbB1QvrQV20OiTMCRIeF+qqfT62KMuBKGmK5tCSk2jG41Nss7yiO klr/QFeyydplXqwN+uawhQs1zTaJ+g2ygq+TtOLZ2nG7KV3MNcsLFwKtxXPW2TvepfF4jr f0gjYc14XvDfq5zOxIRnT8dKuXs++1aGWb/+P60YziK8MO9/OcmPQ7ne2hR/LW0LbNO+FM FfY6BwsTkoWYYOCKEJkDdWWtbzQoRNlvBFRqrm05XNPu23/VA24dUbYoyONMCw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684371737; a=rsa-sha256; cv=none; b=OhfZgZFgJA2JieHeXHbRfzTDYkJzS0rDJodDAfrhYK/m6pdyi+TNp5yZD4xGy66Z7wEdTp RrEQbFIRTNzfQe6oQRagL52ScI9KbsvU4l+tzNgayxgJuGgpAiLJtQHKpg4FnhrqdG8PDP tzHXo9RBzvLCyPmzrWdN2pSrUkbWZbE813bYfnYd02aDZj7nIiztVR1pyACoPNxBJkVPTj cxg+4ba6QeWQXtHJPRtr/AymAWTLgoDNyCvyXi+iuP4tgGB6uUIXRb3+YjDFWb0VGNBOM3 4IJnDzJtmdRDA0Kys1k+D299uJ/LiAMZN5DYB3R7oBPUQM0LXikLylwmF1IQYg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QMBX92TGqzR49; Thu, 18 May 2023 01:02:17 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 34I12H81035167; Thu, 18 May 2023 01:02:17 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 34I12HH8035166; Thu, 18 May 2023 01:02:17 GMT (envelope-from git) Date: Thu, 18 May 2023 01:02:17 GMT Message-Id: <202305180102.34I12HH8035166@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: "Danilo G. Baio" Subject: git: d206f52a92 - main - handbook/mirrors: Add Web Mirror information List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: dbaio X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: d206f52a928454c12d4dab920337d320765511ec Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by dbaio: URL: https://cgit.FreeBSD.org/doc/commit/?id=d206f52a928454c12d4dab920337d320765511ec commit d206f52a928454c12d4dab920337d320765511ec Author: Danilo G. Baio AuthorDate: 2023-05-16 01:25:46 +0000 Commit: Danilo G. Baio CommitDate: 2023-05-18 01:01:08 +0000 handbook/mirrors: Add Web Mirror information The FreeBSD Website and Documentation Portal are now hosted on the project's globally-distributed GeoDNS infrastructure. It provides faster access, reliability, and redundancy. https://www.FreeBSD.org/ https://docs.FreeBSD.org/ Reviewed by: lwhsu Differential Revision: https://reviews.freebsd.org/D40114 --- documentation/content/en/books/handbook/mirrors/_index.adoc | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/documentation/content/en/books/handbook/mirrors/_index.adoc b/documentation/content/en/books/handbook/mirrors/_index.adoc index c0bbef77a8..d6aad98c43 100644 --- a/documentation/content/en/books/handbook/mirrors/_index.adoc +++ b/documentation/content/en/books/handbook/mirrors/_index.adoc @@ -75,12 +75,14 @@ Official mirrors service: | **vuxml.FreeBSD.org** / **www.VuXML.org** | link:https://www.vuxml.org/[https] | FreeBSD Project VuXML web page. `pkg audit` fetches the list of vulnerabilities from this service. + +| **www.FreeBSD.org** / **docs.FreeBSD.org** +| `https` +| link:https://www.freebsd.org/[FreeBSD Web Site] and the link:https://docs.freebsd.org/[FreeBSD Documentation Portal]. |=== All official mirrors support IPv4 and IPv6. -The FreeBSD website (https://www.FreeBSD.org and https://docs.FreeBSD.org) are not hosted in the GeoDNS Infrastructure; there are ongoing studies of its implementation. - http://ftp-archive.FreeBSD.org is not in the GeoDNS Infrastructure, hosted in only one location (US). The project is looking for new locations; those willing to sponsor, please reach out to the Cluster Administrators team for more information. From nobody Thu May 18 15:53:42 2023 X-Original-To: dev-commits-doc-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QMZJk3XDYz4BjtD for ; Thu, 18 May 2023 15:53:42 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QMZJk2Kg4z4PQm; Thu, 18 May 2023 15:53:42 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684425222; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=QejiuliMnvBVq0Vfv+kDbY33+me45vDfilqCGK55wlQ=; b=L2cM9yyAWoEZALKwlJid9oohmj9/Dv74L6NEQlhxTuDyUrS4ttINJpppYjfGAqfMPeXA/u ESvWtdhcGTumKhikkth3lhrhueAKiRcuJY9jVdPnJGhIMvS79D9WY1/iWAP3yYGKqRx2h+ Sf3A14zzmGC9g3QGmAkcN1XKZXbdnuy98m/qstIDThjDY7eZHsmXtK7dNnol4e0uU4ssHh oF7qBGmOx5oYZc5ZWT3FcU9bt1ruNzEDp2p2tHI5EhqEHlsfopqOCDJ3BhsK52aOonVwaP mpgCk9OnOgeS+zvBusKCw5GgM9F39TQsa2W0aczbSMZyEyBG29sf3F+PeOUawA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684425222; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=QejiuliMnvBVq0Vfv+kDbY33+me45vDfilqCGK55wlQ=; b=GpwIHvHRGBZ6s02GbGAVSuz8Qtxe9CEBZIxY9S7TQUBVsJxp53fTFSLB1kasdO5RuWI0lt uCoXog/VL+YN+6GgmQFejHpkxdvSPKYnRkSIBcIMSMUqb9O9DX9QgCPsHmZjZaE2YWKE+F bBgD6rmfkw8EB3F151Nag8r+eem2eLIrKPKTJ58jliwLQUwk6ArNaDcTUfngDwJRe4RAKa 3n1NOyMrBPc/sPSm4Zi58etLf/n+Tr+iQrPhKJOCQCsjtNGdFtQIhvB8zCRSxnRrQjrqhJ sgrx/f8Sihdy3mmowEnSwD+/UEqVyctzfSWLJB5GBBFqeKg24E0ZKkUCwoKSOg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684425222; a=rsa-sha256; cv=none; b=gdad2nKJX2wvmrc2celuSSQRH3srKluJOnlc8t60e/9pN4C1NVIFmNJMYIta4noX2PT8iX 77Q+8stEAxMOgovPi0fvYDnYqB44/CgG6eN9hjiJsdwDQ9baEXDhUYF3W2n/4/rbqmlNtH EsyrM7bm8VZykycF0QiZurUDZQxV48ag+JQHAuCs9DoWYHDz7jZW7+BjbNkmewUy+QYLHL X6UksuXcN70xtifIMcxX8gxNiUb+fcv7O9uwGdS181DMuYj2O/lFOGn0hn+bSAy0mtBUS3 6i7R/LJfO3UUAQda6f0xC3EO4TkihfEnbyll4fxJZhURWBxE85nrefwlAoYzYg== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4QMZJk1N3zzrWJ; Thu, 18 May 2023 15:53:42 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 34IFrgDm002255; Thu, 18 May 2023 15:53:42 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 34IFrg9O002254; Thu, 18 May 2023 15:53:42 GMT (envelope-from git) Date: Thu, 18 May 2023 15:53:42 GMT Message-Id: <202305181553.34IFrg9O002254@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: Benedict Reuschling Subject: git: b2f883f5a2 - main - Remove instances of "in order to" to ease readability List-Id: Commit messages for all branches of the doc repository List-Archive: https://lists.freebsd.org/archives/dev-commits-doc-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-doc-all@freebsd.org X-BeenThere: dev-commits-doc-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: bcr X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: b2f883f5a2d9010820ec194ab709549c3303db6e Auto-Submitted: auto-generated X-ThisMailContainsUnwantedMimeParts: N The branch main has been updated by bcr: URL: https://cgit.FreeBSD.org/doc/commit/?id=b2f883f5a2d9010820ec194ab709549c3303db6e commit b2f883f5a2d9010820ec194ab709549c3303db6e Author: Benedict Reuschling AuthorDate: 2023-05-18 15:46:42 +0000 Commit: Benedict Reuschling CommitDate: 2023-05-18 15:53:26 +0000 Remove instances of "in order to" to ease readability Chapter 11 of the FreeBSD Documentation Project Primer states that language should be clear, short, and simple. This phrasing rarely helps with that and can be cut to a single "to" in pretty much all instances. --- .../en/articles/committers-guide/_index.adoc | 4 ++-- .../content/en/articles/contributing/_index.adoc | 2 +- .../content/en/articles/contributors/_index.adoc | 4 ++-- documentation/content/en/articles/cups/_index.adoc | 4 ++-- .../content/en/articles/explaining-bsd/_index.adoc | 8 ++++---- .../en/articles/filtering-bridges/_index.adoc | 16 ++++++++-------- .../content/en/articles/freebsd-releng/_index.adoc | 14 +++++++------- .../content/en/articles/ipsec-must/_index.adoc | 2 +- .../content/en/articles/license-guide/_index.adoc | 4 ++-- .../en/articles/linux-emulation/_index.adoc | 18 +++++++++--------- .../content/en/articles/rc-scripting/_index.adoc | 8 ++++---- .../content/en/articles/remote-install/_index.adoc | 10 +++++----- .../content/en/articles/vinum/_index.adoc | 14 +++++++------- .../content/en/articles/vm-design/_index.adoc | 22 +++++++++++----------- 14 files changed, 65 insertions(+), 65 deletions(-) diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc index 47d7060859..744d3e31ed 100644 --- a/documentation/content/en/articles/committers-guide/_index.adoc +++ b/documentation/content/en/articles/committers-guide/_index.adoc @@ -1876,7 +1876,7 @@ would look at the log for the vendor branch for zlib starting at 1.2.10. === Collaborating with others One of the keys to good software development on a project as large as FreeBSD is the ability to collaborate with others before you push your changes to the tree. -The FreeBSD project's Git repositories do not, yet, allow user-created branches to be pushed to the repository, and therefore if you wish to share your changes with others you must use another mechanism, such as a hosted GitLab or GitHub, in order to share changes in a user-generated branch. +The FreeBSD project's Git repositories do not, yet, allow user-created branches to be pushed to the repository, and therefore if you wish to share your changes with others you must use another mechanism, such as a hosted GitLab or GitHub, to share changes in a user-generated branch. The following instructions show how to set up a user-generated branch, based on the FreeBSD `main` branch, and push it to GitHub. @@ -3698,7 +3698,7 @@ FreeBSD committers can get a free 4-CD or DVD set at conferences from http://www https://gandi.net[Gandi] provides website hosting, cloud computing, domain registration, and X.509 certificate services. Gandi offers an E-rate discount to all FreeBSD developers. -In order to streamline the process of getting the discount first set up a Gandi account, fill in the billing information and select the currency. +To streamline the process of getting the discount first set up a Gandi account, fill in the billing information and select the currency. Then send an mail to mailto:non-profit@gandi.net[non-profit@gandi.net] using your `@freebsd.org` mail address, and indicate your Gandi handle. [[benefits-rsync]] diff --git a/documentation/content/en/articles/contributing/_index.adoc b/documentation/content/en/articles/contributing/_index.adoc index f4d6a9c657..ceefd904e5 100644 --- a/documentation/content/en/articles/contributing/_index.adoc +++ b/documentation/content/en/articles/contributing/_index.adoc @@ -332,7 +332,7 @@ An additional challenge is to keep individual ports working within the Ports Col As a maintainer, you will need to manage the following challenges: -* *New software versions and updates.* New versions and updates of existing ported software become available all the time, and these need to be incorporated into the Ports Collection in order to provide up-to-date software. +* *New software versions and updates.* New versions and updates of existing ported software become available all the time, and these need to be incorporated into the Ports Collection to provide up-to-date software. * *Changes to dependencies.* If significant changes are made to the dependencies of your port, it may need to be updated so that it will continue to work correctly. diff --git a/documentation/content/en/articles/contributors/_index.adoc b/documentation/content/en/articles/contributors/_index.adoc index 55230b53dc..41516b19fc 100644 --- a/documentation/content/en/articles/contributors/_index.adoc +++ b/documentation/content/en/articles/contributors/_index.adoc @@ -198,12 +198,12 @@ The following individuals and businesses have generously contributed hardware fo * TRW Financial Systems, Inc. provided 130 PCs, three 68 GB file servers, twelve Ethernets, two routers and an ATM switch for debugging the diskless code * Dermot McDonnell donated the Toshiba XM3401B CDROM drive currently used in _freefall_. * Chuck Robey contributed his floppy tape streamer for experimental work. -* Larry Altneu and {wilko}, provided Wangtek and Archive QIC-02 tape drives in order to improve the [.filename]#wt# driver. +* Larry Altneu and {wilko}, provided Wangtek and Archive QIC-02 tape drives to improve the [.filename]#wt# driver. * Ernst Winter (http://berklix.org/ewinter/[Deceased]) contributed a 2.88 MB floppy drive to the project. This will hopefully increase the pressure for rewriting the floppy disk driver. * http://www.tekram.com/[Tekram Technologies] sent one each of their DC-390, DC-390U and DC-390F FAST and ULTRA SCSI host adapter cards for regression testing of the NCR and AMD drivers with their cards. They are also to be applauded for making driver sources for free operating systems available from their FTP server link:ftp://ftp.tekram.com/scsi/FreeBSD/[ftp://ftp.tekram.com/scsi/FreeBSD/]. * Larry M. Augustin contributed not only a Symbios Sym8751S SCSI card, but also a set of data books, including one about the forthcoming Sym53c895 chip with Ultra-2 and LVD support, and the latest programming manual with information on how to safely use the advanced features of the latest Symbios SCSI chips. Thanks a lot! * {kuku} donated an FX120 12 speed Mitsumi CDROM drive for IDE CDROM driver development. -* Mike Tancsa donated four various ATM PCI cards in order to help increase support of these cards as well as help support the development effort of the netatm ATM stack. +* Mike Tancsa donated four various ATM PCI cards to help increase support of these cards as well as help support the development effort of the netatm ATM stack. === Special contributors diff --git a/documentation/content/en/articles/cups/_index.adoc b/documentation/content/en/articles/cups/_index.adoc index 58930951c9..d16f8da5de 100644 --- a/documentation/content/en/articles/cups/_index.adoc +++ b/documentation/content/en/articles/cups/_index.adoc @@ -77,7 +77,7 @@ Once installed, the CUPS configuration files can be found in the directory [.fil [[printing-cups-configuring-server]] == Configuring the CUPS Print Server -After installation, a few files must be edited in order to configure the CUPS server. +After installation, a few files must be edited to configure the CUPS server. First, create or modify, as the case may be, the file [.filename]#/etc/devfs.rules# and add the following information to set the proper permissions on all potential printer devices and to associate printers with the `cups` user group: [.programlisting] @@ -105,7 +105,7 @@ devfs_system_ruleset="system" These two entries will start the CUPS print server on boot and invoke the local devfs rule created above, respectively. -In order to enable CUPS printing under certain Microsoft(R) Windows(R) clients, the line below should be uncommented in [.filename]#/usr/local/etc/cups/mime.types# and [.filename]#/usr/local/etc/cups/mime.convs#: +To enable CUPS printing under certain Microsoft(R) Windows(R) clients, the line below should be uncommented in [.filename]#/usr/local/etc/cups/mime.types# and [.filename]#/usr/local/etc/cups/mime.convs#: [.programlisting] .... diff --git a/documentation/content/en/articles/explaining-bsd/_index.adoc b/documentation/content/en/articles/explaining-bsd/_index.adoc index b188f0a2b0..ca7b1c02e5 100644 --- a/documentation/content/en/articles/explaining-bsd/_index.adoc +++ b/documentation/content/en/articles/explaining-bsd/_index.adoc @@ -145,8 +145,8 @@ Users can obtain a complete copy of any version. A large number of developers worldwide contribute to improvements to BSD. They are divided into three kinds: -* _Contributors_ write code or documentation. They are not permitted to commit (add code) directly to the source tree. In order for their code to be included in the system, it must be reviewed and checked in by a registered developer, known as a __committer__. -* _Committers_ are developers with write access to the source tree. In order to become a committer, an individual must show ability in the area in which they are active. +* _Contributors_ write code or documentation. They are not permitted to commit (add code) directly to the source tree. For their code to be included in the system, it must be reviewed and checked in by a registered developer, known as a __committer__. +* _Committers_ are developers with write access to the source tree. To become a committer, an individual must show ability in the area in which they are active. + It is at the individual committer's discretion whether they should obtain authority before committing changes to the source tree. In general, an experienced committer may make changes which are obviously correct without obtaining consensus. @@ -154,7 +154,7 @@ For example, a documentation project committer may correct typographical or gram On the other hand, developers making far-reaching or complicated changes are expected to submit their changes for review before committing them In extreme cases, a core team member with a function such as Principal Architect may order that changes be removed from the tree, a process known as _backing out_. All committers receive mail describing each individual commit, so it is not possible to commit secretly. -* The _Core team_. FreeBSD and NetBSD each have a core team which manages the project. The core teams developed in the course of the projects, and their role is not always well-defined. It is not necessary to be a developer in order to be a core team member, though it is normal. The rules for the core team vary from one project to the other, but in general they have more say in the direction of the project than non-core team members have. +* The _Core team_. FreeBSD and NetBSD each have a core team which manages the project. The core teams developed in the course of the projects, and their role is not always well-defined. It is not necessary to be a developer to be a core team member, though it is normal. The rules for the core team vary from one project to the other, but in general they have more say in the direction of the project than non-core team members have. This arrangement differs from Linux in a number of ways: @@ -206,7 +206,7 @@ This is particularly attractive for embedded applications. === What else should I know? Since fewer applications are available for BSD than Linux, the BSD developers created a Linux compatibility package, which allows Linux programs to run under BSD. -The package includes both kernel modifications, in order to correctly perform Linux system calls, and Linux compatibility files such as the C library. +The package includes both kernel modifications, to correctly perform Linux system calls, and Linux compatibility files such as the C library. There is no noticeable difference in execution speed between a Linux application running on a Linux machine and a Linux application running on a BSD machine of the same speed. The "all from one supplier" nature of BSD means that upgrades are much easier to handle than is frequently the case with Linux. diff --git a/documentation/content/en/articles/filtering-bridges/_index.adoc b/documentation/content/en/articles/filtering-bridges/_index.adoc index 1d9f76ba83..ae744fb88d 100644 --- a/documentation/content/en/articles/filtering-bridges/_index.adoc +++ b/documentation/content/en/articles/filtering-bridges/_index.adoc @@ -44,7 +44,7 @@ Abstract Often it is useful to divide one physical network (like an Ethernet) into two separate segments without having to create subnets, and use a router to link them together. The device that connects the two networks in this way is called a bridge. -A FreeBSD system with two network interfaces is enough in order to act as a bridge. +A FreeBSD system with two network interfaces is enough to act as a bridge. A bridge works by scanning the addresses of MAC level (Ethernet addresses) of the devices connected to each of its network interfaces and then forwarding the traffic between the two networks only if the source and the destination are on different segments. Under many points of view a bridge is similar to an Ethernet switch with only two ports. @@ -78,7 +78,7 @@ Select the best choice according to your needs and abilities. Before going on, be sure to have at least two Ethernet cards that support the promiscuous mode for both reception and transmission, since they must be able to send Ethernet packets with any address, not just their own. Moreover, to have a good throughput, the cards should be PCI bus mastering cards. The best choices are still the Intel EtherExpress(TM) Pro, followed by the 3Com(R) 3c9xx series. -To simplify the firewall configuration it may be useful to have two cards of different manufacturers (using different drivers) in order to distinguish clearly which interface is connected to the router and which to the inner network. +To simplify the firewall configuration it may be useful to have two cards of different manufacturers (using different drivers) to distinguish clearly which interface is connected to the router and which to the inner network. [[filtering-bridges-kernel]] === Kernel Configuration @@ -114,9 +114,9 @@ It is not required to add a similar row for the [.filename]#ipfw.ko# module, sin [[filtering-bridges-finalprep]] == Final Preparation -Before rebooting in order to load the new kernel or the required modules (according to the previously chosen installation method), you have to make some changes to the [.filename]#/etc/rc.conf# configuration file. +Before rebooting to load the new kernel or the required modules (according to the previously chosen installation method), you have to make some changes to the [.filename]#/etc/rc.conf# configuration file. The default rule of the firewall is to reject all IP packets. -Initially we will set up an `open` firewall, in order to verify its operation without any issue related to packet filtering (in case you are going to execute this procedure remotely, such configuration will avoid you to remain isolated from the network). +Initially we will set up an `open` firewall, to verify its operation without any issue related to packet filtering (in case you are going to execute this procedure remotely, such configuration will avoid you to remain isolated from the network). Put these lines in [.filename]#/etc/rc.conf#: [.programlisting] @@ -138,7 +138,7 @@ Assigning an IP to both the network cards does not make much sense, unless, duri There is another important thing to know. When running IP over Ethernet, there are actually two Ethernet protocols in use: one is IP, the other is ARP. ARP does the conversion of the IP address of a host into its Ethernet address (MAC layer). -In order to allow the communication between two hosts separated by the bridge, it is necessary that the bridge will forward ARP packets. +To allow the communication between two hosts separated by the bridge, it is necessary that the bridge will forward ARP packets. Such protocol is not included in the IP layer, since it exists only with IP over Ethernet. The FreeBSD firewall filters exclusively on the IP layer and therefore all non-IP packets (ARP included) will be forwarded without being filtered, even if the firewall is configured to not permit anything. @@ -161,12 +161,12 @@ At this point, to enable the bridge, you have to execute the following commands The first row specifies which interfaces should be activated by the bridge, the second one will enable the firewall on the bridge and finally the third one will enable the bridge. At this point you should be able to insert the machine between two sets of hosts without compromising any communication abilities between them. -If so, the next step is to add the `net.link.ether.bridge._[blah]_=_[blah]_` portions of these rows to the [.filename]#/etc/sysctl.conf# file, in order to have them execute at startup. +If so, the next step is to add the `net.link.ether.bridge._[blah]_=_[blah]_` portions of these rows to the [.filename]#/etc/sysctl.conf# file, to have them execute at startup. [[filtering-bridges-ipfirewall]] == Configuring The Firewall -Now it is time to create your own file with custom firewall rules, in order to secure the inside network. +Now it is time to create your own file with custom firewall rules, to secure the inside network. There will be some complication in doing this because not all of the firewall functionalities are available on bridged packets. Furthermore, there is a difference between the packets that are in the process of being forwarded and packets that are being received by the local machine. In general, incoming packets are run through the firewall only once, not twice as is normally the case; in fact they are filtered only upon receipt, so rules that use `out` or `xmit` will never match. @@ -267,7 +267,7 @@ But there is a difference: all suspected traffic will be logged. There are two rules for passing SMTP and DNS traffic towards the mail server and the name server, if you have them. Obviously the whole rule set should be flavored to personal taste, this is only a specific example (rule format is described accurately in the man:ipfw[8] man page). -Note that in order for "relay" and "ns" to work, name service lookups must work _before_ the bridge is enabled. +Note that for "relay" and "ns" to work, name service lookups must work _before_ the bridge is enabled. This is an example of making sure that you set the IP on the correct network card. Alternatively it is possible to specify the IP address instead of the host name (required if the machine is IP-less). diff --git a/documentation/content/en/articles/freebsd-releng/_index.adoc b/documentation/content/en/articles/freebsd-releng/_index.adoc index 02452258df..69a43a8d46 100644 --- a/documentation/content/en/articles/freebsd-releng/_index.adoc +++ b/documentation/content/en/articles/freebsd-releng/_index.adoc @@ -221,7 +221,7 @@ For example, a FreeBSD developer may request blanket approvals from the start of [NOTE] ==== -In order to keep track of blanket approvals, the {teamRe} uses an internal repository to keep a running log of such requests, which defines the area upon which a blanket approval was granted, the author(s), when the blanket approval expires, and the reason the approval was granted. +To keep track of blanket approvals, the {teamRe} uses an internal repository to keep a running log of such requests, which defines the area upon which a blanket approval was granted, the author(s), when the blanket approval expires, and the reason the approval was granted. One example of this is granting blanket approval to [.filename]#release/doc/# to all {teamRe} members until the final `RC` to update the release notes and other release-related documentation. ==== @@ -527,7 +527,7 @@ This is enforced by pre-commit hooks in the Subversion repository by editing [.f [NOTE] ==== There are two general exceptions to requiring commit approval during the release cycle. -The first is any change that needs to be committed by the Release Engineer in order to proceed with the day-to-day workflow of the release cycle, the other is security fixes that may occur during the release cycle. +The first is any change that needs to be committed by the Release Engineer to proceed with the day-to-day workflow of the release cycle, the other is security fixes that may occur during the release cycle. ==== Once the code freeze is in effect, the next build from the branch is labeled `BETA1`. @@ -540,7 +540,7 @@ Subsequent `BETA` builds do not require updates to any files other than [.filena === Creating the {branchRelengx} Branch When the first `RC` (Release Candidate) build is ready to begin, the {branchReleng} branch is created. -This is a multi-step process that must be done in a specific order, in order to avoid anomalies such as overlaps with `__FreeBSD_version` values, for example. +This is a multi-step process that must be done in a specific order, to avoid anomalies such as overlaps with `__FreeBSD_version` values, for example. The paths listed below are relative to the repository root. The order of commits and what to change are: @@ -641,7 +641,7 @@ See and [.filename]#src/release/release.conf.sample# for more details and exampl [[releng-build-scripts-multiple]] ==== The [.filename]#thermite.sh# Wrapper Script -In order to make cross building the full set of architectures supported on a given branch faster, easier, and reduce human error factors, a wrapper script around [.filename]#src/release/release.sh# was written to iterate through the various combinations of architectures and invoke [.filename]#src/release/release.sh# using a configuration file specific to that architecture. +To make cross building the full set of architectures supported on a given branch faster, easier, and reduce human error factors, a wrapper script around [.filename]#src/release/release.sh# was written to iterate through the various combinations of architectures and invoke [.filename]#src/release/release.sh# using a configuration file specific to that architecture. The wrapper script is called [.filename]#thermite.sh#, which is available in the FreeBSD Subversion repository at `svn://svn.freebsd.org/base/user/gjb/thermite/`, in addition to configuration files used to build {branchHead} and {branchStablex} development snapshots. @@ -795,14 +795,14 @@ On `ftp-master` in the FreeBSD Project infrastructure, this step requires `root` === Publishing FreeBSD Installation Media Once the images are staged in [.filename]#/archive/tmp/#, they are ready to be made public by putting them in [.filename]#/archive/pub/FreeBSD#. -In order to reduce propagation time, is used to create hard links from [.filename]#/archive/tmp# to [.filename]#/archive/pub/FreeBSD#. +To reduce propagation time, is used to create hard links from [.filename]#/archive/tmp# to [.filename]#/archive/pub/FreeBSD#. [NOTE] ==== -In order for this to be effective, both [.filename]#/archive/tmp# and [.filename]#/archive/pub# must reside on the same logical filesystem. +For this to be effective, both [.filename]#/archive/tmp# and [.filename]#/archive/pub# must reside on the same logical filesystem. ==== -There is a caveat, however, where rsync must be used after in order to correct the symbolic links in [.filename]#pub/FreeBSD/snapshots/ISO-IMAGES# which will replace with a hard link, increasing the propagation time. +There is a caveat, however, where rsync must be used after to correct the symbolic links in [.filename]#pub/FreeBSD/snapshots/ISO-IMAGES# which will replace with a hard link, increasing the propagation time. [NOTE] ==== diff --git a/documentation/content/en/articles/ipsec-must/_index.adoc b/documentation/content/en/articles/ipsec-must/_index.adoc index 361f70406f..d4de24e1a9 100644 --- a/documentation/content/en/articles/ipsec-must/_index.adoc +++ b/documentation/content/en/articles/ipsec-must/_index.adoc @@ -148,7 +148,7 @@ A comprehensive guide on running IPsec on FreeBSD is provided in extref:{handboo [[kernel]] == src/sys/i386/conf/KERNELNAME -This needs to be present in the kernel config file in order to capture network data with man:tcpdump[1]. +This needs to be present in the kernel config file to capture network data with man:tcpdump[1]. Be sure to run man:config[8] after adding this, and rebuild and reinstall. [.programlisting] diff --git a/documentation/content/en/articles/license-guide/_index.adoc b/documentation/content/en/articles/license-guide/_index.adoc index e6d91491dc..44fbb70d00 100644 --- a/documentation/content/en/articles/license-guide/_index.adoc +++ b/documentation/content/en/articles/license-guide/_index.adoc @@ -66,7 +66,7 @@ Any questions or concerns should immediately be brought to the attention of {cor == Software License Policy The following sections outline the project's Software License Policies in detail. -For the most part we expect developers to read, understand and utilize the sections above this one in order to apply appropriate licenses to their contributions. +For the most part we expect developers to read, understand and utilize the sections above this one to apply appropriate licenses to their contributions. The rest of this document details the philosophical background to the policies as well as the policies in great detail. As always, if the text below is confusing or you need help with applying these policies, please reach out to {core-email}. @@ -113,7 +113,7 @@ The Core Team must approve the import of new CDDL licensed components or the cha *** ZFS filesystem, including kernel support and userland utilities * Historically, the phrase 'All Rights Reserved.' was included in all copyright notices. -All the BSD releases had it, in order to comply with the https://en.wikipedia.org/wiki/Buenos_Aires_Convention[Buenos Aires Convention of 1910] in the Americas. +All the BSD releases had it, to comply with the https://en.wikipedia.org/wiki/Buenos_Aires_Convention[Buenos Aires Convention of 1910] in the Americas. With the ratification of the https://en.wikipedia.org/wiki/Berne_Convention[Berne Convention] in 2000 by Nicaragua, the Buenos Aires Convention -- and the phrase -- became obsolete. As such, the FreeBSD project recommends that new code omit the phrase and encourages existing copyright holders to remove it. In 2018, the project updated its templates to remove it. diff --git a/documentation/content/en/articles/linux-emulation/_index.adoc b/documentation/content/en/articles/linux-emulation/_index.adoc index b695d7bc81..7fefba22e0 100644 --- a/documentation/content/en/articles/linux-emulation/_index.adoc +++ b/documentation/content/en/articles/linux-emulation/_index.adoc @@ -510,14 +510,14 @@ numbers are not casual Spin locks let waiters to spin until they cannot acquire the lock. An important matter do deal with is when a thread contests on a spin lock if it is not descheduled. -Since the FreeBSD kernel is preemptive, this exposes spin lock at the risk of deadlocks that can be solved just disabling interrupts while they are acquired. +Since the FreeBSD kernel is preemptive, this exposes spin lock at the risk of deadlocks that can be solved just disabling interrupts while they are acquired. For this and other reasons (like lack of priority propagation support, poorness in load balancing schemes between CPUs, etc.), spin locks are intended to protect very small paths of code, or ideally not to be used at all if not explicitly requested (explained later). [[freebsd-blocking]] ===== Blocking Block locks let waiters to be descheduled and blocked until the lock owner does not drop it and wakes up one or more contenders. -In order to avoid starvation issues, blocking locks do priority propagation from the waiters to the owner. +To avoid starvation issues, blocking locks do priority propagation from the waiters to the owner. Block locks must be implemented through the turnstile interface and are intended to be the most used kind of locks in the kernel, if no particular conditions are met. [[freebsd-sleeping]] @@ -548,7 +548,7 @@ Among these locks only mutexes, sxlocks, rwlocks and lockmgrs are intended to ha [[freebsd-scheduling]] ===== Scheduling barriers -Scheduling barriers are intended to be used in order to drive scheduling of threading. +Scheduling barriers are intended to be used to drive scheduling of threading. They consist mainly of three different stubs: * critical sections (and preemption) @@ -561,11 +561,11 @@ Generally, these should be used only in a particular context and even if they ca ===== Critical sections The FreeBSD kernel has been made preemptive basically to deal with interrupt threads. -In fact, in order to avoid high interrupt latency, time-sharing priority threads can be preempted by interrupt threads (in this way, they do not need to wait to be scheduled as the normal path previews). +In fact, to avoid high interrupt latency, time-sharing priority threads can be preempted by interrupt threads (in this way, they do not need to wait to be scheduled as the normal path previews). Preemption, however, introduces new racing points that need to be handled, as well. -Often, in order to deal with preemption, the simplest thing to do is to completely disable it. +Often, to deal with preemption, the simplest thing to do is to completely disable it. A critical section defines a piece of code (borderlined by the pair of functions man:critical_enter[9] and man:critical_exit[9], where preemption is guaranteed to not happen (until the protected code is fully executed). -This can often replace a lock effectively but should be used carefully in order to not lose the whole advantage that preemption brings. +This can often replace a lock effectively but should be used carefully to not lose the whole advantage that preemption brings. [[freebsd-schedpin]] ===== sched_pin/sched_unpin @@ -578,7 +578,7 @@ The latter condition will determine a critical section as a too strong condition [[freebsd-schedbind]] ===== sched_bind/sched_unbind -`sched_bind` is an API used in order to bind a thread to a particular CPU for all the time it executes the code, until a `sched_unbind` function call does not unbind it. +`sched_bind` is an API used to bind a thread to a particular CPU for all the time it executes the code, until a `sched_unbind` function call does not unbind it. This feature has a key role in situations where you cannot trust the current state of CPUs (for example, at very early stages of boot), as you want to avoid your thread to migrate on inactive CPUs. Since `sched_bind` and `sched_unbind` manipulate internal scheduler structures, they need to be enclosed in `sched_lock` acquisition/releasing when used. @@ -741,7 +741,7 @@ On the other hand `close` is just an alias for real FreeBSD man:close[2] so it h The Linux(R) emulation layer is not complete, as some syscalls are not implemented properly and some are not implemented at all. The emulation layer employs a facility to mark unimplemented syscalls with the `DUMMY` macro. These dummy definitions reside in [.filename]#linux_dummy.c# in a form of `DUMMY(syscall);`, which is then translated to various syscall auxiliary files and the implementation consists of printing a message saying that this syscall is not implemented. -The `UNIMPL` prototype is not used because we want to be able to identify the name of the syscall that was called in order to know what syscalls are more important to implement. +The `UNIMPL` prototype is not used because we want to be able to identify the name of the syscall that was called to know what syscalls are more important to implement. [[signal-handling]] === Signal handling @@ -775,7 +775,7 @@ It also unmasks the signal in process signal mask. [[ptrace]] === Ptrace -Many UNIX(R) derivates implement the man:ptrace[2] syscall in order to allow various tracking and debugging features. +Many UNIX(R) derivates implement the man:ptrace[2] syscall to allow various tracking and debugging features. This facility enables the tracing process to obtain various information about the traced process, like register dumps, any memory from the process address space, etc. and also to trace the process like in stepping an instruction or between system entries (syscalls and traps). man:ptrace[2] also lets you set various information in the traced process (registers etc.). man:ptrace[2] is a UNIX(R)-wide standard implemented in most UNIX(R)es around the world. diff --git a/documentation/content/en/articles/rc-scripting/_index.adoc b/documentation/content/en/articles/rc-scripting/_index.adoc index ae68c31c28..cdfa656e53 100644 --- a/documentation/content/en/articles/rc-scripting/_index.adoc +++ b/documentation/content/en/articles/rc-scripting/_index.adoc @@ -92,7 +92,7 @@ Finally, an important part of the [.filename]#rc.d# framework is man:rcorder[8], It can help [.filename]#/etc/rc.shutdown#, too, because the proper order for the shutdown sequence is opposite to that of startup. The BSD [.filename]#rc.d# design is described in <>, and the [.filename]#rc.d# components are documented in great detail in <>. -However, it might not appear obvious to an [.filename]#rc.d# newbie how to tie the numerous bits and pieces together in order to create a well-styled script for a particular task. +However, it might not appear obvious to an [.filename]#rc.d# newbie how to tie the numerous bits and pieces together to create a well-styled script for a particular task. Therefore this article will try a different approach to describe [.filename]#rc.d#. It will show which features should be used in a number of typical cases, and why. Note that this is not a how-to document because our aim is not at giving ready-made recipes, but at showing a few easy entrances into the [.filename]#rc.d# realm. @@ -100,7 +100,7 @@ Neither is this article a replacement for the relevant manual pages. Do not hesitate to refer to them for more formal and complete documentation while reading this article. There are prerequisites to understanding this article. -First of all, you should be familiar with the man:sh[1] scripting language in order to master [.filename]#rc.d#. +First of all, you should be familiar with the man:sh[1] scripting language to master [.filename]#rc.d#. In addition, you should know how the system performs userland startup and shutdown tasks, which is described in man:rc[8]. This article focuses on the FreeBSD branch of [.filename]#rc.d#. @@ -110,7 +110,7 @@ Nevertheless, it may be useful to NetBSD developers, too, because the two branch == Outlining the task A little consideration before starting `$EDITOR` will not hurt. -In order to write a well-tempered [.filename]#rc.d# script for a system service, we should be able to answer the following questions first: +To write a well-tempered [.filename]#rc.d# script for a system service, we should be able to answer the following questions first: * Is the service mandatory or optional? * Will the script serve a single program, e.g., a daemon, or perform more complex actions? @@ -157,7 +157,7 @@ For example, a system admin can run our script manually, from the command line: [NOTE] ==== -In order to be properly managed by the [.filename]#rc.d# framework, its scripts need to be written in the man:sh[1] language. +To be properly managed by the [.filename]#rc.d# framework, its scripts need to be written in the man:sh[1] language. If you have a service or port that uses a binary control utility or a startup routine written in another language, install that element in [.filename]#/usr/sbin# (for the system) or [.filename]#/usr/local/sbin# (for ports) and call it from a man:sh[1] script in the appropriate [.filename]#rc.d# directory. ==== diff --git a/documentation/content/en/articles/remote-install/_index.adoc b/documentation/content/en/articles/remote-install/_index.adoc index f1bd16bb37..9efc5e4165 100644 --- a/documentation/content/en/articles/remote-install/_index.adoc +++ b/documentation/content/en/articles/remote-install/_index.adoc @@ -70,7 +70,7 @@ The instructions included in this article will benefit those using services prov [.procedure] ==== -. As we have mentioned in the <> section, many of the reputable server hosting companies provide some kind of rescue system, which is booted from their LAN and accessible over SSH. They usually provide this support in order to help their customers fix broken operating systems. As this article will explain, it is possible to install FreeBSD with the help of these rescue systems. +. As we have mentioned in the <> section, many of the reputable server hosting companies provide some kind of rescue system, which is booted from their LAN and accessible over SSH. They usually provide this support to help their customers fix broken operating systems. As this article will explain, it is possible to install FreeBSD with the help of these rescue systems. + . The next section of this article will describe how to configure, and build minimalistic FreeBSD on the local machine. That version will eventually be running on the remote machine from a ramdisk, which will allow us to install a complete FreeBSD operating system from an FTP mirror using the sysinstall utility. . The rest of this article will describe the installation procedure itself, as well as the configuration of the ZFS file system. @@ -261,7 +261,7 @@ The following example will describe how to create slices and labels, initialize <.> Write a standard label for each disk including the bootstrap code. -<.> Now, manually edit the label of the given disk. Refer to the man:bsdlabel[8] manual page in order to find out how to create partitions. Create partitions `a` for [.filename]#/# (root) file system, `b` for swap, `d` for [.filename]#/var#, `e` for [.filename]#/usr# and finally `f` which will later be used for ZFS. +<.> Now, manually edit the label of the given disk. Refer to the man:bsdlabel[8] manual page to find out how to create partitions. Create partitions `a` for [.filename]#/# (root) file system, `b` for swap, `d` for [.filename]#/var#, `e` for [.filename]#/usr# and finally `f` which will later be used for ZFS. <.> Import the recently created label for the second hard drive, so both hard drives will be labeled in the same way. @@ -297,7 +297,7 @@ Note that this step is very important and if skipped, `sysinstall` will be unabl ==== Go to the [.guimenuitem]#Distributions# menu, move the cursor with the arrow keys to `Minimal`, and check it by pressing kbd:[Space]. -This article uses the Minimal distribution in order to save network traffic, because the system itself will be installed over ftp. +This article uses the Minimal distribution to save network traffic, because the system itself will be installed over ftp. Exit this menu by choosing `Exit`. [NOTE] @@ -315,9 +315,9 @@ Exit `sysinstall` when it finishes the installation. === Post Installation Steps The FreeBSD operating system should be installed now; however, the process is not finished yet. -It is necessary to perform some post installation steps in order to allow FreeBSD to boot in the future and to be able to log in to the system. +It is necessary to perform some post installation steps to allow FreeBSD to boot in the future and to be able to log in to the system. -You must now man:chroot[8] into the freshly installed system in order to finish the installation. +You must now man:chroot[8] into the freshly installed system to finish the installation. Use the following command: [source,shell] diff --git a/documentation/content/en/articles/vinum/_index.adoc b/documentation/content/en/articles/vinum/_index.adoc index f6b0baea11..0583ae94a7 100644 --- a/documentation/content/en/articles/vinum/_index.adoc +++ b/documentation/content/en/articles/vinum/_index.adoc @@ -68,7 +68,7 @@ This chapter provides an overview of potential problems with traditional disk st [NOTE] ==== -Starting with FreeBSD 5, [.filename]#vinum# has been rewritten in order to fit into the extref:{handbook}[GEOM architecture, geom], while retaining the original ideas, terminology, and on-disk metadata. +Starting with FreeBSD 5, [.filename]#vinum# has been rewritten to fit into the extref:{handbook}[GEOM architecture, geom], while retaining the original ideas, terminology, and on-disk metadata. This rewrite is called _gvinum_ (for _GEOM vinum_). While this chapter uses the term [.filename]#vinum#, any command invocations should be performed with `gvinum`. The name of the kernel module has changed from the original [.filename]#vinum.ko# to [.filename]#geom_vinum.ko#, and all device nodes reside under [.filename]#/dev/gvinum# instead of [.filename]#/dev/vinum#. @@ -158,7 +158,7 @@ If one drive fails, the array can continue to operate in degraded mode where a r [[vinum-objects]] == [.filename]#vinum# Objects -In order to address these problems, [.filename]#vinum# implements a four-level hierarchy of objects: +To address these problems, [.filename]#vinum# implements a four-level hierarchy of objects: * The most visible object is the virtual disk, called a _volume_. Volumes have essentially the same properties as a UNIX(R) disk drive, though there are some minor differences. For one, they have no size limitations. * Volumes are composed of _plexes_, each of which represent the total address space of a volume. This level in the hierarchy provides redundancy. Think of plexes as individual disks in a mirrored array, each containing the same data. @@ -186,7 +186,7 @@ As long as at least one plex can provide the data for the complete address range [.filename]#vinum# implements both concatenation and striping at the plex level: * A _concatenated plex_ uses the address space of each subdisk in turn. Concatenated plexes are the most flexible as they can contain any number of subdisks, and the subdisks may be of different length. The plex may be extended by adding additional subdisks. They require less CPU time than striped plexes, though the difference in CPU overhead is not measurable. On the other hand, they are most susceptible to hot spots, where one disk is very active and others are idle. -* A _striped plex_ stripes the data across each subdisk. The subdisks must all be the same size and there must be at least two subdisks in order to distinguish it from a concatenated plex. The greatest advantage of striped plexes is that they reduce hot spots. By choosing an optimum sized stripe, about 256 kB, the load can be evened out on the component drives. Extending a plex by adding new subdisks is so complicated that [.filename]#vinum# does not implement it. +* A _striped plex_ stripes the data across each subdisk. The subdisks must all be the same size and there must be at least two subdisks to distinguish it from a concatenated plex. The greatest advantage of striped plexes is that they reduce hot spots. By choosing an optimum sized stripe, about 256 kB, the load can be evened out on the component drives. Extending a plex by adding new subdisks is so complicated that [.filename]#vinum# does not implement it. <> summarizes the advantages and disadvantages of each plex organization. @@ -484,7 +484,7 @@ For example, a disk drive may have a name like [.filename]#/dev/ad0a# or [.filen These names represent the first partition ([.filename]#a#) on the first (0) IDE disk ([.filename]#ad#) and the eighth partition ([.filename]#h#) on the third (2) SCSI disk ([.filename]#da#) respectively. By contrast, a [.filename]#vinum# volume might be called [.filename]#/dev/gvinum/concat#, which has no relationship with a partition name. -In order to create a file system on this volume, use man:newfs[8]: +To create a file system on this volume, use man:newfs[8]: [source,shell] .... @@ -582,7 +582,7 @@ Each single subdisk within these plexes needs its own `a` partition illusion, fo It is not strictly needed that each of these faked `a` partitions is located at the same offset within its device, compared with other devices containing plexes of the root volume. However, it is probably a good idea to create the [.filename]#vinum# volumes that way so the resulting mirrored devices are symmetric, to avoid confusion. -In order to set up these `a` partitions for each device containing part of the root volume, the following is required: +To set up these `a` partitions for each device containing part of the root volume, the following is required: [.procedure] ==== @@ -594,7 +594,7 @@ In order to set up these `a` partitions for each device containing part of the r .... + [.filename]#vinum# offsets and sizes are measured in bytes. -They must be divided by 512 in order to obtain the block numbers that are to be used by `bsdlabel`. +They must be divided by 512 to obtain the block numbers that are to be used by `bsdlabel`. . Run this command for each device that participates in the root volume: + [source,shell] @@ -713,4 +713,4 @@ So if a [.filename]#vinum# partition was started at offset 0 within a slice or d Similarly, if the above situation has been recovered, by booting from a "Fixit" media, and the bootstrap has been re-installed using `bsdlabel -B` as described in extref:{handbook}[stage two, boot-boot1], the bootstrap will trash the [.filename]#vinum# header, and [.filename]#vinum# will no longer find its disk(s). Though no actual [.filename]#vinum# configuration data or data in [.filename]#vinum# volumes will be trashed, and it would be possible to recover all the data by entering exactly the same [.filename]#vinum# configuration data again, the situation is hard to fix. -It is necessary to move the entire [.filename]#vinum# partition by at least 4 KB, in order to have the [.filename]#vinum# header and the system bootstrap no longer collide. +It is necessary to move the entire [.filename]#vinum# partition by at least 4 KB, to have the [.filename]#vinum# header and the system bootstrap no longer collide. diff --git a/documentation/content/en/articles/vm-design/_index.adoc b/documentation/content/en/articles/vm-design/_index.adoc index 7499c1e362..1a6431a489 100644 --- a/documentation/content/en/articles/vm-design/_index.adoc +++ b/documentation/content/en/articles/vm-design/_index.adoc @@ -76,7 +76,7 @@ These issues are not due to bad algorithmic design but instead rise from environ In any direct comparison between platforms, these issues become most apparent when system resources begin to get stressed. As I describe FreeBSD's VM/Swap subsystem the reader should always keep two points in mind: -. The most important aspect of performance design is what is known as "Optimizing the Critical Path". It is often the case that performance optimizations add a little bloat to the code in order to make the critical path perform better. +. The most important aspect of performance design is what is known as "Optimizing the Critical Path". It is often the case that performance optimizations add a little bloat to the code to make the critical path perform better. . A solid, generalized design outperforms a heavily-optimized design over the long run. While a generalized design may end up being slower than an heavily-optimized design when they are first implemented, the generalized design tends to be easier to adapt to changing conditions and the heavily-optimized design winds up having to be thrown away. Any codebase that will survive and be maintainable for years must therefore be designed properly from the beginning even if it costs some performance. @@ -185,7 +185,7 @@ FreeBSD allocates the swap management structure for a VM Object only when it is However, the swap management structure has had problems historically: * Under FreeBSD 3.X the swap management structure preallocates an array that encompasses the entire object requiring swap backing store-even if only a few pages of that object are swap-backed. This creates a kernel memory fragmentation problem when large objects are mapped, or processes with large runsizes (RSS) fork. -* Also, in order to keep track of swap space, a "list of holes" is kept in kernel memory, and this tends to get severely fragmented as well. Since the "list of holes" is a linear list, the swap allocation and freeing performance is a non-optimal O(n)-per-page. +* Also, to keep track of swap space, a "list of holes" is kept in kernel memory, and this tends to get severely fragmented as well. Since the "list of holes" is a linear list, the swap allocation and freeing performance is a non-optimal O(n)-per-page. * It requires kernel memory allocations to take place during the swap freeing process, and that creates low memory deadlock problems. * The problem is further exacerbated by holes created due to the interleaving algorithm. * Also, the swap block map can become fragmented fairly easily resulting in non-contiguous allocations. @@ -196,10 +196,10 @@ For FreeBSD 4.X, I completely rewrote the swap subsystem: * Swap management structures are allocated through a hash table rather than a linear array giving them a fixed allocation size and much finer granularity. * Rather then using a linearly linked list to keep track of swap space reservations, it now uses a bitmap of swap blocks arranged in a radix tree structure with free-space hinting in the radix node structures. This effectively makes swap allocation and freeing an O(1) operation. -* The entire radix tree bitmap is also preallocated in order to avoid having to allocate kernel memory during critical low memory swapping operations. After all, the system tends to swap when it is low on memory so we should avoid allocating kernel memory at such times in order to avoid potential deadlocks. +* The entire radix tree bitmap is also preallocated to avoid having to allocate kernel memory during critical low memory swapping operations. After all, the system tends to swap when it is low on memory so we should avoid allocating kernel memory at such times to avoid potential deadlocks. * To reduce fragmentation the radix tree is capable of allocating large contiguous chunks at once, skipping over smaller fragmented chunks. -I did not take the final step of having an "allocating hint pointer" that would trundle through a portion of swap as allocations were made in order to further guarantee contiguous allocations or at least locality of reference, but I ensured that such an addition could be made. +I did not take the final step of having an "allocating hint pointer" that would trundle through a portion of swap as allocations were made to further guarantee contiguous allocations or at least locality of reference, but I ensured that such an addition could be made. [[freeing-pages]] == When to free a page @@ -208,7 +208,7 @@ Since the VM system uses all available memory for disk caching, there are usuall The VM system depends on being able to properly choose pages which are not in use to reuse for new allocations. Selecting the optimal pages to free is possibly the single-most important function any VM system can perform because if it makes a poor selection, the VM system may be forced to unnecessarily retrieve pages from disk, seriously degrading system performance. -How much overhead are we willing to suffer in the critical path to avoid freeing the wrong page? Each wrong choice we make will cost us hundreds of thousands of CPU cycles and a noticeable stall of the affected processes, so we are willing to endure a significant amount of overhead in order to be sure that the right page is chosen. +How much overhead are we willing to suffer in the critical path to avoid freeing the wrong page? Each wrong choice we make will cost us hundreds of thousands of CPU cycles and a noticeable stall of the affected processes, so we are willing to endure a significant amount of overhead to be sure that the right page is chosen. This is why FreeBSD tends to outperform other systems when memory resources become stressed. The free page determination algorithm is built upon a history of the use of memory pages. @@ -240,7 +240,7 @@ This is why you will see some systems with very low cache queue counts and high As the VM system becomes more stressed, it makes a greater effort to maintain the various page queues at the levels determined to be the most effective. An urban myth has circulated for years that Linux did a better job avoiding swapouts than FreeBSD, but this in fact is not true. -What was actually occurring was that FreeBSD was proactively paging out unused pages in order to make room for more disk cache while Linux was keeping unused pages in core and leaving less memory available for cache and process pages. +What was actually occurring was that FreeBSD was proactively paging out unused pages to make room for more disk cache while Linux was keeping unused pages in core and leaving less memory available for cache and process pages. I do not know whether this is still true today. [[prefault-optimizations]] @@ -261,8 +261,8 @@ These occur when a process accesses pages in its BSS area. The BSS area is expected to be initially zero but the VM system does not bother to allocate any memory at all until the process actually accesses it. When a fault occurs the VM system must not only allocate a new page, it must zero it as well. To optimize the zeroing operation the VM system has the ability to pre-zero pages and mark them as such, and to request pre-zeroed pages when zero-fill faults occur. -The pre-zeroing occurs whenever the CPU is idle but the number of pages the system pre-zeros is limited in order to avoid blowing away the memory caches. -This is an excellent example of adding complexity to the VM system in order to optimize the critical path. +The pre-zeroing occurs whenever the CPU is idle but the number of pages the system pre-zeros is limited to avoid blowing away the memory caches. +This is an excellent example of adding complexity to the VM system to optimize the critical path. [[page-table-optimizations]] == Page Table Optimizations @@ -360,16 +360,16 @@ A `vm_page` represents an (object,index#) tuple. A `pv_entry` represents a hardw If you have five processes sharing the same physical page, and three of those processes's page tables actually map the page, that page will be represented by a single `vm_page` structure and three `pv_entry` structures. `pv_entry` structures only represent pages mapped by the MMU (one `pv_entry` represents one pte). -This means that when we need to remove all hardware references to a `vm_page` (in order to reuse the page for something else, page it out, clear it, dirty it, and so forth) we can simply scan the linked list of pv_entry's associated with that vm_page to remove or modify the pte's from their page tables. +This means that when we need to remove all hardware references to a `vm_page` (to reuse the page for something else, page it out, clear it, dirty it, and so forth) we can simply scan the linked list of pv_entry's associated with that vm_page to remove or modify the pte's from their page tables. Under Linux there is no such linked list. -In order to remove all the hardware page table mappings for a `vm_page` linux must index into every VM object that _might_ have mapped the page. +To remove all the hardware page table mappings for a `vm_page` linux must index into every VM object that _might_ have mapped the page. For example, if you have 50 processes all mapping the same shared library and want to get rid of page X in that library, you need to index into the page table for each of those 50 processes even if only 10 of them have actually mapped the page. So Linux is trading off the simplicity of its design against performance. Many VM algorithms which are O(1) or (small N) under FreeBSD wind up being O(N), O(N^2), or worse under Linux. Since the pte's representing a particular page in an object tend to be at the same offset in all the page tables they are mapped in, reducing the number of accesses into the page tables at the same pte offset will often avoid blowing away the L1 cache line for that offset, which can lead to better performance. -FreeBSD has added complexity (the `pv_entry` scheme) in order to increase performance (to limit page table accesses to _only_ those pte's that need to be modified). +FreeBSD has added complexity (the `pv_entry` scheme) to increase performance (to limit page table accesses to _only_ those pte's that need to be modified). But FreeBSD has a scaling problem that Linux does not in that there are a limited number of `pv_entry` structures and this causes problems when you have massive sharing of data. In this case you may run out of `pv_entry` structures even though there is plenty of free memory available.