Dear list, In order to keep this non-code RFC brief, allow me to list a few observations and then a proposal, that I shall be happy to engage in, but for which I'd like a bit of guidance:
1) System calls get superseded and deprecated on a regular basis 2) Keeping track of deprecations can be difficult 3) HW vendors with out-of-tree drivers allocate too few resources to handle 1) and 2) 4) Out-of-tree drivers usually fail to take deprecations into consideration, and then breaking when deprecation leads to removal A knee-jerk reaction to 3) might be that they all need to shape up, but experience seems to relegate that reaction to the pile of wishful thoughts that lead nowhere. IIRC, Greg K-H once tried to extend an offer to HW vendors to the effect of helping with opening their code base, with the reward of helping write drivers. I don't know what came of it, but I imagine that I would have heard, if it was a roaring success. As a user first, and only secondly a developer, I'd like my HW to work, and finding fully supported gear can still be hard if not impossible, but I imagine that if we had a central place to list deprecations (and, possibly, "victims" of them), a lot of grief could be avoided by simply pointing vendors to that central resource and saying "here is what you need to know for your driver to keep working - now get to it". As said, I'm more of a user, so I may be unaware of practices already in place to mark commits as causing deprecation, but if such practices exist, I should be able to whip up some sort of script that periodically does a "git log" and collates deprecations into some format that could then be parsed by a bash script grepping various out-of-tree code bases and notifies the relevant parties. I'd be willing to have a go at such functionality as well as hosting the info (at least until some vendor realizes the value and donates to it), but I'd hate to go off into too many wrong directions, if those can be avoided by feedback here. Best regards, Sune Mølgaard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
