Lines Matching refs:de

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
74 hizo, junto con los correspondientes seguimientos de los system calls --
76 ``pipe``/``pipe2``, ``renameat``/``renameat2`` -- así que aprenda de la
79 Para llamadas al sistema más simples que sólo toman un par de argumentos,
80 la forma preferida de permitir futuras extensiones es incluir un argumento
82 de forma segura estos flags entre versiones del kernel, revise si los flags
89 (Si no hay valores de flags usados aún, revise que los argumentos del flag
92 Para llamadas al sistema más sofisticadas que involucran un gran número de
93 argumentos, es preferible encapsular la mayoría de los argumentos en una
94 estructura que sea pasada a través de un puntero. Tal estructura puede
95 hacer frente a futuras extensiones mediante la inclusión de un argumento de
106 diseñado de forma tal que un valor cero, devuelva el comportamiento previo,
111    cualquier memoria más allá del tamaño de la estructura sea cero (revisar
112    de manera efectiva que ``param_4 == 0``).
115    instancia más pequeña de la estructura (definiendo efectivamente
119 ``kernel/events/code.c``) para un ejemplo de esta aproximación.
126 objeto del kernel, esta debería usar un descriptor de archivo como el
127 manipulador de ese objeto -- no invente un nuevo tipo de objeto manipulador
129 para usar los descriptores de archivos.
132 descriptor de archivo, entonces el argumento flag debe incluir un valor que
134 al userspace acortar la brecha de tiempo entre ``xyzzy()`` y la llamada a
137 ejecutado. (Sin embargo, resista la tentación de reusar el valor actual de
138 la constante ``O_CLOEXEC``, ya que es específica de la arquitectura y es
139 parte de un espacio numerado de flags ``O_*`` que está bastante lleno.)
141 Si su llamada de sistema retorna un nuevo descriptor de archivo, debería
142 considerar también que significa usar la familia de llamadas de sistema
143 :manpage:`poll(2)` en ese descriptor de archivo. Hacer un descriptor de
145 indique al espacio de usuario que un evento ha ocurrido en el
148 Si su nueva llamada de sistema :manpage:`xyzzy(2)` involucra algún nombre
149 de archivo como argumento::
160 un descriptor de archivo ya abierto usando el flag ``AT_EMPTY_PATH``,
166 (Para más detalles sobre la explicación racional de las llamadas \*at(),
167 revise el man page :manpage:`openat(2)`; para un ejemplo de AT_EMPTY_PATH,
170 Si su nueva llamada de sistema :manpage:`xyzzy(2)` involucra un parámetro
171 describiendo un describiendo un movimiento dentro de un archivo, ponga de
172 tipo ``loff_t`` para que movimientos de 64-bit puedan ser soportados
173 incluso en arquitecturas de 32-bit.
175 Si su nueva llamada de sistema  :manpage:`xyzzy` involucra una
178 describe en el man page :manpage:`capabilities(7)`. Elija una parte de
180 de evitar combinar muchas funciones sólo relacionadas vagamente bajo la
181 misma sección, ya que va en contra de los propósitos de las capabilities de
183 de la capacidad ya demasiado general de la capabilities ``CAP_SYS_ADMIN``.
185 Si su nueva llamada de sistema :manpage:`xyzzy(2)` manipula un proceso que
187 a ``ptrace_may_access()``) de forma que el único proceso con los mismos
191 Finalmente, debe ser conciente de que algunas arquitecturas no-x86 tienen
194 permitir el uso de pares contiguos de registros 32-bits. (Este cuidado no
195 aplica si el argumento es parte de una estructura que se pasa a través de
201 Para hacer una nueva llamada al sistema fácil de revisar, es mejor dividir
202 el patchset (conjunto de parches) en trozos separados. Estos deberían
203 incluir al menos los siguientes items como commits distintos (cada uno de
206  - La implementación central de la llamada al sistema, junto con
207    prototipos, numeración genérica, cambios Kconfig e implementaciones de
208    rutinas de respaldo (fallback stub)
211  - Una demostración del use de la nueva llamada a sistema en el userspace
213  - Un borrador de man-page para la nueva llamada a sistema, ya sea como
214    texto plano en la carta de presentación, o como un parche (separado)
217 Nuevas propuestas de llamadas de sistema, como cualquier cambio al API del
221 Implementation de Llamada de Sistema Generica
224 La entrada principal a su nueva llamada de sistema :manpage:`xyzzy(2)` será
225 llamada ``sys_xyzzy()``, pero incluya este punto de entrada con la macro
226 ``SYSCALL_DEFINEn()`` apropiada en vez de explicitamente. El 'n' indica el
227 numero de argumentos de la llamada de sistema, y la macro toma el nombre de
228 la llamada de sistema seguida por el par (tipo, nombre) para los parámetros
229 como argumentos. Usar esta macro permite a la metadata de la nueva llamada
230 de sistema estar disponible para otras herramientas.
232 El nuevo punto de entrada también necesita un prototipo de función
234 para calzar en la manera en que las llamadas de sistema son invocadas::
238 Algunas arquitecturas (e.g. x86) tienen sus propias tablas de syscall
240 una tabla de syscall genéricas. Agrega su nueva llamada de sistema a la
247 También actualice el conteo de __NR_syscalls para reflejar la llamada de
248 sistema adicional, y note que si multiples llamadas de sistema nuevas son
249 añadidas en la misma ventana unida, su nueva llamada de sistema podría
253 (rutina de respaldo) para cada llamada de sistema, retornando ``-ENOSYS``.
258 Su nueva funcionalidad del kernel, y la llamada de sistema que la controla,
265  - Haga la opción dependiendo de EXPERT si esta debe estar escondida de los
268    dependa de la opción CONFIG en el Makefile (e.g.
276  - ``SYSCALL_DEFINEn(xyzzy, ...)`` para el punto de entrada
282 Implementación de Llamada de Sistema x86
285 Para conectar su nueva llamada de sistema a plataformas x86, necesita
286 actualizar las tablas maestras syscall. Asumiendo que su nueva llamada de
287 sistema ni es especial de alguna manera (revise abajo), esto involucra una
297 De nuevo, estos número son propensos de ser cambiados si hay conflictos en
298 la ventana de integración relevante.
301 Compatibilidad de Llamadas de Sistema (Genérica)
304 Para la mayoría de llamadas al sistema la misma implementación 64-bit puede
305 ser invocada incluso cuando el programa de userspace es en si mismo 32-bit;
306 incluso si los parámetros de la llamada de sistema incluyen un puntero
307 explícito, esto es manipulado de forma transparente.
309 Sin embargo, existe un par de situaciones donde se necesita una capa de
310 compatibilidad para lidiar con las diferencias de tamaño entre 32-bit y
314 32-bit, y por lo tanto necesita analizar areas de memoria del (``__user``)
316 necesita siempre que un argumento de la llamada a sistema es:
321  - un puntero a un type entero de tamaño entero variable (``time_t``,
323  - un puntero a un struct conteniendo un type entero de tamaño variable.
325 La segunda situación que requiere una capa de compatibilidad es cuando uno
326 de los argumentos de la llamada a sistema tiene un argumento que es
329 desde una aplicación de 32-bit se separará en dos valores de 32-bit, los
330 que luego necesitan ser reensamblados en la capa de compatibilidad.
332 (Note que un argumento de una llamada a sistema que sea un puntero a un
333 type explicitamente de 64-bit **no** necesita una capa de compatibilidad;
334 por ejemplo, los argumentos de :manpage:`splice(2)`) del tipo
335 ``loff_t __user *`` no significan la necesidad de una llamada a sistema
338 La versión compatible de la llamada de sistema se llama
340 ``COMPAT_SYSCALL_DEFINEn``, de manera análoga a SYSCALL_DEFINEn. Esta
341 versión de la implementación se ejecuta como parte de un kernel de 64-bit,
344 convierte los valores a versiones de 64 bits y llama a la versión ``sys_``
345 o ambas llaman a una función de implementación interna común.)
347 El punto de entrada compat también necesita un prototipo de función
354 de forma distinta en sistema de 32-bit y 64-bit, digamos
355 ``struct xyzzy_args``, entonces el archivo de cabecera
356 include/linux/compat.h también debería incluir una versión compatible de la
357 estructura (``struct compat_xyzzy_args``) donde cada campo de tamaño
360 esta estructura ``compat_`` para analizar los argumentos de una invocación
361 de 32-bit.
381 la lista genérica de llamadas al sistema también necesita ajustes para
383 ``include/uapi/asm-generic/unistd.h`` debería usar ``__SC_COMP`` en vez de
391   - una ``COMPAT_SYSCALL_DEFINEn(xyzzy, ...)`` para el punto de entrada de compat.
393   - (en caso de ser necesario) un struct de mapeo de 32-bit en ``include/linux/compat.h``
394   - una instancia de ``__SC_COMP`` no ``__SYSCALL`` en ``include/uapi/asm-generic/unistd.h``
396 Compatibilidad de Llamadas de Sistema (x86)
399 Para conectar la arquitectura x86 de una llamada al sistema con una versión
400 de compatibilidad, las entradas en las tablas de syscall deben ser
404 una columna extra para indicar que un programa del userspace de 32-bit
405 corriendo en un kernel de 64-bit debe llegar al punto de entrada compat::
409 Segundo, tienes que averiguar qué debería pasar para la versión x32 ABI de
410 la nueva llamada al sistema. Aquí hay una elección: el diseño de los
411 argumentos debería coincidir con la versión de 64-bit o la versión de
417 progamas 32-bit lleguen al envoltorio de compatibilidad::
427 En cualquier caso, debes revisar que lo tipos involucrados en su diseño de
428 argumentos de hecho asigne exactamente de x32 (-mx32) a 32-bit(-m32) o
432 Llamadas de Sistema Retornando a Otros Lugares
435 Para la mayoría de las llamadas al sistema, una vez que se la llamada al
436 sistema se ha completado el programa de usuario continúa exactamente donde
437 quedó -- en la siguiente instrucción, con el stack igual y la mayoría de
438 los registros igual que antes de la llamada al sistema, y con el mismo
443 cambiar el espacio de memoria (``fork``/``vfork``/``clone``) o incluso de
446 Para permitir esto, la implementación del kernel de la llamada al sistema
448 kernel, brindandole control completo de donde y cómo la ejecución continúa
449 después de la llamada a sistema.
451 Esto es arch-specific, pero típicamente involucra definir puntos de entrada
452 assembly que guardan/restauran registros adicionales e invocan el punto de
453 entrada real de la llamada a sistema.
455 Para x86_64, esto es implementado como un punto de entrada ``stub_xyzzy``
468 Si la llamada a sistema necesita una capa de compatibilidad (como en la
470 versión ``compat_sys_`` de la llamada a sistema, en vez de la versión
471 nativa de 64-bit. También, si la implementación de la versión x32 ABI no es
475 Para completar, también es agradable configurar un mapeo de modo que el
487 La mayoría del kernel trata las llamadas a sistema de manera genérica, pero
491 El subsistema de auditoría es un caso especial; este incluye funciones
492 (arch-specific) que clasifican algunos tipos especiales de llamadas al
494 execution (``execve`` /``execveat``) o operaciones multiplexores de socket
495 (``socketcall``). Si su nueva llamada de sistema es análoga a alguna de
500 kernel de la llamada a sistema existente, para revisar que no exista otro
508 proveer a los revisores con una demostración de cómo los programas del
509 userspace usarán la llamada al sistema. Una buena forma de combinar estos
523 Para pruebas más amplias y exhautivas de la nueva funcionalidad, también
537 en el cover del email para el patchset, para la conveniencia de los
544 No invoque las llamadas de sistemas en el kernel
547 Las llamadas al sistema son, cómo se declaró más arriba, puntos de
548 interacción entre el userspace y el kernel. Por lo tanto, las funciones de
550 ser llamadas sólo desde el userspace vía la tabla de syscall, pero no de
553 antiguas, o necesita ser compartida entre una syscall y su variante de
556 dentro del syscall stub (``sys_xyzzy()``), la syscall stub de
560 adelante no invocar funciones de llamada al sistema (system call) en el
561 kernel. Este usa una convención de llamada diferente para llamadas al
566 de llenar en seis registros de CPU con contenido random del userspace todo
567 el tiempo (los cuales podrían causar serios problemas bajando la cadena de
571 entre la data del kernel y la data de usuario. Esta es otra razón por la
575 específicos de arquitectura, envoltorios de compatibilidad específicos de
582  - Artículo LWN de Michael Kerrisk sobre el uso de argumentos flags en llamadas al
585  - Artículo LWN de Michael Kerrisk sobre cómo manejar flags desconocidos en una
587  - Artículo LWN de Jake Edge describiendo restricciones en argumentos en
589  - Par de artículos LWN de David Drysdale que describen la ruta de implementación
590    de llamadas al sistema en detalle para v3.14:
598  - Recopilación de emails de Linus Torvalds discutiendo problemas con ``ioctl()``:
602  - Artículo LWN de Michael Kerrisk sobre evitar nuevos usos de CAP_SYS_ADMIN:
604  - Recomendaciones de Andrew Morton que toda la información relacionada a una nueva
605    llamada al sistema debe venir en el mismo hilo de correos:
607  - Recomendaciones de Michael Kerrisk que una nueva llamada al sistema debe venir
609  - Sugerencias de Thomas Gleixner que conexiones x86 deben ir en commits
611  - Sugerencias de Greg Kroah-Hartman que es bueno para las nueva llamadas al sistema
613  - Discusión de Michael Kerrisk de nuevas system call vs. extensiones :manpage:`prctl(2)`:
615  - Sugerencias de Ingo Molnar que llamadas al sistema que involucran múltiples
617 …un campo de tamaño para futura extensibilidad: https://lore.kernel.org/r/20150730083831.GA22182@gm…
618  - Enumerando rarezas por la (re-)utilización de O_* numbering space flags:
626  - Discusión de Matthew Wilcox sobre las restricciones en argumentos 64-bit:
628  - Recomendaciones de Greg Kroah-Hartman sobre flags desconocidos deben ser
630  - Recomendaciones de Linus Torvalds que las llamadas al sistema x32 deben favorecer