Announcement

Collapse
No announcement yet.

KDBUS To Be Included In The Linux 4.1 Kernel

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

  • #31
    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.
    What finalzone said and:
    While I agree that Redhat's forced introduction of systemd is not a beautiful matter - Greg KH ist not Redhat - at least not that I know. Greg is Gentoo, SuSE and whatsnot. And a general kernel / driver developer and maintainer.
    Stop TCPA, stupid software patents and corrupt politicians!

    Comment


    • #32
      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.

      Comment


      • #33
        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.

        Comment


        • #34
          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.

          Comment


          • #35
            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.

            Comment


            • #36
              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...

              Comment


              • #37
                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.

                Comment


                • #38
                  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

                  Comment


                  • #39
                    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.

                    Comment


                    • #40
                      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.

                      Comment

                      Working...
                      X