Announcement

Collapse
No announcement yet.

Red Hat Intros Kpatch For Dynamic Kernel Patching

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

  • #11
    Originally posted by Sonadow View Post
    Ksplice, Kgraft and now Kpatch.

    NIH syndrome at its best. And i'll bet that Kpatch eventually gets upstreamed just because it's from Red Hat.
    kGraft was publicly announced on 2014-01-31: https://www.suse.com/communities/con...rnel-patching/

    The announcement for Kpatch states that "the kernel team here at Red Hat has been working on a dynamic kernel patching project called kpatch for several months."

    So, sounds like it was just a timing thing: both teams happened to work on the same thing at the same time. I don't know anything the public doesn't about Kpatch, but RH and SUSE devs have a long history of working together upstream, esp. on the kernel, so I'd be surprised if that doesn't happen here.

    edit: looks like http://www.pro-linux.de/news/1/20758...it-kpatch.html may be vaguely interesting - anyone who can read German want to translate?

    Comment


    • #12
      I'd prefer if KGraft came out ahead, just to give a few points to SUSE. Red Hat have enough.

      Comment


      • #13
        Originally posted by xeekei View Post
        I'd prefer if KGraft came out ahead, just to give a few points to SUSE. Red Hat have enough.
        I'd prefer neither of them to end up in kernel but SuSE and RH engineers to sit in the same room, think of the good sides and bad sides of both implementations and implement a third one together that would be an evolutionary step from both.

        Comment


        • #14
          Originally posted by AdamW View Post
          kGraft was publicly announced on 2014-01-31: https://www.suse.com/communities/con...rnel-patching/

          The announcement for Kpatch states that "the kernel team here at Red Hat has been working on a dynamic kernel patching project called kpatch for several months."

          So, sounds like it was just a timing thing: both teams happened to work on the same thing at the same time. I don't know anything the public doesn't about Kpatch, but RH and SUSE devs have a long history of working together upstream, esp. on the kernel, so I'd be surprised if that doesn't happen here.

          edit: looks like http://www.pro-linux.de/news/1/20758...it-kpatch.html may be vaguely interesting - anyone who can read German want to translate?
          I'll give it a try:

          Red Hat's Kpatch joins Kspilce and Kgraft

          A week after Suse announced that they work on Kgraft, a framework for live patching of the kernel, Red Hat explained that they want to present their own software, named Kpatch at the end of march at the Collaboration Summit. This was unveilled by a Red Hat developer named Linda Wang in a lightning talk at devconf.cz.

          Beneath Ksplice and OpenSuses Kgraft, this is the third technology in development for patching at the kernel runtime and without reboots. Ksplice has been in development since 2008, but was bought by Oracle in 2011 and hasn't been available under a free license since. Aditionally Ksplice wasn't upstreamed.

          Suse and Red Hat still seem to be in early developement with those technologies, but it's unclear why both distributions are working on similar things at the same time instead of sharing the work. Concerning integration into mainline, it seems unlikely that two interfaces will be accepted.

          The last paragraph is about why such a technology is needed anyways and not about the differences or anything like that, plus it links to a english website.

          Comment


          • #15
            Test signature

            Comment


            • #16
              Originally posted by bridgman View Post
              I don't think this applies here, there was no standard to start with: ksplice has been in a limbo for a while now, and Oracle doesn't really have a history of reliability in open source projects. Suse and Red Hat seem to have developed different solutions in parallel in the meantime, probably out of the same concern.
              What I really hope is that they'll hae a collaborative attitude and maybe even merge the projects, if possible at all.

              Comment


              • #17
                The cartoon worked much better after nanonyme's post than after ajs124's... need to hit "refresh" before replying next time
                Test signature

                Comment


                • #18
                  I'm not sure at what granularity the other solutions work but my hope is that we'll get some competition so we can have as robust a facility for hotpatching as possible.

                  Comment


                  • #19
                    Originally posted by nanonyme View Post
                    I'd prefer neither of them to end up in kernel but SuSE and RH engineers to sit in the same room, think of the good sides and bad sides of both implementations and implement a third one together that would be an evolutionary step from both.
                    That sounds great except I don't think we need any more camels.

                    Comment

                    Working...
                    X