| /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 | submitting-patches.rst | 11 Para una persona o empresa que desee enviar un cambio al kernel Linux,
14 que pueden aumentar considerablemente las posibilidades de que se acepte su
26 Esta documentación asume que está usando ``git`` para preparar sus parches.
27 Si no está familiarizado con ``git``, le recomendamos que aprenda a
40 que se puede descargar con::
44 Tenga en cuenta, sin embargo, que es posible que no desee desarrollar con
58 subyacente que le motivó a hacer ese trabajo. Convenza al revisor de que
59 hay un problema que merece la pena solucionar y de que tiene sentido que
62 Describa el impacto relativo al usuario. Cosas que estropeen el kernel y
65 código, describa el impacto que cree pueda tener en los usuarios. Tenga en
[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 | coding-style.rst | 11 Este es un breve documento que describe el estilo preferido en el código
13 puntos de vista sobre nadie, pero esto vale para todo lo que tengo que
14 mantener, y preferiría que para la mayoría de otras cosas también. Por
27 tienen 8 caracteres. Hay movimientos heréticos que intentan hacer sangría
36 Bueno, algunas personas dirán que tener sangrías de 8 caracteres hace que
38 pantalla de terminal de 80 caracteres. La respuesta a eso es que si
70 No ponga varias declaraciones en una sola línea a menos que tenga algo que
108 El estilo de código tiene todo que ver con la legibilidad y la
114 que exceder las 80 columnas aumente significativamente la legibilidad y no
117 Los descendientes siempre son sustancialmente más cortos que el padre y
[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 | adding-syscalls.rst | 13 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` que
22 tradicionales, existen otras posibilidades -- elija la que mejor se adecúe
25 - Si se puede hacer que la operación se parezca a un objeto filesystem,
28 funcionalidad en un módulo del kernel en vez de requerir que sea
32 notifica al userspace que algo ha pasado, entonces retornar un nuevo
36 - Sin embargo, operaciones que no mapean a operaciones similares a
37 :manpage:`read(2)`/:manpage:`write(2)` tienen que ser implementadas
44 requiere que el filesystem relevante esté montado, lo que podría no ser
46 Evite agregar cualquier API a debugfs, ya que no se considera una
52 llamada al sistema multiplexada que esconde mucha complejidad, así que
[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 …]
|
| H A D | submit-checklist.rst | 11 Aquí hay algunas cosas básicas que los desarrolladores deben hacer si
12 quieren que sus envíos de parches del kernel sean aceptados más
15 Todo esto está más allá de la documentación que se proporciona en
19 1) Si utiliza una funcionalidad, #include el archivo que define/declara
20 esa funcionalidad. No dependa de otros archivos de encabezado que
21 extraigan los que utiliza.
42 por que tiende a usar ``unsigned long`` para cantidades de 64-bits.
48 Debería ser capaz de justificar todas las infracciones que permanezcan
52 configuración y se desactiva por defecto, a menos que cumpla con los
64 10) Use ``make checkstack`` y solucione cualquier problema que encuentre.
[all …]
|
| H A D | embargoed-hardware-issues.rst | 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.
42 seguridad que lo ayudarán a coordinar un problema de acuerdo con nuestro
56 investigadores o individuos que hayan identificado una posible falla de
71 Las listas de correo encriptadas que se utilizan en nuestro proceso están
110 (expertos en dominio) que formarán el equipo de respuesta inicial para un
122 que ocurra una violación, el equipo de seguridad de hardware informará a
145 afectado, le animamos a considerar también que otro hardware podría estar
149 encriptada específica para el incidente que se utilizará para la discusión
[all …]
|
| H A D | kernel-enforcement-statement.rst | 19 asegurar que las acciones individuales para proteger estos se lleven a cabo
20 de una manera que beneficia a nuestra comunidad y no tenga un indeseado
23 en que es en el mejor interés de nuestro desarrollo como comunidad asumir
28 que es en el mejor interés de nuestra comunidad de desarrollo adoptar
36 a menos que y hasta que el titular de los derechos de autor explícita
44 vez que ha recibido notificación de violación de esta Licencia (para
49 del software. Queremos que empresas y particulares utilicen, modifiquen y
52 expectativas con respecto al cumplimiento que podría limitar la adopción de
53 nuestro software. Entendemos la acción legal como último recurso, que se
57 Finalmente, una vez que se resuelva un problema de incumplimiento,
[all …]
|
| H A D | contribution-maturity-model.rst | 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
21 trabajo, para que puedan convertirse en lideres respetados y finalmente,
59 * Se espera que los ingenieros de software contribuyan al kernel de Linux
69 * Se espera que los ingenieros de software revisen los parches (incluidos
82 métricas que se sugieren encarecidamente incluyen:
85 organización (por ejemplo, todas las personas que reportan a un
87 * El porcentaje de desarrolladores del kernel que han realizado
92 upstream en el que se basa el kernel interno.
100 trabajo centrado en el Trabajo Ascendente, que se define como revisar
|
| H A D | kernel-docs.rst | 15 Afortunadamente, a medida que más y más gente accede a GNU/Linux, más
20 Desafortunadamente, no existen muchos documentos disponibles para que los
22 "conocido" que les pudiera seguir la pista. Estas líneas tratan de cubrir
25 POR FAVOR, si conoce algún documento que no figura aquí, o si escribe un
51 :Descripción: Documentación que viene con las fuentes del kernel,
54 estar más actualizadas que la versión web.
130 :Descripción: Otro navegador de código fuente del kernel Linux que se
162 'novato'. La audiencia se compone principalmente de personas que
164 o hackers profesionales del kernel que quieren ayudar a la gente
|
| H A D | code-of-conduct.rst | 21 maneras que contribuyan a una comunidad abierta, acogedora, diversa,
27 Ejemplos de comportamiento que contribuyen a crear un ambiente positivo
35 * Centrarse en lo que sea mejor no sólo para nosotros como individuos, sino
49 * Otras conductas que puedan ser razonablemente consideradas como
59 comportamiento que consideren inapropiado, amenazante, ofensivo o dañino.
63 páginas de wiki, issues y otras contribuciones que no se alineen con este
|
| H A D | researcher-guidelines.rst | 23 Este documento busca clarificar lo que la comunidad del kernel de Linux
36 La comunidad del kernel de Linux espera que todos los que interactúan con
43 La investigación pasiva que se basa completamente en fuentes disponibles
69 cuando se trata de desarrollar o ejecutar herramientas de análisis que
74 Linux ya tiene muchos errores conocidos – lo que es mucho más útil es
87 * ¿Cuál es el problema específico que se ha encontrado?
136 Si usted es un colaborador por primera vez, se recomienda que el parche en
138 públicas. (Esto es necesario si se le ha dicho explícitamente que sus parches
139 necesitan una revisión interna más cuidadosa.) Se espera que estas personas
|
| H A D | magic-number.rst | 11 Este archivo es un registro de los números mágicos que están en uso. Cuando
13 este documento, ya que es mejor si los números mágicos utilizados por
35 complicados donde una matriz ha sido invadida y las estructuras que siguen
51 estamos en fase de "feature freeze", es muy poco probable que
60 freeze, pero es posible que algunos nuevos números mágicos se cuelen en
|
| /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 …]
|
| /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.
|
| H A D | sched-design-CFS.rst | 26 "una CPU multitarea ideal" es una CPU (inexistente :-)) que tiene un 100%
27 de potencia y que puede ejecutar cualquier tarea exactamente a la misma
32 En hardware real, se puede ejecutar una única tarea a la vez, así que
47 de CPU esperado" que una tarea debería tener.
56 p->se.vruntime más pequeño (i.e., la tarea que se ha ejecutado menos hasta el
74 artificio de "cambio de tareas" (algo que previamente era usado por el gestor
86 de esas tareas que están en la cola de ejecución.
89 tareas que pueden ser ejecutadas están ordenadas por su valor de
93 de forma continuada dando una oportunidad a cada tarea de ser la que
99 que el tiempo de uso de la CPU se ha completado, y se añade a
[all …]
|
| /linux/drivers/infiniband/hw/bnxt_re/ |
| H A D | qplib_fp.h | 373 static inline bool bnxt_qplib_queue_full(struct bnxt_qplib_q *que, in bnxt_qplib_queue_full() argument
379 hwq = &que->hwq; in bnxt_qplib_queue_full()
598 static inline void *bnxt_qplib_get_swqe(struct bnxt_qplib_q *que, u32 *swq_idx) in bnxt_qplib_get_swqe() argument
602 idx = que->swq_start; in bnxt_qplib_get_swqe()
605 return &que->swq[idx]; in bnxt_qplib_get_swqe()
608 static inline void bnxt_qplib_swq_mod_start(struct bnxt_qplib_q *que, u32 idx) in bnxt_qplib_swq_mod_start() argument
610 que->swq_start = que->swq[idx].next_idx; in bnxt_qplib_swq_mod_start()
613 static inline u32 bnxt_qplib_get_depth(struct bnxt_qplib_q *que, u8 wqe_mode, bool is_sq) in bnxt_qplib_get_depth() argument
618 slots = (que->wqe_size * que->max_wqe) / sizeof(struct sq_sge); in bnxt_qplib_get_depth()
625 static inline u32 bnxt_qplib_set_sq_size(struct bnxt_qplib_q *que, u8 wqe_mode) in bnxt_qplib_set_sq_size() argument
[all …]
|
| /linux/drivers/scsi/qedi/ |
| H A D | qedi_debugfs.c | 136 struct global_queue *que = NULL; in qedi_gbl_ctx_show() local
153 que = qedi->global_queues[fp->sb_id]; in qedi_gbl_ctx_show()
154 seq_printf(s, "DRV CONS IDX: %d\n", que->cq_cons_idx); in qedi_gbl_ctx_show()
|
| /linux/drivers/atm/ |
| H A D | iphase.c | 98 static void ia_init_rtn_q (IARTN_Q *que) in ia_init_rtn_q() argument
100 que->next = NULL; in ia_init_rtn_q()
101 que->tail = NULL; in ia_init_rtn_q()
104 static void ia_enque_head_rtn_q (IARTN_Q *que, IARTN_Q * data) in ia_enque_head_rtn_q() argument
107 if (que->next == NULL) in ia_enque_head_rtn_q()
108 que->next = que->tail = data; in ia_enque_head_rtn_q()
110 data->next = que->next; in ia_enque_head_rtn_q()
111 que->next = data; in ia_enque_head_rtn_q()
116 static int ia_enque_rtn_q (IARTN_Q *que, struct desc_tbl_t data) { in ia_enque_rtn_q() argument
122 if (que->next == NULL) in ia_enque_rtn_q()
[all …]
|