Announcement

Collapse
No announcement yet.

KDBUS To Be Included In The Linux 4.1 Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Slaeppa
    replied
    Not to be included in the linux 4.1

    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.
    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.

    Leave a comment:


  • valeriodean
    replied
    Uh ah, the boss coming into the discussion, calling the thread for what it really is: a thread-from-hell. LOL
    Originally posted by Linus
    Is there actually a performance issue?

    I've seen this claimed, but I have never seen any actual numbers. What
    speeds up? By how much? is it actually measurable?

    Maybe they've marched past me in this thread-from-hell. But I can't
    recall having seen any (not now, not before).

    That said, I think the more serious issue is that if Luto complains
    about the capability-capturing code being completely broken, then
    people need to take that *seriously*.

    Linus
    I guess "Luto" is Andy Lutomirski. The replies to the GIT PULL are starting to be massive... where were those people before?
    Also this time, with their work, the systemd crew give as the usual popcorn time.

    Leave a comment:


  • interested
    replied
    Originally posted by valeriodean View Post
    The Kdbus itself is 13-14 k.
    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.

    In effect he wants a "fool proof" IPC where user space can't ever make mistakes that can lead to security problems. The problem with that attitude is of course that the entire Linux/BSD etc. user space would have to be rewritten to take advantage of such a totally new IPC; this won't happen, so effectively this attitude will kill off any future Linux IPC systems that will actually be used.

    That is quite contrary to Linus Torvalds normal attitude towards the Linux kernel, in that he stresses real world usage and problem solving, and not ivory tower attitudes about eg. how to obtain security. So since there is a distinct lack of low level code criticism and only generalised fear of potential problems without concrete examples, I suspect that Linus will allow kdbus in the kernel, maybe not in Linux 4.1, but probably quite soon.

    Leave a comment:


  • valeriodean
    replied
    Originally posted by pininety View Post
    Well, some of the kdbus critics seem to have a point (I haven't had a look at the source code of kdbus myself and most likely am lacking the programming skills to comprehend it anyway so take this with a piece of salt)

    Including something into the kernel will mean they will have to support it in the future and if the design is hard to maintain, this might end in disaster.
    On the other hand, kdbus fulfils a need right now like race free dbus.

    So right now, I am torn. I would really like to see something like kdbus in the kernel because of all the benefits but I do not want to have some giant unmaintained block in the kernel (and kdbus is like 34k lines of code afaik).

    The ideal case would be, we get kgernicipc which is really nice and can translate the current dbus userspace to it without to many worries but if this was easy or even possible, I guess people would have already done it.
    The whole package is 34k: 97 files changed, 34069 insertions(+), 3 deletions(-)
    But that means: Documentation + Code + Selftest.
    The Kdbus itself is 13-14 k.

    About the mainteiners, those are the names:
    Greg Kroah-Hartman
    Daniel Mack
    David Herrmann
    Djalal Harouni

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by Adarion View Post
    Does anybody know how well this can be used by userland today? I mean, userland supports dbus very often these days, some actually depend on it. But what is with kdbus, could Kdbus replace dbus in an instant or will the upstream userland developers have to make many adaptions?
    It should be more or less transparent to user space developers.

    Leave a comment:


  • justmy2cents
    replied
    Originally posted by Rallos Zek View Post
    https://lkml.org/lkml/2015/4/14/461

    That is what happens when you let scum like Red Hat work on good things like the Linux Kernel. Red Hat gave us the poison that is systemd and now are trying to infect the kernel itself.
    do you even realize how dumb this sounds? go and check kernel contributor list... and check it over the years. now go and check it for other projects as well. surprise, surprise...

    Leave a comment:


  • pininety
    replied
    Well, some of the kdbus critics seem to have a point (I haven't had a look at the source code of kdbus myself and most likely am lacking the programming skills to comprehend it anyway so take this with a piece of salt)

    Including something into the kernel will mean they will have to support it in the future and if the design is hard to maintain, this might end in disaster.
    On the other hand, kdbus fulfils a need right now like race free dbus.

    So right now, I am torn. I would really like to see something like kdbus in the kernel because of all the benefits but I do not want to have some giant unmaintained block in the kernel (and kdbus is like 34k lines of code afaik).

    The ideal case would be, we get kgernicipc which is really nice and can translate the current dbus userspace to it without to many worries but if this was easy or even possible, I guess people would have already done it.

    Leave a comment:


  • ceage
    replied
    Originally posted by Adarion View Post
    Does anybody know how well this can be used by userland today? I mean, userland supports dbus very often these days, some actually depend on it. But what is with kdbus, could Kdbus replace dbus in an instant or will the upstream userland developers have to make many adaptions?
    Systemd provides a translation layer to traditional D-Bus (systemd-bus-proxyd). See https://wiki.gnome.org/MatthiasClasen/KDBusMigration.

    Leave a comment:


  • MoonMoon
    replied
    Originally posted by Rallos Zek View Post
    https://lkml.org/lkml/2015/4/14/461




    That is what happens when you let scum like Red Hat work on good things like the Linux Kernel. Red Hat gave us the poison that is systemd and now are trying to infect the kernel itself.
    Go ahead and remove all contributions of Red Hat to the kernel and see how much that "scum" has actually provided to the kernel that you deem useful or simply need to get a working system.

    Leave a comment:


  • interested
    replied
    Originally posted by Naib View Post
    One of the aeguements for putting it in kernel is speed. The counter to that is there are plenty of opportunities to improve the user land speed. That hasn't been addressed.
    Yes it has, many times, including in the kdbus docs and on lkml. The point was never just to have a faster dbus, but to have a faster dbus that can solve real world problems because it can access kernel features. These problems includes solving inherent race problems, security measures like allowing LSM's to hook into the bus from the "safe" kernel instead of doing it in user land (and many more, including introspection etc). These problems can't be resolved by making a faster user land dbus, but only by having direct access to kernel features like kdbus.

    Faster implementations is always a good thing when done correctly and therefore always a good argument. But in this case the speed increases are just a positive side effect by moving things into the kernel that can't be done in user land.

    Leave a comment:

Working...
X