OpenBSD Journal

OpenBSD has accepted projects from Google Summer of Code 2015

Contributed by phessler on from the all tomorrow's patches dept.

The OpenBSD page for Google Summer of Code 2015 has been updated with the list of accepted projects for this year.
Asynchronous USB Transfers From Userland
ARM SD/MMC Driver & Controller Driver In libsa For OpenBSD
Port HAMMER2 to OpenBSD
Implement KMS Driver For Cirrus Cards
Improving USB Userland Tools And ioctl(2)
Automating Module Porting
Many thanks to those that responded, and we wish the best of luck on all projects!

(Comments are closed)


Comments
  1. By nixCraft (nixcraft) vivek@nixcraft.com on http://www.cyberciti.biz/

    I'm really exited about HAMMER2 file system.

    Comments
    1. By Bayu Krisnawan (202.0.89.254) krisna@gmail.com on http://www.yukova.com

      > I'm really exited about HAMMER2 file system.
      Yeah... hope it will also support cluster file system in the future :)
      Then let's move all to OpenBSD :)

      Comments
      1. By Brad (63.228.131.142) bradla8@yahoo.com on

        > > I'm really exited about HAMMER2 file system.
        > Yeah... hope it will also support cluster file system in the future :)
        > Then let's move all to OpenBSD :)

        This might help....
        https://github.com/bradla/OpenBSD-Hammer2

    2. By Predrag Punosevac (Oko) punosevac72@hotmail.com on

      > I'm really exited about HAMMER2 file system.

      Excitement is for children. We adults should be more rational. Personally, I am very surprised by the choice of HAMMER2 as one of OpenBSD's Google Summer of Code 2015 projects. HAMMER2 is very far away from being production ready. Please see this link for the current status

      http://gitweb.dragonflybsd.org/dragonfly.git/blob/b93cc2e0815ec1ad6d6f8e60cc0becbdee247679:/sys/vfs/hammer2/DESIGN

      this is little follow up discussion we had users@dragonflybsd.org

      http://lists.dragonflybsd.org/pipermail/users/2015-April/207618.html

      If I have to put a time frame HAMMER 2 will be released no earlier than January of 2017 which means that will not be usable for foreseeable future.


      I wish one of developers would publicly state the reasons for not even looking at WAPBL which is ported to Bitrig. HAMMER1 has reached production stability and in spite of its pitfalls it is a marvellous file system. However I suspect that porting HAMMER1 would require reimplementing large part of DragonFly kernel internals in OpenBSD kernel.

      Comments
      1. By rjc (rjc) on

        > > I'm really exited about HAMMER2 file system.
        >
        > Excitement is for children.

        There's no need for the condescending tone.

        Raf

      2. By Jtf (203.219.152.70) jttff1@gmail.com on

        > > I'm really exited about HAMMER2 file system.
        >
        > Excitement is for children. We adults should be more rational. Personally, I am very surprised by the choice of HAMMER2 as one of OpenBSD's Google Summer of Code 2015 projects. HAMMER2 is very far away from being production ready. Please see this link for the current status
        >
        > http://gitweb.dragonflybsd.org/dragonfly.git/blob/b93cc2e0815ec1ad6d6f8e60cc0becbdee247679:/sys/vfs/hammer2/DESIGN
        >
        > this is little follow up discussion we had users@dragonflybsd.org
        >
        > http://lists.dragonflybsd.org/pipermail/users/2015-April/207618.html
        >
        > If I have to put a time frame HAMMER 2 will be released no earlier than January of 2017 which means that will not be usable for foreseeable future.
        >
        >
        > I wish one of developers would publicly state the reasons for not even looking at WAPBL which is ported to Bitrig. HAMMER1 has reached production stability and in spite of its pitfalls it is a marvellous file system. However I suspect that porting HAMMER1 would require reimplementing large part of DragonFly kernel internals in OpenBSD kernel.

        Looking closely at the abstract, it says that the goal is to port a "subset" of HAMMER2 to OpenBSD. My guesses are the aim of this project is to just port parts of HAMMER2 not everything.

        I share Oko's concern. HAMMER2 is still not a complete file system yet even on DragonflyBSD so there is a lot of risks committing effort to porting it over. However, it would be rash to simply dismiss such as project. The thing is if HAMMER2 where to be production ready on DragonflyBSD by November 2020, focusing on it now may make it possible to have a usable HAMMER2 layout on OpenBSD within a 2021-2022 time-frame rather then a 2025-2027 time-frame as file systems are not easy to port over. Especially if you haven't been keeping track of the development.

        The problem with porting HAMMER1 instead of HAMMER2 is that OpenBSD developers will eventually have to port HAMMER2 as maintenance of HAMMER1 code will cease when HAMMER2 goes production ready. In the end, more work has to be done if OpenBSD were to take the HAMMER1 route.

        On the topic of WAPBL, I completely agree with Oko that it should be added to OpenBSD's FFS. We are still going to have FFS as the main file system for a while. Also, HAMMER2 or HAMMER1 will not be suitable for all situations.

        Comments
        1. By rjc (rjc) on

          > Looking closely at the abstract, it says that the goal is to port a "subset" of HAMMER2 to OpenBSD. My guesses are the aim of this project is to just port parts of HAMMER2 not everything.

          Not sure whether you missed it - https://marc.info/?l=openbsd-tech&m=142755452428573&w=2

          > I share Oko's concern. HAMMER2 is still not a complete file system yet even on DragonflyBSD so there is a lot of risks committing effort to porting it over. However, it would be rash to simply dismiss such as project. The thing is if HAMMER2 where to be production ready on DragonflyBSD by November 2020, focusing on it now may make it possible to have a usable HAMMER2 layout on OpenBSD within a 2021-2022 time-frame rather then a 2025-2027 time-frame as file systems are not easy to port over. Especially if you haven't been keeping track of the development.
          >
          > The problem with porting HAMMER1 instead of HAMMER2 is that OpenBSD developers will eventually have to port HAMMER2 as maintenance of HAMMER1 code will cease when HAMMER2 goes production ready. In the end, more work has to be done if OpenBSD were to take the HAMMER1 route.

          IMVHO, It's better to focus efforts on a filesystem which is meant as a successor to HAMMER, rather than having working HAMMER support in a couple of years, when HAMMER2 will hopefully be production-ready.

          > On the topic of WAPBL, I completely agree with Oko that it should be added to OpenBSD's FFS. We are still going to have FFS as the main file system for a while. Also, HAMMER2 or HAMMER1 will not be suitable for all situations.

          I agree when it comes to WAPBL.

  2. By Anonymous Coward (185.61.138.143) on

    Hopefully this won't be a repeat of the total sudden silence of GSOC project statuses like last year.

    Many promising projects, and there were no information in ML archives or on the OpenBSD or OpenBSD Foundation sites regarding project status.

    I hope I wasn't looking hard enough, or that I am wrong.

    Comments
    1. By Josh Grosse (129.9.75.249) on

      > I hope I wasn't looking hard enough, or that I am wrong.

      You may have missed several mailing list posts, then. For example:

      http://marc.info/?l=openbsd-misc&m=140340017208914&w=2

      Comments
      1. By Anonymous Coward (141.228.106.148) on

        > > I hope I wasn't looking hard enough, or that I am wrong.
        >
        > You may have missed several mailing list posts, then. For example:
        >
        > http://marc.info/?l=openbsd-misc&m=140340017208914&w=2
        >
        >

        Yeah but what about things like capsicum which were worked on but the outcome was only mentioned in passing? Better visibility of GSoC stuff would be fantastic

    2. By Noryungi (noryungi) on

      > Hopefully this won't be a repeat of the total sudden silence of GSOC project statuses like last year.
      >
      > Many promising projects, and there were no information in ML archives or on the OpenBSD or OpenBSD Foundation sites regarding project status.
      >
      > I hope I wasn't looking hard enough, or that I am wrong.
      >


      Well, yes, I believe you haven't been looking very hard.

      Here is an example:

      http://undeadly.org/cgi?action=article&sid=20140915064856
      http://bsd.slashdot.org/story/14/09/08/0250207/gsoc-project-works-to-emulate-systemd-for-openbsd

      Enjoy!

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]