| /linux/Documentation/translations/sp_SP/process/ |
| H A D | management-style.rst | 12 Este es un documento breve que describe el estilo de gestión preferido (o
20 que reglas simples de estilo de codificación, por lo que este documento
22 eso no significa que no pueda ser realmente cierto. Tendrás que decidir
26 personas lideres técnicas, no de las personas que hacen la gestión
28 alguna idea sobre el presupuesto de tu grupo, es casi seguro que no eres
35 haciendo dolorosamente obvio para el interrogador que no tenemos ni idea
45 Todos piensan que los gerentes toman decisiones, y que la toma de
50 El nombre del partido es **evitar** tener que tomar una decisión. En
52 que decidas sobre esto”, estas en problemas como gerente. Es mejor que
53 las personas a las que diriges conozcan los detalles mejor que tú, así
[all …]
|
| H A D | handling-regressions.rst | 10 *No causamos regresiones* -- este documento describe la que es la "primera
11 regla del desarrollo del kernel de Linux" y que implica en la práctica para
13 Documentation/admin-guide/reporting-regressions.rst, que cubre el tema
20 #. Asegúrese de que los suscriptores a la lista `regression mailing list
24 * Cuando se reciba un correo que no incluyó a la lista, inclúyalo en la
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
37 como el siguiente, lo que le indica a regzbot cuando empezó a suceder
69 Asegúrese de que el programa de gestión de regresiones del kernel de Linux
74 * Cuando se recibe un informe por email que no tiene en CC la lista,
[all …]
|
| H A D | 1.Intro.rst | 15 kernel y los tipos de frustraciones que los desarrolladores y sus
16 empleadores pueden encontrar allí. Hay muchas razones por las que el
27 herramientas y listas de correo. Se anima a los desarrolladores que deseen
38 las herramientas que pueden ayudar a garantizar que los parches del kernel
47 :ref:`sp_development_followthrough` cubre lo que sucede después de publicar
51 etapa. Se advierte a los desarrolladores que no asuman que el trabajo está
66 libre más grandes y activos que existen. Desde sus humildes comienzos en
68 del sistema operativo que se ejecuta en reproductores de música digital
69 de bolsillo, PC de escritorio, las supercomputadoras más grandes que
74 desarrolladores (y empresas) que desean participar en su desarrollo. Los
[all …]
|
| H A D | 2.Process.rst | 15 ha tenido que adaptar varios procesos para mantener el desarrollo sin
41 continuo que está integrando continuamente cambios importantes.
45 se dice que la "merge window" (ventana de fusión) está abierta. En ese
46 momento, el código que se considera lo suficientemente estable (y que es
53 (Aparte, vale la pena señalar que los cambios integrados durante la
59 tiempo, Linux Torvalds declarará que la ventana está cerrada y publicará
62 5.6-rc1. El lanzamiento -rc1 señala que el tiempo para fusionar nuevas
63 características ha pasado y que el tiempo para estabilizar el siguiente
66 Durante las próximas seis a diez semanas, solo los parches que solucionen
68 más significativo, pero tales ocasiones son raras; los desarrolladores que
[all …]
|
| H A D | howto.rst | 18 este archivo, que se encuentra en la parte superior del documento.
22 ¿De modo que quiere descubrir como convertirse en un/a desarrollador/a del
26 que debe pasar, y con indicaciones de como trabajar con la comunidad.
28 de la forma en que lo hace.
30 El kernel esta principalmente escrito en C, con algunas partes que son
33 cualquier arquitectura) no es necesario excepto que planee realizar
43 bien se adhiere al estándar ISO C89, utiliza una serie de extensiones que
45 sin depender de la biblioteca C estándar, por lo que algunas partes del
48 entender las suposiciones que el kernel hace respecto a la cadena de
49 herramientas y las extensiones que usa, y desafortunadamente no hay
[all …]
|
| H A D | maintainer-kvm-x86.rst | 14 normas/directrices que contiene. Todos cometemos errores y todos hemos sido
17 aprenda de los errores que cometa, será recibido con los brazos abiertos,
34 directamente al árbol principal de KVM, mientras que todo el desarrollo
36 improbable caso de que una corrección para el ciclo actual se dirija a
40 Tenga en cuenta que se espera que este periodo de transición dure bastante
41 tiempo, es decir, que será el statu quo en un futuro previsible.
50 en en camino, y tener que rechazar una solicitud de pull debido a errores
66 temática de KVM x86, normalmente la semana antes de que Linus abra la
80 margen de maniobra en función del tamaño de la serie, los parches que están
82 actual y/o árboles estables, consiguen saltar la cola. Los parches que se
[all …]
|
| H A D | deprecated.rst | 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
25 Mientras que este atributo señala visualmente que un interface ha sido
28 porque uno de los objetivos del kernel es que compile sin avisos, y
30 que usar `__deprecated` es sencillo para anotar una API obsoleta en
38 "imposibles" tan elegantemente como se pueda. Mientras que la familia de
50 Nótese que la familia de funciones WARN() únicamente debería ser usada
51 en situaciones que se "esperan no sean alcanzables". Si se quiere
54 *panic_on_warn* sysctl para asegurarse que sus sistemas no continúan
[all …]
|
| H A D | security-bugs.rst | 12 seguridad para que pueda ser corregido y divulgado lo más rápido posible.
21 oficiales de seguridad que ayudarán a verificar el informe del error y
23 favor, inclúyala con su informe, ya que eso puede acelerar considerablemente
24 el proceso. Es posible que el equipo de seguridad traiga ayuda adicional
31 si no tiene claro que información es útil. Cualquier código de explotación
33 que envia el error) a menos que ya se haya hecho público.
48 Coordinación debajo. Una vez que se ha desarrollado una solución robusta,
56 a 14 días de calendario si se acuerda que la criticalidad del error requiere
59 escala que requieren coordinación de lanzamiento.
71 que se haya levantado el embargo, en perpetuidad.
[all …]
|
| /linux/Documentation/translations/pt_BR/process/ |
| H A D | management-style.rst | 13 que simples regras de estilo de codificação, então este documento pode ou não ter
15 significa que não possa ser verdade. Você terá que decidir por si mesmo.
18 técnicas, e não das pessoas que fazem gerenciamento tradicional dentro das empresas.
27 dolorosamente óbvio para o questionador que não temos ideia de qual é a resposta.
36 Todo mundo pensa que os gerentes tomam decisões, e que a tomada de decisões é
40 O nome do jogo é **evitar** ter que tomar uma decisão. Em particular, se alguém
41 lhe disser "escolha (a) ou (b), realmente precisamos que você decida sobre isso",
42 você está em apuros como gerente. As pessoas que você gerencia devem conhecer os
43 detalhes melhor do que você, então se elas vierem até você para uma decisão técnica,
46 (Consequência: Se as pessoas que você gerencia não conhecem os detalhes melhor
[all …]
|
| H A D | 6.Followthrough.rst | 8 de patches. Um dos maiores erros que até mesmo desenvolvedores experientes
9 do kernel podem cometer é concluir que o seu trabalho agora está concluído.
14 É raro um patch ser tão bom em seu primeiro envio que não haja margem para
17 enviado. Espera-se que você, como autor desse código, trabalhe junto à
18 comunidade do kernel para garantir que seu código esteja de acordo com os
28 desenvolvedores à medida que eles revisam o código. Trabalhar com revisores
37 mudanças que podem lhe pedir para fazer — desde ajustes de estilo de código
38 até reescritas substanciais — vêm do entendimento de que o Linux ainda estará
43 fama duradoura para aqueles que o revisaram. Portanto, os revisores podem
45 repetidamente. Se você receber uma revisão que pareça irritada, insultuosa
[all …]
|
| H A D | 5.Posting.rst | 6 Cedo ou tarde, chega o momento em que seu trabalho está pronto para ser
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
22 No entanto, se o trabalho que está sendo feito for complexo, há muito a se
23 ganhar obtendo feedback da comunidade antes que o trabalho esteja concluído.
25 disponibilizar uma árvore git para que os desenvolvedores interessados possam
28 Ao enviar um código que ainda não é considerado pronto para inclusão, é uma boa
30 que ainda precise ser feito e quaisquer problemas conhecidos. Menos pessoas vão
31 olhar para patches que sabidamente estão "meio cozidos" (half-baked), mas aqueles
32 que o fizerem virão com a ideia de que podem ajudá-lo a conduzir o trabalho na
[all …]
|
| H A D | 4.Coding.rst | 6 Embora haja muito o que se dizer sobre um processo de design sólido e orientado
8 código resultante. É o código que será examinado por outros desenvolvedores e
10 deste código que determinará o sucesso final do projeto.
14 foco mudará para como fazer as coisas do jeito certo e as ferramentas que podem
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
33 e não são exigidos. A verdade é que adicionar novo código ao kernel é muito
35 desenvolvedores solicitarão que o código seja reformatado antes mesmo de
37 uniformidade para tornar possível que os desenvolvedores entendam rapidamente
42 estilo exigido por um empregador. Nesses casos, o estilo do kernel terá que
[all …]
|
| H A D | backporting.rst | 21 e existem muitas técnicas úteis que você pode usar para tornar o processo mais
30 Às vezes, o patch que você está fazendo backport já existe como um commit do
31 git, caso em que você apenas faz o cherry-pick dele diretamente usando
36 Se você já usou o ``git am``, provavelmente já sabe que ele é bastante exigente
43 árvore de destino, pois isso fará com que o git exiba marcadores de conflito e
44 permitirá que você resolva os conflitos com a ajuda do git e de quaisquer outras
45 ferramentas de resolução de conflitos que preferir usar. Por exemplo, se você
46 quiser aplicar um patch que acabou de chegar na LKML a um kernel estável mais
51 gerado, mas isso não importa tanto, desde que ele se aplique de forma limpa e
53 base "errada" é que isso pode trazer mais alterações não relacionadas no
[all …]
|
| H A D | applying-patches.rst | 16 uma das muitas árvores/branches deve ser aplicado. Esperamos que este documento
24 O que é um Patch?
27 Um patch é um pequeno documento de texto que contém uma diferença (delta) de
44 Os patches para o kernel Linux são gerados relativamente ao diretório pai que
47 Isso significa que os caminhos para os arquivos dentro do arquivo de patch
51 Como é improvável que isso corresponda ao nome do diretório do código-fonte do
80 conhecer mais do que uma maneira de usar o patch, então você pode parar a
96 aplicá-lo (o que presumo que você tenha feito nos exemplos abaixo), basta
102 O que deixará você com um arquivo patch-x.y.z em texto puro que você pode
105 Alguns outros argumentos úteis para o patch são ``-s``, que faz com que o patch
[all …]
|
| H A D | security-bugs.rst | 7 gostaríamos de saber quando uma falha de segurança é encontrada para que ela
22 será processado. Uma parte significativa dos relatórios é de bugs que já
23 foram corrigidos, portanto, é extremamente importante que as
29 mostrando sua manifestação, e por que você considera o comportamento
34 maneira de acionar o problema quanto uma maneira de confirmar que ele
39 sem o consentimento do relator, a menos que já sejam públicos. Por
50 se suspeita que o bug esteja presente são muito importantes, pelo menos
52 não for possível (por exemplo, "o sistema trava toda vez que executo este
55 * **uma proposta de correção**: os relatores de bugs que analisaram a causa
59 mantenedores, mesmo que a correção acabe não sendo a correta, pois ajuda a
[all …]
|
| H A D | 7.AdvancedTopics.rst | 6 Neste ponto, esperamos que você já tenha uma boa noção de como funciona o
8 cobrirá uma série de tópicos que podem ser úteis para desenvolvedores que
17 de software que ele incorporava certamente não era. O controle de versão
24 especialmente à medida que o volume desses patches cresce. O git também tem suas
25 pontas soltas e apresenta certos riscos; é uma ferramenta jovem e poderosa que
30 que desejam se atualizar com o git encontrarão mais informações em:
40 outros. Um desenvolvedor que utiliza o git deve ser capaz de obter uma cópia do
52 Quando estiver pronto para começar a disponibilizar árvores git para que outros
65 em nenhuma branch a partir da qual pretenda pedir para que outros deem pull.
70 O git fornece algumas ferramentas poderosas que podem permitir que você
[all …]
|
| H A D | deprecated.rst | 11 conversão de uma só vez. Isso significa que novas instâncias podem acabar
14 sobre o que se tornou obsoleto e o porquê, esta lista foi criada para servir de
36 demais. (Por exemplo: "Em que ordem os bloqueios precisam ser liberados? Os
38 desestabilizar o sistema ou travá-lo por completo, o que torna impossível
45 Note que a família WARN() só deve ser usada para situações que "espera-se que
46 sejam inacessíveis". Se você quiser alertar sobre situações que são
49 garantir que seus sistemas não continuem executando diante de condições
58 que os valores dessem a volta (*wrap around*), resultando em uma alocação menor
59 do que o esperado pelo chamador. O uso dessas alocações pode levar a estouros
91 .. note:: Se você estiver usando struct_size() em uma estrutura que contém uma
[all …]
|
| H A D | botching-up-ioctls.rst | 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
15 alocar memória e enviar trabalho para a GPU. O que é bom, já que não há mais a
16 insanidade na forma de interfaces falsamente genéricas, mas que na verdade só
17 são usadas uma vez. No entanto, a desvantagem clara é que há muito mais
24 lições é provavelmente algo que cada driver de GPU tem que fazer por conta
47 tamanho da estrutura, o que o core do drm, por exemplo, faz.
52 isso diminui a verificação que ferramentas como o sparse podem fornecer. A
68 puder confiar que os kernels antigos rejeitarão as novas flags/modos ou
69 ioctls (já que fazer isso foi deixado de lado no passado), então você
[all …]
|
| H A D | maintainer-netdev.rst | 28 Note que alguns subsistemas (ex: drivers de rede sem fio/wireless), que possuem
58 Para descobrir em que ponto do ciclo estamos agora - carregue a página da
90 a netdev, mas sabendo o que foi dito acima, você pode prever isso com
96 em que a árvore ``net-next`` estiver fechada.
114 que o foco da ``net`` é a estabilização e correções de bugs.
136 (dependendo do co-mantenedor exato que estiver lidando
147 Not applicable espera-se que o patch seja aplicado fora do
150 apropriado, que o enviará para as árvores de rede;
166 Os patches são indexados pelo cabeçalho ``Message-ID`` dos e-mails que os
179 simples (bot) que procura por comandos/linhas especiais dentro dos e-mails
[all …]
|
| H A D | code-of-conduct-interpretation.rst | 6 O :ref:`pt_BR_code_of_conduct` é um documento geral que tem como objetivo
10 do kernel Linux, o interpretaremos. Nós também não esperamos que esta
18 revisão quase sempre exigirá melhorias antes que o material possa ser
19 incluído no kernel. Saiba que isso acontece porque todos os envolvidos
22 mais robusto de todos os tempos, e nós não queremos fazer nada que cause
30 um subsistema, driver ou arquivo, e que esteja listada no arquivo
39 Em primeiro lugar e acima de tudo, é uma expectativa razoável que os
43 para que os mantenedores lidem unilateralmente com o comportamento de
53 que surgirem. Isso não será considerado um relato de violação, a menos
54 que você queira que seja. Se não tiver certeza sobre como abordar o TAB
[all …]
|
| H A D | cve.rst | 15 do kernel, deixou claro que a comunidade do kernel deve controlar
32 Como parte do processo normal de lançamento estável, alterações do kernel que
38 Observe que, devido à camada em que o kernel Linux se encontra em um sistema,
42 cautelosa e atribui números CVE a qualquer correção de bug que identificar.
46 Se a equipe de atribuição de CVEs deixar passar uma correção específica que
47 qualquer usuário considere que deveria receber um CVE, por favor envie um
49 que nenhum possível problema de segurança deve ser enviado para esse alias;
50 ele é SOMENTE para atribuição de CVEs a correções que já estejam em árvores de
58 depois que uma correção estiver disponível e aplicada a uma árvore de kernel
60 original. Se alguém desejar que um CVE seja atribuído antes que um problema
[all …]
|
| H A D | adding-syscalls.rst | 7 Este documento descreve o que está envolvido na adição de uma nova chamada de
19 usuário (userspace) e o kernel, existem outras possibilidades -- escolha o que
25 funcionalidade em um módulo de kernel, em vez de exigir que ela seja
28 - Se a nova funcionalidade envolver operações em que o kernel notifica o
29 espaço do usuário de que algo aconteceu, retornar um novo descritor de
30 arquivo (file descriptor) para o objeto relevante permite que o espaço
33 - No entanto, as operações que não se mapeiam para operações do tipo
35 requisições :manpage:`ioctl(2)`, o que pode levar a uma API um tanto
41 a esses mecanismos exige que o sistema de arquivos relevante esteja montado,
42 o que pode não ser sempre o caso (por exemplo, em um ambiente com namespaces,
[all …]
|
| /linux/Documentation/translations/sp_SP/ |
| H A D | memory-barriers.txt | 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
44 (1) especificar la funcionalidad mínima en la que se puede confiar para
49 Tenga en cuenta que una arquitectura puede proporcionar más que el
53 Tenga en cuenta también que es posible que una barrera no valga (sea no-op)
54 para alguna arquitectura porque por la forma en que funcione dicha
110 (*) Cosas que hacen las CPU.
151 Cada CPU ejecuta un programa que genera operaciones de acceso a la memoria.
154 en el orden que desee, siempre que la causalidad del programa parezca
156 instrucciones que emite en el orden que quiera, siempre que no afecte al
[all …]
|
| H A D | index.rst | 18 aquellos que no entiendan inglés o duden de sus interpretaciones, o
19 simplemente para aquellos que prefieran leer en el idioma español. Sin
20 embargo, tenga en cuenta que la *única* documentación oficial es la que
26 es posible. Por tanto, no existe ninguna garantía de que una traducción
27 esté actualizada con las últimas modificaciones. Si lo que lee en una
28 traducción no se corresponde con lo que ve en el código fuente, informe
33 lo que los usuarios no encontrarán aquí ninguna información que no sea la
38 contribuciones que son puramente de interés relativo a la traducción (por
56 los maintainers pueden utilizar el español con el que dichos maintainers se
65 La traducción es incompleta, y podría encontrar advertencias que indiquen
[all …]
|
| /linux/Documentation/translations/sp_SP/scheduler/ |
| H A D | sched-eevdf.rst | 20 de la CPU de forma equitativa entre todas las tareas que tengan la misma
22 ejecución virtual a cada tarea, creando un "retraso" que puede ser usado
25 positivo, es porque se le debe tiempo de ejecución, mientras que una
26 con "retraso" negativo implica que la tarea ha excedido su cuota de
30 ser ejecutada a continuación. Es importante darse cuenta que esto permite
31 que la tareas que sean sensibles a la latencia que tengan porciones de
36 en tareas que estén en un estado durmiente; pero en el momento en el que
42 a su retraso decaer a lo largo de VRT. Por tanto, las tareas que duerman
47 que sean sensibles a las latencias.
|