Documentation/translations/sp_SP/process/adding-syscalls.rst
Source file repositories/reference/linux-study-clean/Documentation/translations/sp_SP/process/adding-syscalls.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/translations/sp_SP/process/adding-syscalls.rst- Extension
.rst- Size
- 30438 bytes
- Lines
- 633
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: syscall or user/kernel boundary
- Status
- core implementation candidate
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Defines or participates in a user/kernel boundary; inspect argument validation, copy_from_user/copy_to_user, credentials, and dispatch target.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
struct xyzzy_paramsstruct xyzzy_argsstruct compat_xyzzy_args
Annotated Snippet
struct xyzzy_params {
u32 size; /* userspace define p->size = sizeof(struct xyzzy_params) */
u32 param_1;
u64 param_2;
u64 param_3;
};
Siempre que cualquier campo añadido subsecuente, digamos ``param_4``, sea
diseñado de forma tal que un valor cero, devuelva el comportamiento previo,
entonces permite versiones no coincidentes en ambos sentidos:
- Para hacer frente a programas del userspace más modernos, haciendo
llamadas a un kernel más antiguo, el código del kernel debe revisar que
cualquier memoria más allá del tamaño de la estructura sea cero (revisar
de manera efectiva que ``param_4 == 0``).
- Para hacer frente a programas antiguos del userspace haciendo llamadas a
un kernel más nuevo, el código del kernel puede extender con ceros, una
instancia más pequeña de la estructura (definiendo efectivamente
``param_4 == 0``).
Revise :manpage:`perf_event_open(2)` y la función ``perf_copy_attr()`` (en
``kernel/events/code.c``) para un ejemplo de esta aproximación.
Diseñando el API: Otras consideraciones
---------------------------------------
Si su nueva llamada al sistema permite al userspace hacer referencia a un
objeto del kernel, esta debería usar un descriptor de archivo como el
manipulador de ese objeto -- no invente un nuevo tipo de objeto manipulador
userspace cuando el kernel ya tiene mecanismos y semánticas bien definidas
para usar los descriptores de archivos.
Si su nueva llamada a sistema xyzzy(2) retorna un nuevo
descriptor de archivo, entonces el argumento flag debe incluir un valor que
sea equivalente a definir ``O_CLOEXEC`` en el nuevo FD. Esto hace posible
al userspace acortar la brecha de tiempo entre ``xyzzy()`` y la llamada a
``fcntl(fd, F_SETFD, FD_CLOEXEC)``, donde un ``fork()`` inesperado y
``execve()`` en otro hilo podrían filtrar un descriptor al programa
ejecutado. (Sin embargo, resista la tentación de reusar el valor actual de
la constante ``O_CLOEXEC``, ya que es específica de la arquitectura y es
parte de un espacio numerado de flags ``O_*`` que está bastante lleno.)
Si su llamada de sistema retorna un nuevo descriptor de archivo, debería
considerar también que significa usar la familia de llamadas de sistema
:manpage:`poll(2)` en ese descriptor de archivo. Hacer un descriptor de
archivo listo para leer o escribir es la forma normal para que el kernel
indique al espacio de usuario que un evento ha ocurrido en el
correspondiente objeto del kernel.
Si su nueva llamada de sistema xyzzy(2) involucra algún nombre
de archivo como argumento::
int sys_xyzzy(const char __user *path, ..., unsigned int flags);
debería considerar también si una versión xyzzyat(2) es mas
apropiada::
int sys_xyzzyat(int dfd, const char __user *path, ..., unsigned int flags);
Esto permite más flexibilidad en como el userspace especifica el archivo en
cuestión; en particular esto permite al userspace pedir la funcionalidad a
un descriptor de archivo ya abierto usando el flag ``AT_EMPTY_PATH``,
efectivamente dando una operación fxyzzy(3) gratis::
- xyzzyat(AT_FDCWD, path, ..., 0) es equivalente a xyzzy(path, ...)
- xyzzyat(fd, "", ..., AT_EMPTY_PATH) es equivalente a fxyzzy(fd, ...)
(Para más detalles sobre la explicación racional de las llamadas \*at(),
revise el man page :manpage:`openat(2)`; para un ejemplo de AT_EMPTY_PATH,
Annotation
- Detected declarations: `struct xyzzy_params`, `struct xyzzy_args`, `struct compat_xyzzy_args`.
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: core implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.