Tu sélectionnes beaucoup… Le reste de la discussion est posé, il argumente.
Par exemple :
"Well, UVC should return the same error codes as the other drivers, for the same error types. That's what that patch was trying to fix"
Maintenant, pose-toi la question : si tu as un bug, et que le user space plante si tu corrige le bug, doit-on ne jamais corriger le bug car un "dictateur bienveillant" a décidé que les bugs doivent rester? Les nouveaux programmes doivent-ils se taper 1000 lignes de code alors qu'une suffirait si on corrige le bug parce qu'un autre programme a implémenté d'une certaine manière la gestion de ce bug et/ou attend une valeur précise alors que ton API dit qu'il peut retourner n'importe quelle erreur? Qu'est-ce qui dit qu'il faut absolument que l'API retourne EINVAL et pas ENOENT, même si un logiciel a été codé comme les pieds et attend une unique valeur?
On peut aussi constater le bug, proposer un plan de migration (long, ça peut être en années) entre les différents acteurs (user space est au courant et corrige, on attend un peu au kernel avant de changer), et corriger un jour.
bref, ce n'est pas aussi binaire que Linus (même si il est "bienveillant" pour toi, un dictateur est toujours bienveillant pour certains et pas pour d'autres) et toi le disent.
# Mouais...
Posté par Zenitram (site web personnel) . En réponse au journal Linus pas content. Évalué à -10.
Tu sélectionnes beaucoup… Le reste de la discussion est posé, il argumente.
Par exemple :
"Well, UVC should return the same error codes as the other drivers, for the same error types. That's what that patch was trying to fix"
Maintenant, pose-toi la question : si tu as un bug, et que le user space plante si tu corrige le bug, doit-on ne jamais corriger le bug car un "dictateur bienveillant" a décidé que les bugs doivent rester? Les nouveaux programmes doivent-ils se taper 1000 lignes de code alors qu'une suffirait si on corrige le bug parce qu'un autre programme a implémenté d'une certaine manière la gestion de ce bug et/ou attend une valeur précise alors que ton API dit qu'il peut retourner n'importe quelle erreur? Qu'est-ce qui dit qu'il faut absolument que l'API retourne EINVAL et pas ENOENT, même si un logiciel a été codé comme les pieds et attend une unique valeur?
On peut aussi constater le bug, proposer un plan de migration (long, ça peut être en années) entre les différents acteurs (user space est au courant et corrige, on attend un peu au kernel avant de changer), et corriger un jour.
bref, ce n'est pas aussi binaire que Linus (même si il est "bienveillant" pour toi, un dictateur est toujours bienveillant pour certains et pas pour d'autres) et toi le disent.