Driver tests based on `sysfs/bus/*/devices` aren't future proof
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- shell
- Área
- operating-systems, testing
Línea de trabajo
Comienza revisando las pruebas de bootrr que usan assert_device_present y su dependencia de sysfs/bus/*/devices. Lee el informe de regresión de KernelCI enlazado y la discusión relacionada para comprender los casos de fallo; el trabajo no estará terminado hasta decidir un enfoque de pruebas preparado para el futuro, en lugar de soluciones alternativas específicas de una versión.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
There are quite a few KernelCI regression reports from time to time that point to the same basic bootrr tests based on assert_device_present. These tests rely on sysfs nodes that aren't meant to be used as a stable ABI, so some changes like driver or device file renames and DT re-structuring can make these tests fail when, in fact, they shouldn't be considered as regressions.
Here's a recent example: https://groups.io/g/kernelci-results/message/39167 (this one is based on the KernelCI fork of bootrr)
Introduced by this patch: https://lore.kernel.org/all/[email protected]/
Fixing these tests to comply with the current changes or to run different checks depending on the kernel version seems more like a temporary workaround than a proper fix.
Do you think there'll be a better way to test this type of things in the future? Any suggestions from your side?
Here's a related discussion with a bit more background on this: https://lore.kernel.org/lkml/5095423.31r3eYUQgx@diego/
Thanks
- Lenguaje dominante
- Shell
- Estrellas
- 7
- Forks
- 33
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Issues similares
-
bot-found bug priority: P3
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
madenvel/KalinkaPlayer#179 ·
-
[platform-assessment 2026-09]Abiertodocumentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
jbaruch/coding-policy#621 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
mattpocock/skills#1134 ·
-
area:build bug P3
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
uttrflow/uttrflow-swift#2506 ·
Los mantenedores suelen responder en 1 día