| /linux/Documentation/translations/sp_SP/process/ |
| H A D | embargoed-hardware-issues.rst | 7 Problemas de hardware embargados
13 Los problemas de hardware que resultan en problemas de seguridad son una
14 categoría diferente de errores de seguridad que los errores de software
15 puro que solo afectan al kernel de Linux.
17 Los problemas de hardware como Meltdown, Spectre, L1TF, etc. deben
18 tratarse de manera diferente porque usualmente afectan a todos los
20 vendedores diferentes de OS, distribuciones, vendedores de hardware y
21 otras partes. Para algunos de los problemas, las mitigaciones de software
22 pueden depender de actualizaciones de microcódigo o firmware, los cuales
30 El equipo de seguridad de hardware del kernel de Linux es separado del
[all …]
|
| H A D | 2.Process.rst | 8 Cómo funciona el proceso de desarrollo
11 El desarrollo del kernel de Linux a principios de la década de 1990 fue
12 un asunto relajado, con un número relativamente pequeño de usuarios y
13 desarrolladores involucrados. Con una base de usuarios en los millones y
14 alrededor de 2,000 desarrolladores involucrados durante un año, el kernel
16 problemas. Se requiere una comprensión solida de cómo funciona el proceso
22 Los desarrolladores del kernel utilizan un proceso de lanzamiento basado
23 en el tiempo de manera flexible, con uno nuevo lanzamiento principal del
24 kernel ocurriendo cada dos o tres meses. El historial reciente de
38 puede contener alrededor de 13,000 conjuntos de cambios incluyendo en
[all …]
|
| H A D | 1.Intro.rst | 14 El resto de esta sección cubre el alcance del proceso de desarrollo del
15 kernel y los tipos de frustraciones que los desarrolladores y sus
18 incluyendo la disponibilidad automática para los usuarios, el apoyo de la
19 comunidad en muchas formas, y la capacidad de influir en la dirección del
20 desarrollo del kernel. El código contribuido al kernel de Linux debe
23 :ref:`sp_development_process` introduce el proceso de desarrollo, el ciclo
24 de lanzamiento del kernel y la mecánica de la "ventana de combinación"
26 la revisión y, el ciclo de fusión. Hay algunas discusiones sobre
27 herramientas y listas de correo. Se anima a los desarrolladores que deseen
31 :ref:`sp_development_early_stage` cubre la planificación de proyectos en
[all …]
|
| H A D | maintainer-kvm-x86.rst | 11 KVM se esfuerza por ser una comunidad acogedora; las contribuciones de los
13 se sienta intimidado por la extensión de este documento y las numerosas
16 seguir las directrices de KVM x86, sea receptivo a los comentarios, y
17 aprenda de los errores que cometa, será recibido con los brazos abiertos,
27 KVM x86 se encuentra actualmente en un período de transición de ser parte
28 del árbol principal de KVM, a ser "sólo otra rama de KVM". Como tal, KVM
29 x86 está dividido entre el árbol principal de KVM,
30 ``git.kernel.org/pub/scm/virt/kvm/kvm.git``, y un árbol específico de KVM
34 directamente al árbol principal de KVM, mientras que todo el desarrollo
35 para el siguiente ciclo se dirige a través del árbol de KVM x86. En el
[all …]
|
| H A D | howto.rst | 8 Cómo participar en el desarrollo del kernel de Linux
11 Este documento es el principal punto de partida. Contiene instrucciones
12 sobre cómo convertirse en desarrollador del kernel de Linux y explica cómo
17 Si algo en este documento quedara obsoleto, envíe parches al maintainer de
22 ¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del
23 kernel de Linux? Tal vez su jefe le haya dicho, "Escriba un driver de
24 Linux para este dispositivo." El objetivo de este documento en enseñarle
26 que debe pasar, y con indicaciones de como trabajar con la comunidad.
27 También trata de explicar las razones por las cuales la comunidad trabaja
28 de la forma en que lo hace.
[all …]
|
| H A D | contribution-maturity-model.rst | 8 Modelo de Madurez de Contribución al Kernel de Linux
15 Como parte de la cumbre de mantenedores del kernel de Linux 2021, hubo
17 en el reclutamiento de mantenedores del kernel, así como la sucesión de
18 los mantenedores. Algunas de las conclusiones de esa discusión incluyeron
19 que las empresas que forman parte de la comunidad del kernel de Linux
20 necesitan permitir que los ingenieros sean mantenedores como parte de su
22 en mantenedores del kernel. Para apoyar una fuente solida de talento, se
24 upstream, como revisar los parches de otras personas, reestructurar la
27 Con ese fin, Technical Advisory Board (TAB) de la Fundación Linux propone
28 este Modelo de Madurez de Contribución al Kernel de Linux. Estas
[all …]
|
| H A D | handling-regressions.rst | 7 Gestión de regresiones
11 regla del desarrollo del kernel de Linux" y que implica en la práctica para
14 desde el punto de vista de un usuario; si nunca ha leído ese texto, realice
15 al menos una lectura rápida del mismo antes de continuar.
20 #. Asegúrese de que los suscriptores a la lista `regression mailing list
22 son conocedores con rapidez de cualquier nuevo informe de regresión:
25 conversación de los correos, mandando un breve "Reply-all" con la
28 * Mande o redirija cualquier informe originado en los gestores de bugs
31 #. Haga que el bot del kernel de Linux "regzbot" realice el seguimiento del
36 respuesta (con la lista de regresiones en CC) que contenga un párrafo
[all …]
|
| H A D | deprecated.rst | 12 En un mundo perfecto, sería posible convertir todas las instancias de
14 único ciclo de desarrollo. Desafortunadamente, debido al tamaño del kernel,
15 la jerarquía de mantenimiento, y el tiempo, no siempre es posible hacer
16 estos cambios de una única vez. Esto significa que las nuevas instancias
17 han de ir creándose en el kernel, mientras que las antiguas se quitan,
18 haciendo que la cantidad de trabajo para limpiar las APIs crezca. Para
28 porque uno de los objetivos del kernel es que compile sin avisos, y
31 un archivo de cabecera, no es la solución completa. Dichos interfaces
37 Use WARN() y WARN_ON() en su lugar, y gestione las condiciones de error
38 "imposibles" tan elegantemente como se pueda. Mientras que la familia de
[all …]
|
| H A D | kernel-enforcement-statement.rst | 8 Aplicación de la licencia en el kernel Linux
12 se utiliza nuestro software y cómo se aplica la licencia de nuestro software.
13 El cumplimiento de las obligaciones de intercambio recíproco de GPL-2.0 son
14 fundamentales en el largo plazo para la sostenibilidad de nuestro software
17 Aunque existe el derecho de hacer valer un copyright distinto en las
18 contribuciones hechas a nuestra comunidad, compartimos el interés de
20 de una manera que beneficia a nuestra comunidad y no tenga un indeseado
21 impacto negativo en la salud y crecimiento de nuestro ecosistema de software.
22 Con el fin de disuadir la aplicación inútil de acciones, estamos de acuerdo
23 en que es en el mejor interés de nuestro desarrollo como comunidad asumir
[all …]
|
| H A D | management-style.rst | 9 Estilo de gestión del kernel de Linux
12 Este es un documento breve que describe el estilo de gestión preferido (o
13 inventado, dependiendo de a quién le preguntes) para el kernel de Linux.
19 El estilo de gestión es muy personal y mucho más difícil de cuantificar
20 que reglas simples de estilo de codificación, por lo que este documento
25 Por cierto, cuando se hable de “gerente de kernel”, se refiere a las
26 personas lideres técnicas, no de las personas que hacen la gestión
27 tradicional dentro de las empresas. Si firmas pedidos de compra o tienes
28 alguna idea sobre el presupuesto de tu grupo, es casi seguro que no eres
29 un gerente de kernel. Estas sugerencias pueden o no aplicarse a usted.
[all …]
|
| H A D | security-bugs.rst | 7 Errores de seguridad
10 Los desarrolladores del kernel de Linux se toman la seguridad muy en
11 serio. Como tal, nos gustaría saber cuándo se encuentra un error de
13 Por favor, informe sobre los errores de seguridad al equipo de seguridad
14 del kernel de Linux.
19 El equipo de seguridad del kernel de Linux puede ser contactado por correo
20 electrónico en <security@kernel.org>. Esta es una lista privada de
21 oficiales de seguridad que ayudarán a verificar el informe del error y
24 el proceso. Es posible que el equipo de seguridad traiga ayuda adicional
25 de mantenedores del área para comprender y corregir la vulnerabilidad de
[all …]
|
| H A D | researcher-guidelines.rst | 9 La comunidad del kernel de Linux da la bienvenida a la investigación
10 transparente sobre el kernel de Linux, las actividades involucradas
11 en su producción, otros subproductos de su desarrollo. Linux se
12 beneficia mucho de este tipo de investigación, y la mayoría de los
13 aspectos de Linux son impulsados por investigación en una forma u otra.
16 los hallazgos preliminares antes de hacer públicos sus resultados,
18 temprano ayuda a mejorar la calidad de investigación y la capacidad
19 de Linux para mejorar a partir de ella. En cualquier caso, se recomienda
20 compartir copias de acceso abierto de la investigación publicada con
23 Este documento busca clarificar lo que la comunidad del kernel de Linux
[all …]
|
| /linux/Documentation/translations/pt_BR/process/ |
| H A D | adding-syscalls.rst | 4 Adicionando uma Nova Chamada de Sistema
7 Este documento descreve o que está envolvido na adição de uma nova chamada de
8 sistema (system call) ao kernel Linux, indo além dos conselhos normais de
13 Alternativas às Chamadas de Sistema
16 A primeira coisa a se considerar ao adicionar uma nova chamada de sistema é se
17 uma das alternativas poderia ser mais adequada. Embora as chamadas de sistema
18 sejam os pontos de interação mais tradicionais e óbvios entre o espaço do
23 objeto do tipo arquivo, pode fazer mais sentido criar um novo sistema de
25 funcionalidade em um módulo de kernel, em vez de exigir que ela seja
29 espaço do usuário de que algo aconteceu, retornar um novo descritor de
[all …]
|
| H A D | botching-up-ioctls.rst | 7 De: https://blog.ffwll.ch/2013/11/botching-up-ioctls.html
11 Uma percepção clara que os hackers de gráficos do kernel tiveram nos últimos
12 anos é que tentar criar uma interface unificada para gerenciar as unidades de
14 Portanto, hoje em dia, cada driver tem seu próprio conjunto de ioctls para
16 insanidade na forma de interfaces falsamente genéricas, mas que na verdade só
23 deveria ser exatamente a aparência da ioctl de envio de comando. Aprender essas
24 lições é provavelmente algo que cada driver de GPU tem que fazer por conta
32 adicionar uma camada de compatibilidade de 32 bits (compat layer):
34 * Use apenas inteiros de tamanho fixo. Para evitar conflitos com typedefs no
35 espaço de usuário (userspace), o kernel possui tipos especiais como __u32 e
[all …]
|
| H A D | 4.Coding.rst | 6 Embora haja muito o que se dizer sobre um processo de design sólido e orientado
7 à comunidade, a prova de qualquer projeto de desenvolvimento de kernel está no
12 Esta seção examinará o processo de codificação. Começaremos analisando uma série
13 de maneiras pelas quais os desenvolvedores de kernel podem errar. Em seguida, o
21 Estilo de Codificação
24 O kernel há muito possui um estilo de codificação padrão, descrito em
28 de código no kernel que não cumpre as diretrizes de estilo de codificação.
32 O primeiro deles é acreditar que os padrões de codificação do kernel não importam
34 difícil se esse código não estiver escrito de acordo com o padrão; muitos
35 desenvolvedores solicitarão que o código seja reformatado antes mesmo de
[all …]
|
| H A D | code-of-conduct-interpretation.rst | 3 Interpretação do Código de Conduta do Kernel Linux
7 fornecer um conjunto de regras para quase todas as comunidades de código
8 aberto. Toda comunidade de código aberto é única e o kernel Linux não é
14 O esforço de desenvolvimento do kernel Linux é um processo muito pessoal
15 em comparação com as formas "tradicionais" de desenvolvimento de software.
21 processo de desenvolvimento provou criar o kernel de sistema operacional
22 mais robusto de todos os tempos, e nós não queremos fazer nada que cause
28 O Código de Conduta usa o termo "mantenedores" várias vezes. Na
31 MAINTAINERS na árvore de código-fonte do kernel.
36 O Código de Conduta menciona direitos e responsabilidades para os
[all …]
|
| H A D | security-bugs.rst | 3 Falhas de segurança
7 gostaríamos de saber quando uma falha de segurança é encontrada para que ela
13 Como em qualquer relatório de bug, um relatório de falha de segurança exige
14 muito trabalho de análise por parte dos desenvolvedores, portanto, quanto mais
18 informações são absolutamente necessárias em **qualquer** relatório de falha de
21 * **versão do kernel afetada**: sem indicação de versão, seu relatório não
22 será processado. Uma parte significativa dos relatórios é de bugs que já
24 vulnerabilidades sejam verificadas em versões recentes (árvore de
32 * **reproduzir**: os desenvolvedores precisarão ser capazes de reproduzir o
34 maneira de acionar o problema quanto uma maneira de confirmar que ele
[all …]
|
| H A D | cve.rst | 8 como uma forma inequívoca de identificar, definir e catalogar vulnerabilidades
9 de segurança divulgadas publicamente. Com o tempo, sua utilidade diminuiu em
11 de formas inadequadas e por motivos inadequados. Por causa disso, a comunidade
12 de desenvolvimento do kernel tendeu a evitá-los. No entanto, a combinação da
13 pressão contínua para atribuir CVEs e outras formas de identificadores de
14 segurança, e abusos contínuos por indivíduos e empresas de fora da comunidade
18 A equipe de desenvolvedores do kernel Linux tem a capacidade de atribuir CVEs
19 para possíveis problemas de segurança do kernel Linux. Essa atribuição é
20 independente do processo normal de relato de bugs de segurança do kernel
23 Uma lista de todos os CVEs atribuídos ao kernel Linux pode ser encontrada nos
[all …]
|
| H A D | deprecated.rst | 4 Interfaces, recursos de linguagem, atributos e convenções obsoletos
7 Em um mundo perfeito, seria possível converter todas as instâncias de alguma
9 ciclo de desenvolvimento. No entanto, devido ao tamanho do kernel, à hierarquia
10 de manutenção e ao cronograma, nem sempre é viável realizar esse tipo de
11 conversão de uma só vez. Isso significa que novas instâncias podem acabar
13 o volume de trabalho para remover a API. A fim de instruir os desenvolvedores
14 sobre o que se tornou obsoleto e o porquê, esta lista foi criada para servir de
15 referência quando o uso de elementos obsoletos for proposto para inclusão no
24 ninguém estava de fato agindo para remover essas interfaces obsoletas. Embora o
25 uso de `__deprecated` seja útil para sinalizar uma API antiga em um arquivo de
[all …]
|
| H A D | 6.Followthrough.rst | 7 adição de suas próprias habilidades de engenharia, enviou uma série perfeita
8 de patches. Um dos maiores erros que até mesmo desenvolvedores experientes
10 Na verdade, o envio de patches indica uma transição para a próxima etapa
11 do processo, possivelmente com uma quantidade considerável de trabalho
15 melhorias. O processo de desenvolvimento do kernel reconhece esse fato e,
18 comunidade do kernel para garantir que seu código esteja de acordo com os
19 padrões de qualidade do kernel. A falha em participar desse processo muito
20 provavelmente impedirá a inclusão de seus patches na árvore principal
27 Um patch de qualquer relevância resultará em uma série de comentários de outros
30 de desenvolvimento do kernel. No entanto, a vida pode se tornar muito mais
[all …]
|
| H A D | 7.AdvancedTopics.rst | 6 Neste ponto, esperamos que você já tenha uma boa noção de como funciona o
7 processo de desenvolvimento. No entanto, ainda há mais a aprender! Esta seção
8 cobrirá uma série de tópicos que podem ser úteis para desenvolvedores que
9 desejam se tornar parte regular do processo de desenvolvimento do kernel Linux.
11 Gerenciamento de patches com o git
14 O uso de controle de versão distribuído para o kernel começou no início de
16 Embora o BitKeeper fosse controverso, a abordagem de gerenciamento de versão
17 de software que ele incorporava certamente não era. O controle de versão
18 distribuído permitiu uma aceleração imediata do projeto de desenvolvimento do
20 bem ou para o mal, o projeto do kernel adotou o git como sua ferramenta de
[all …]
|
| H A D | maintainer-netdev.rst | 4 Subsistema de Rede do Linux (netdev)
13 independentemente da árvore de destino.
16 - **Intervalo de envio** – não reenvie seus patches dentro de um período de 24
18 - **Reverse xmas tree** – organize as declarações de variáveis locais da mais
23 A **netdev** é a lista de discussão para todos os assuntos do Linux relacionados
25 como IPv6) e em ``drivers/net`` (ex: drivers específicos de hardware) na árvore
26 de diretórios do Linux.
28 Note que alguns subsistemas (ex: drivers de rede sem fio/wireless), que possuem
29 um alto volume de tráfego, possuem suas próprias listas de discussão e árvores
32 Como muitas outras listas de discussão do Linux, a lista netdev é hospedada no
[all …]
|
| H A D | contribution-maturity-model.rst | 4 Modelos de Maturidade para Contribuição no Kernel Linux
11 Como parte do Linux Kernel Maintainers’ Summit de 2021, houve uma
13 contratação de mantenedores do kernel, bem como a sucessão de mantenedores.
16 como mantenedores como parte de seu trabalho, para que possam crescer e se
18 apoiar um fluxo forte de talentos, os desenvolvedores devem ser autorizados e
19 incentivados a assumir contribuições no upstream, como revisar os patches de
23 Linux Foundation propõe este Modelo de Maturidade para Contribuição no Kernel
25 aumentar a influência de desenvolvedores individuais, aumentar a colaboração
26 de organizações e melhorar a saúde geral do ecossistema do Kernel Linux.
28 O TAB insta as organizações a avaliarem continuamente seu modelo de maturidade
[all …]
|
| H A D | 5.Posting.rst | 8 mainline. Sem surpresa, a comunidade de desenvolvimento do kernel evoluiu um
9 conjunto de convenções e procedimentos que são usados no envio de patches;
20 Existe uma tentação constante de evitar o envio de patches antes que eles
24 Portanto, você deve considerar o envio de trabalhos em andamento, ou até mesmo
32 que o fizerem virão com a ideia de que podem ajudá-lo a conduzir o trabalho na
36 Antes de criar patches
39 Há uma série de coisas que devem ser feitas antes de você considerar o envio
40 de patches para la comunidade de desenvolvimento. Elas incluem:
42 - Teste o código tanto quanto puder. Faça uso das ferramentas de depuração
44 razoáveis de opções de configuração, use compiladores cruzados (cross-
[all …]
|
| /linux/Documentation/translations/sp_SP/ |
| H A D | memory-barriers.txt | 13 BARRERAS DE MEMORIA EN EL KERNEL LINUX
22 Nota: Si tiene alguna duda sobre la exactitud del contenido de esta
31 de brevedad) y sin querer (por ser humanos) incompleta. Este documento
32 pretende ser una guía para usar las diversas barreras de memoria
34 pregunte. Algunas dudas pueden ser resueltas refiriéndose al modelo de
35 consistencia de memoria formal y documentación en tools/memory-model/. Sin
36 embargo, incluso este modelo debe ser visto como la opinión colectiva de
37 sus maintainers en lugar de que como un oráculo infalible.
39 De nuevo, este documento no es una especificación de lo que Linux espera
42 El propósito de este documento es doble:
[all …]
|