Re: [PATCH v14 0/5] DMA-BUF Heaps (destaging ION)

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2582 bytes --]

On Mon, 4 Nov 2019 11:21:21 -0800
John Stultz <john.stultz@linaro.org> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]