On Mon, 4 Nov 2019 11:21:21 -0800 John Stultz <john.stultz@xxxxxxxxxx> wrote: > So apologies for the confusion. I do believe I understand the > requirement now, and am doing my best to adhere to them. Hi John, that's cool, the kernel regression rules are so strict that any slip in userspace projects can seriously hamper kernel work, so I'm kind of on the edge now that I've realized that. > That said, given different userland projects use different approaches, > I do find it a little strange on the insistence that userland patches > cannot be merged to their project before the kernel changes land. > Obviously no interface is final and any userland that does so has some > risk that it will change and break, but there are many cases where > distros support new features in their userland not yet merged > upstream. Ensuring there is a real opensource user for the kernel > feature is important, but I'm not sure I understand why the kernel is > dictating rules as to how userspace merges code. My own understanding is that if a userspace project manages to release a version that uses new kernel UAPI which was not finalized yet, then when kernel people fix something in the UAPI and attempt to land it, the difference will make the userspace now break because the feature does not work like it used to. The userspace project is already released and in the wild, so it cannot be retroactively fixed. According to the kernel rules, any kernel change that breaks existing userspace, no matter how wrong userspace was, is the kernel's fault. So that means the kernel developers cannot land the new fixed feature, but will need to figure out a way to expose the new feature without triggering the new path in the userspace project that jumped the gun. Often the breakage is not found out immediately but after a kernel release. That means the already released feature will have to be reverted, and then figure out how to re-introduce it so that it does not trigger the userspace project that jumped the gun. This obviously affects also userspace projects that wanted to use the feature and did not jump the gun - they do not break, they just do not find the feature anymore and need to be fixed. In my opinion, saying "do not merge" to userspace projects is better than "do not release" until the UAPI is finalized in the kernel. I'm not sure it even matters if the userspace project makes a release or not. All it takes is for someone to grab a snapshot and distribute it, and for someone to complain. Thanks, pq
Attachment:
pgpczEmLdK3rV.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
