Tweet
Not to be included in the linux 4.1
Biggest concern here isn't the 13k lines of code. It would be readable if it weren't so complex. This has been complained a lot. Even when reviewing it in smaller patches it takes huge amount of time. Is anyone willing to do it as it already has two NACK's from reputable kernel maintainers?
All i see is pattern of someone making claim of the code and backing it up, GKH just comes back with answer, people try to ask more, he comes back with "i already answered that, do you have any technical argument?". It has been on going pattern for the whole kdbus story. (Somewhat it reminds me of unrelated systemd conversations)
Other concern here is the fact that when it is accepted in to kernel it can't be changed as "never break userspace". So what this means is even maintainers have been admitting that dbus might be bad design, we would be stuck with this bad design in kernel. Also we would be stuck with current API for a really long time. If someone would have interested to replace dbus with godlike design and API, we would still be stuck with kdbus in kernel.
I don't believe Linus will be accepting this as it is when it has 0 reviews(normally it would have been booted to curb already) and 2 nacks. Also there are criticising from Al Viro, Luto and others.
PS. seems like Linus already answered to this.
Originally posted by interested
View Post
And as Greg KH pointed out, that is less than a serial port driver:
As I understand it, the kdbus code have very little interaction with the rest of the kernel, so there should be no problems for other kernel maintainers whatever happens with kdbus. So it is unlikely that there will be any kernel related maintenance problems with kdbus.
If I understand Andy L. correct, his maintenance problem scenario is strictly that _user space_ may have maintenance problems if they abuse the API and make "bad things" despite of the documentation. Eg. if a certain piece of meta-information potentially can be abused, it probably will.
As I understand it, the kdbus code have very little interaction with the rest of the kernel, so there should be no problems for other kernel maintainers whatever happens with kdbus. So it is unlikely that there will be any kernel related maintenance problems with kdbus.
If I understand Andy L. correct, his maintenance problem scenario is strictly that _user space_ may have maintenance problems if they abuse the API and make "bad things" despite of the documentation. Eg. if a certain piece of meta-information potentially can be abused, it probably will.
All i see is pattern of someone making claim of the code and backing it up, GKH just comes back with answer, people try to ask more, he comes back with "i already answered that, do you have any technical argument?". It has been on going pattern for the whole kdbus story. (Somewhat it reminds me of unrelated systemd conversations)
Other concern here is the fact that when it is accepted in to kernel it can't be changed as "never break userspace". So what this means is even maintainers have been admitting that dbus might be bad design, we would be stuck with this bad design in kernel. Also we would be stuck with current API for a really long time. If someone would have interested to replace dbus with godlike design and API, we would still be stuck with kdbus in kernel.
I don't believe Linus will be accepting this as it is when it has 0 reviews(normally it would have been booted to curb already) and 2 nacks. Also there are criticising from Al Viro, Luto and others.
PS. seems like Linus already answered to this.
Comment