/linux-6.12.1/drivers/net/ethernet/dec/tulip/ |
D | de2104x.c | 327 static void de_tx (struct de_private *de); 328 static void de_clean_rings (struct de_private *de); 329 static void de_media_interrupt (struct de_private *de, u32 status); 332 static unsigned int de_ok_to_advertise (struct de_private *de, u32 new_media); 366 #define dr32(reg) ioread32(de->regs + (reg)) 367 #define dw32(reg, val) iowrite32((val), de->regs + (reg)) 370 static void de_rx_err_acct (struct de_private *de, unsigned rx_tail, in de_rx_err_acct() argument 373 netif_dbg(de, rx_err, de->dev, in de_rx_err_acct() 380 netif_warn(de, rx_err, de->dev, in de_rx_err_acct() 383 de->dev->stats.rx_length_errors++; in de_rx_err_acct() [all …]
|
/linux-6.12.1/Documentation/translations/sp_SP/process/ |
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 …]
|
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 …]
|
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 …]
|
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 …]
|
D | adding-syscalls.rst | 12 al kernel Linux, más allá de la presentación y consejos normales en 21 son los puntos de interacción entre el userspace y el kernel más obvios y 26 podría tener más sentido crear un nuevo sistema de ficheros o 28 funcionalidad en un módulo del kernel en vez de requerir que sea 33 descriptor de archivo para el objeto relevante permite al userspace 47 interfaz (interface) de 'producción' para el userspace. 49 - Si la operación es específica a un archivo o descriptor de archivo 50 específico, entonces la opción de comando adicional :manpage:`fcntl(2)` 56 un descriptor de archivo). 70 explícitamente el interface en las listas de correo del kernel, y es [all …]
|
D | coding-style.rst | 12 del kernel Linux. El estilo de código es muy personal y no **forzaré** mi 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 17 En primer lugar, sugeriría imprimir una copia de los estándares de código 28 de 4 (¡o incluso 2!) caracteres de longitud, y eso es similar a tratar de 29 definir el valor de PI como 3. 31 Justificación: La idea detrás de la sangría es definir claramente dónde 32 comienza y termina un bloque de control. Especialmente, cuando ha estado 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 [all …]
|
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 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. 31 dependientes de la arquitectura en ensamblador. Un buen conocimiento de C [all …]
|
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 …]
|
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 …]
|
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 …]
|
D | submitting-patches.rst | 8 Envío de parches: la guía esencial para incluir su código en el kernel 13 familiarizado con "el sistema". Este texto es una colección de sugerencias 14 que pueden aumentar considerablemente las posibilidades de que se acepte su 17 Este documento contiene una gran cantidad de sugerencias en un formato 19 funciona el proceso de desarrollo del kernel, consulte 21 Documentation/process/submit-checklist.rst para obtener una lista de 22 elementos a verificar antes de enviar código. Para los parches de 23 "binding" del árbol de dispositivos, lea 31 Algunos subsistemas y árboles de mantenimiento cuentan con información 32 adicional sobre su flujo de trabajo y expectativas, consulte [all …]
|
D | code-of-conduct.rst | 8 Código de Conducta para Contribuyentes 15 a hacer de la participación en nuestra comunidad una experiencia libre de 16 acoso para todo el mundo, independientemente de la edad, dimensión corporal, 18 identidad y expresión de género, nivel de experiencia, educación, nivel 20 identidad u orientación sexual. Nos comprometemos a actuar e interactuar de 27 Ejemplos de comportamiento que contribuyen a crear un ambiente positivo 31 * Respeto a diferentes opiniones, puntos de vista y experiencias 34 por nuestros errores, aprendiendo de la experiencia 39 Ejemplos de comportamiento inaceptable: 41 * El uso de lenguaje o imágenes sexualizadas, y aproximaciones o [all …]
|
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 …]
|
/linux-6.12.1/fs/hpfs/ |
D | dnode.c | 14 struct hpfs_dirent *de; in get_pos() local 17 for (de = dnode_first_de(d); de < de_end; de = de_next_de(de)) { in get_pos() 18 if (de == fde) return ((loff_t) le32_to_cpu(d->self) << 4) | (loff_t)i; in get_pos() 122 struct hpfs_dirent *de, *de_end, *dee = NULL, *deee = NULL; in dnode_pre_last_de() local 124 for (de = dnode_first_de(d); de < de_end; de = de_next_de(de)) { in dnode_pre_last_de() 125 deee = dee; dee = de; in dnode_pre_last_de() 132 struct hpfs_dirent *de, *de_end, *dee = NULL; in dnode_last_de() local 134 for (de = dnode_first_de(d); de < de_end; de = de_next_de(de)) { in dnode_last_de() 135 dee = de; in dnode_last_de() 142 struct hpfs_dirent *de; in set_last_pointer() local [all …]
|
/linux-6.12.1/fs/nilfs2/ |
D | dir.c | 216 nilfs_match(int len, const unsigned char *name, struct nilfs_dir_entry *de) in nilfs_match() argument 218 if (len != de->name_len) in nilfs_match() 220 if (!de->inode) in nilfs_match() 222 return !memcmp(name, de->name, len); in nilfs_match() 248 struct nilfs_dir_entry *de; in nilfs_readdir() local 257 de = (struct nilfs_dir_entry *)(kaddr + offset); in nilfs_readdir() 260 for ( ; (char *)de <= limit; de = nilfs_next_entry(de)) { in nilfs_readdir() 261 if (de->rec_len == 0) { in nilfs_readdir() 266 if (de->inode) { in nilfs_readdir() 269 t = fs_ftype_to_dtype(de->file_type); in nilfs_readdir() [all …]
|
/linux-6.12.1/Documentation/translations/sp_SP/ |
D | memory-barriers.txt | 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: 51 arquitectura proporciona menos de eso, dicha arquitectura es incorrecta. [all …]
|
/linux-6.12.1/Documentation/translations/sp_SP/scheduler/ |
D | sched-design-CFS.rst | 9 Gestor de tareas CFS 15 CFS viene de las siglas en inglés de "Gestor de tareas totalmente justo" 16 ("Completely Fair Scheduler"), y es el nuevo gestor de tareas de escritorio 18 del previo gestor de tareas SCHED_OTHER. Hoy en día se está abriendo camino 19 para el gestor de tareas EEVDF, cuya documentación se puede ver en 22 El 80% del diseño de CFS puede ser resumido en una única frase: CFS 27 de potencia y que puede ejecutar cualquier tarea exactamente a la misma 29 tareas ejecutándose, entonces cada una usa un 50% de la potencia --- es decir, 33 se ha usado el concepto de "tiempo de ejecución virtual". El tiempo 34 de ejecución virtual de una tarea específica cuando la siguiente porción [all …]
|
/linux-6.12.1/fs/ufs/ |
D | dir.c | 36 const unsigned char *name, struct ufs_dir_entry *de) in ufs_match() argument 38 if (len != ufs_get_de_namlen(sb, de)) in ufs_match() 40 if (!de->d_ino) in ufs_match() 42 return !memcmp(name, de->d_name, len); in ufs_match() 72 struct ufs_dir_entry *de; in ufs_inode_by_name() local 75 de = ufs_find_entry(dir, qstr, &folio); in ufs_inode_by_name() 76 if (de) { in ufs_inode_by_name() 77 res = fs32_to_cpu(dir->i_sb, de->d_ino); in ufs_inode_by_name() 78 folio_release_kmap(folio, de); in ufs_inode_by_name() 85 void ufs_set_link(struct inode *dir, struct ufs_dir_entry *de, in ufs_set_link() argument [all …]
|
/linux-6.12.1/fs/ext2/ |
D | dir.c | 217 struct ext2_dir_entry_2 * de) in ext2_match() argument 219 if (len != de->name_len) in ext2_match() 221 if (!de->inode) in ext2_match() 223 return !memcmp(name, de->name, len); in ext2_match() 238 ext2_dirent *de = (ext2_dirent*)(base + offset); in ext2_validate_entry() local 240 while ((char*)p < (char*)de) { in ext2_validate_entry() 248 static inline void ext2_set_de_type(ext2_dirent *de, struct inode *inode) in ext2_set_de_type() argument 251 de->file_type = fs_umode_to_ftype(inode->i_mode); in ext2_set_de_type() 253 de->file_type = 0; in ext2_set_de_type() 276 ext2_dirent *de; in ext2_readdir() local [all …]
|
/linux-6.12.1/fs/sysv/ |
D | dir.c | 90 struct sysv_dir_entry *de; in sysv_readdir() local 96 de = (struct sysv_dir_entry *)(kaddr+offset); in sysv_readdir() 98 for ( ;(char*)de <= limit; de++, ctx->pos += sizeof(*de)) { in sysv_readdir() 99 char *name = de->name; in sysv_readdir() 101 if (!de->inode) in sysv_readdir() 105 fs16_to_cpu(SYSV_SB(sb), de->inode), in sysv_readdir() 146 struct sysv_dir_entry *de; in sysv_find_entry() local 157 de = (struct sysv_dir_entry *)kaddr; in sysv_find_entry() 159 for ( ; (char *) de <= kaddr ; de++) { in sysv_find_entry() 160 if (!de->inode) in sysv_find_entry() [all …]
|
/linux-6.12.1/fs/proc/ |
D | generic.c | 46 static int proc_match(const char *name, struct proc_dir_entry *de, unsigned int len) in proc_match() argument 48 if (len < de->namelen) in proc_match() 50 if (len > de->namelen) in proc_match() 53 return memcmp(name, de->name, len); in proc_match() 75 struct proc_dir_entry *de = rb_entry(node, in pde_subdir_find() local 78 int result = proc_match(name, de, len); in pde_subdir_find() 85 return de; in pde_subdir_find() 91 struct proc_dir_entry *de) in pde_subdir_insert() argument 101 int result = proc_match(de->name, this, de->namelen); in pde_subdir_insert() 113 rb_link_node(&de->subdir_node, parent, new); in pde_subdir_insert() [all …]
|
/linux-6.12.1/fs/fat/ |
D | dir.c | 43 struct msdos_dir_entry *de) in fat_make_i_pos() argument 46 | (de - (struct msdos_dir_entry *)bh->b_data); in fat_make_i_pos() 83 struct buffer_head **bh, struct msdos_dir_entry **de) in fat__get_entry() argument 111 *de = (struct msdos_dir_entry *)((*bh)->b_data + offset); in fat__get_entry() 118 struct msdos_dir_entry **de) in fat_get_entry() argument 121 if (*bh && *de && in fat_get_entry() 122 (*de - (struct msdos_dir_entry *)(*bh)->b_data) < in fat_get_entry() 125 (*de)++; in fat_get_entry() 128 return fat__get_entry(dir, pos, bh, de); in fat_get_entry() 292 struct buffer_head **bh, struct msdos_dir_entry **de, in fat_parse_long() argument [all …]
|
/linux-6.12.1/fs/isofs/ |
D | dir.c | 17 int isofs_name_translate(struct iso_directory_record *de, char *new, struct inode *inode) in isofs_name_translate() argument 19 char * old = de->name; in isofs_name_translate() 20 int len = de->name_len[0]; in isofs_name_translate() 50 int get_acorn_filename(struct iso_directory_record *de, in get_acorn_filename() argument 55 int retnamlen = isofs_name_translate(de, retname, inode); in get_acorn_filename() 59 std = sizeof(struct iso_directory_record) + de->name_len[0]; in get_acorn_filename() 62 if (de->length[0] - std != 32) in get_acorn_filename() 64 chr = ((unsigned char *) de) + std; in get_acorn_filename() 69 if (((de->flags[0] & 2) == 0) && (chr[13] == 0xff) in get_acorn_filename() 95 struct iso_directory_record *de; in do_isofs_readdir() local [all …]
|
/linux-6.12.1/fs/reiserfs/ |
D | namei.c | 29 static int bin_search_in_dir_item(struct reiserfs_dir_entry *de, loff_t off) in bin_search_in_dir_item() argument 31 struct item_head *ih = de->de_ih; in bin_search_in_dir_item() 32 struct reiserfs_de_head *deh = de->de_deh; in bin_search_in_dir_item() 49 de->de_entry_num = j; in bin_search_in_dir_item() 53 de->de_entry_num = lbound; in bin_search_in_dir_item() 60 static inline void set_de_item_location(struct reiserfs_dir_entry *de, in set_de_item_location() argument 63 de->de_bh = get_last_bh(path); in set_de_item_location() 64 de->de_ih = tp_item_head(path); in set_de_item_location() 65 de->de_deh = B_I_DEH(de->de_bh, de->de_ih); in set_de_item_location() 66 de->de_item_num = PATH_LAST_POSITION(path); in set_de_item_location() [all …]
|