summerofcodeideas

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
summerofcodeideas [2023/01/26 20:57] – WarnerLoshsummerofcodeideas [2023/07/07 16:23] (current) – fix typo in MFSBD project JosephMingrone
Line 15: Line 15:
 We also have a generic %%FreeBSD%% ideas page at IdeasPage and WantedPorts.  Note that many of these may not be suitable Summer of Code projects as-is, but may provide inspiration for ideas of your own.  The projects listed on this page are not restricted to %%GSoC%% participants, of course. We also have a generic %%FreeBSD%% ideas page at IdeasPage and WantedPorts.  Note that many of these may not be suitable Summer of Code projects as-is, but may provide inspiration for ideas of your own.  The projects listed on this page are not restricted to %%GSoC%% participants, of course.
  
-For a feel for projects from previous years, visit: [[SummerOfCode2021|SummerOfCode2021]], [[SummerOfCode2020|SummerOfCode2020]], [[SummerOfCode2019|SummerOfCode2019]], [[SummerOfCode2018|SummerOfCode2018]], [[SummerOfCode2017|SummerOfCode2017]], [[SummerOfCode2016|SummerOfCode2016]], [[SummerOfCode2015|SummerOfCode2015]], [[SummerOfCode2014|SummerOfCode2014]], [[SummerOfCode2013|SummerOfCode2013]], [[SummerOfCode2012|SummerOfCode2012]], [[SummerOfCode2011|SummerOfCode2011]], [[SummerOfCode2010|SummerOfCode2010]].+For a feel for projects from previous years, visit: [[SummerOfCode2022|SummerOfCode2022]], [[SummerOfCode2021|SummerOfCode2021]], [[SummerOfCode2020|SummerOfCode2020]], [[SummerOfCode2019|SummerOfCode2019]], [[SummerOfCode2018|SummerOfCode2018]], [[SummerOfCode2017|SummerOfCode2017]], [[SummerOfCode2016|SummerOfCode2016]], [[SummerOfCode2015|SummerOfCode2015]], [[SummerOfCode2014|SummerOfCode2014]], [[SummerOfCode2013|SummerOfCode2013]], [[SummerOfCode2012|SummerOfCode2012]], [[SummerOfCode2011|SummerOfCode2011]], [[SummerOfCode2010|SummerOfCode2010]].
  
 ===== How to use this idea list ===== ===== How to use this idea list =====
Line 39: Line 39:
  
   * **Scripting**: For scripting, unless otherwise stated we won't enforce which language you choose, however there are certain factors for this choice: if you're willing to work with /bin/sh (+awk/sed/etc), there is a higher chance that whatever you produce could be committed to the base system.  If you pick something like bash, which we don't include in the base system, it may still be possible to create a convincing case for the tool to get into the tree, with some level of commitment and convincing.  For other things in languages too large for the base system and not present there (e.g.: perl, python, ruby), these can still be offered as useful tools to others, but (e.g.) these would be bad language choices for things that need to be usable with just the base system (e.g. the installer). **Tools are equally important as every part of the OS.  If you create a tool for debugging, analyzing and visualizing complex data, it might help dozens of %%FreeBSD%% hackers around the world to be 10x more productive.**   * **Scripting**: For scripting, unless otherwise stated we won't enforce which language you choose, however there are certain factors for this choice: if you're willing to work with /bin/sh (+awk/sed/etc), there is a higher chance that whatever you produce could be committed to the base system.  If you pick something like bash, which we don't include in the base system, it may still be possible to create a convincing case for the tool to get into the tree, with some level of commitment and convincing.  For other things in languages too large for the base system and not present there (e.g.: perl, python, ruby), these can still be offered as useful tools to others, but (e.g.) these would be bad language choices for things that need to be usable with just the base system (e.g. the installer). **Tools are equally important as every part of the OS.  If you create a tool for debugging, analyzing and visualizing complex data, it might help dozens of %%FreeBSD%% hackers around the world to be 10x more productive.**
- 
-====== Ideas list ====== 
  
 ---- ----
Line 139: Line 137:
 ---- ----
  
-==== Complete FreeBSD's MPLS implementation ====+==== Implement MPLS support for FreeBSD ====
  
-| Mentor |  |+| Mentor | Alexander Chernikov <melifaro@FreeBSD.org> |
 | Skills | C (intermediate), networking (intermediate) | | Skills | C (intermediate), networking (intermediate) |
-| Mid-term deliverable | [[http://freebsd.mpls.in/|All mandatory requierement listed here]] |+| Mid-term deliverable | MPLS forwarding works on static labels |
 | Duration | 350 hours | | Duration | 350 hours |
 | Difficulty | Medium | | Difficulty | Medium |
-| Expected Outcome | Full integration with net/frr LDP daemon and/or net/bird |+| Expected Outcome | MPLS forwarding, encap/decap works, MPLS labels can be programmed via Netlink |
  
 === Description === === Description ===
  
-Multiprotocol Label Switching (MPLS) is data forwarding technology that increases the speed and controls the flow of network traffic. With MPLS, data is directed through a path via labels instead of requiring complex lookups in a routing table at every stop.  There has been work to add the MPLS stack to %%FreeBSD%%, but none are complete:+Multiprotocol Label Switching ([[https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching|MPLS]]) is an overlay network technology based on labels instead of IP addresses. The project would be to bring basic MPLS support for %%FreeBSD%%. 
 +Roughly, the implementation can be split into the following chunks: 
 +  * create MPLS routing tables, analogous to AF_INET[6] routing tables 
 +  * add the logic to handle MPLS packets (mpls_input(), mpls_forward(), mpls_output(%%))%% at various stages 
 +  * add the code to perform MPLS encap for IPv4/IPv6 routes, extending nexthops functionality 
 +  * add Netlink support for working with IP-MPLS, MPLS-MPLS and MPLS-IP routes 
 +  * Add userland support for working with MPLS routes to route(8) and netstat(8) 
 +  * [stretch] add fast fib lookup module to enable high-performance concurrent label lookups
  
-  * [[http://freebsd.mpls.in/|melifaro's old-work-in-progress]] +The [[https://2011.eurobsdcon.org/papers/jeker/MPLS.pdf|OpenBSD's MPLS stack]] or the [[https://wiki.netbsd.org/users/kefren/mpls/|NetBSD's MPLS stack]] overviews of other *BSD implementations can provide more datapoints.
-  * [[RyanFrench/Implementation of MPLS in FreeBSD|GSoC 2008 Project]]+
  
-This project should refresh and cleanup these works-in-progress. The [[https://2011.eurobsdcon.org/papers/jeker/MPLS.pdf|OpenBSD's MPLS stack]] or the [[https://wiki.netbsd.org/users/kefren/mpls/|NetBSD's MPLS stack]] can also be used as inspiration.+---- 
 + 
 +==== Improve netgraph concurrency ==== 
 + 
 +| Mentor | Alexander Chernikov <melifaro@FreeBSD.org> | 
 +| Skills | C (intermediate), networking (intermediate) | 
 +| Mid-term deliverable | Traffic is able to pass in a lockless fashion in 2-node netgraph topology | 
 +| Duration | 350 hours | 
 +| Difficulty | Medium | 
 +| Expected Outcome | Traffic is able to pass in a lockless fashion between ng_%%<%%ppp%%|%%car%%|%%tee%%|%%iface>, compatibility retained with non-converted nodes | 
 + 
 +=== Description === 
 + 
 +[[https://man.freebsd.org/cgi/man.cgi?netgraph(4)|Netgraph]] is a traffic-processing subsystem based on the dynamically configured graph of nodes and directed edges. Each node apply a single specific manipulation to the packet. The core idea is similar to [[https://fd.io/gettingstarted/technology/|VPP]]. Currently netgraph uses topology lock and node/hook atomic refcounts to ensure safe passing of the packets between the nodes. The goal of the project is to make passing data between the nodes lockless. The necessary primitives like [[https://man.freebsd.org/cgi/man.cgi?query=epoch&apropos=0&sektion=9&manpath=FreeBSD+13.1-RELEASE+and+Ports&arch=default&format=html|epoch-based]] object reclamation and lockless datastructures are available in the base system. The rough implementation sketch may look like the following: 
 + 
 +  * Enable delayed reclamation of netgraph hooks and nodes under existing NET_EPOCH 
 +  * Make core API like ''%%ng_address_hook()%%'' leverage existing NET_EPOCH and avoid taking topology locks / refcounts 
 +  * Test the implementation with a number of stateless nodes like ng_patch or ng_tee and ng_ipfw 
 +  * Evaluate and convert nodes on per-node basis on their reliance on the topology lock 
  
 ---- ----
Line 197: Line 219:
 ===== Userland projects ===== ===== Userland projects =====
  
-==== Kernel LLDB debugger module support and integration ====+---- 
 + 
 +==== Kernel LLDB debugger improvements, module support and integration ====
  
 | Mentor | [[EdMaste|Ed Maste]] <emaste@FreeBSD.org> | | Mentor | [[EdMaste|Ed Maste]] <emaste@FreeBSD.org> |
Line 203: Line 227:
 | Mid-term deliverable | Parse and report the kernel module list in a coredump | | Mid-term deliverable | Parse and report the kernel module list in a coredump |
 | Duration | 175 or 350 hours | | Duration | 175 or 350 hours |
-| Difficulty | Easy |+| Difficulty | Moderate |
 | Expected Outcome | crashinfo functional with LLDB rather than kgdb | | Expected Outcome | crashinfo functional with LLDB rather than kgdb |
  
Line 217: Line 241:
  
 | Mentor | ? | | Mentor | ? |
-| Skills | C (expert), fusefs (expert) |+| Skills | C++ or Rust (expert), fusefs (expert) |
 | Mid-term deliverable | Read-only support for userland | | Mid-term deliverable | Read-only support for userland |
 | Duration | 350 hours | | Duration | 350 hours |
Line 251: Line 275:
  
 Note: contributing to syzkaller requires signing the Google CLA.  Please make sure that this is acceptable before attempting this project.  Note also that working with syzkaller is probably easiest on a dedicated hardware system with a reasonably large amount of disk space (several hundred GB should be sufficient), ideally running %%FreeBSD%% on ZFS.  syzkaller can instantiate VMs on Google Compute Engine and fuzz them, so this may be an option as well.  Please contact the project mentors for details. Note: contributing to syzkaller requires signing the Google CLA.  Please make sure that this is acceptable before attempting this project.  Note also that working with syzkaller is probably easiest on a dedicated hardware system with a reasonably large amount of disk space (several hundred GB should be sufficient), ideally running %%FreeBSD%% on ZFS.  syzkaller can instantiate VMs on Google Compute Engine and fuzz them, so this may be an option as well.  Please contact the project mentors for details.
- 
----- 
- 
-==== Move to GENERIC armv7 distribution scripting ==== 
- 
-| Mentor | [[WarnerLosh|Warner Losh]] <imp@FreeBSD.org> | 
-| Skills | Shell / Make (intermediate) | 
-| Mid-term deliverable | release scripts working, u-boot ports updated | 
-| Duration | 175 hours | 
-| Difficulty | Medium | 
-| Expected Outcome | Documented and tested user tool to generate generic image | 
- 
-=== Description === 
- 
-%%FreeBSD%% has grown support for a large number of boards over the past few years, far too many to release images for all of them. This project would convert the release tools to generate only a generic image that can have any supported u-boot port overlaid. the u-boot ports would need to be updated with meta-data that would describe how each %%SoCs%% or board's u-boot and other pieces are placed into an image. A simple user-land script needs to be created to take a u-boot package for board X and the generic bootable distribution and make an image that's bootable on board X.  This project could be combined with the mining script project described below to creata a 350-hour project. 
- 
----- 
- 
-==== Move to GENERIC armv7 distribution web interface ==== 
- 
-| Mentor | [[WarnerLosh|Warner Losh]] <imp@FreeBSD.org> | 
-| Skills | Shell / Make (intermediate) | 
-| Mid-term deliverable | scripts to mine u-boot ports and screen mock-ups | 
-| Duration | 175 hours | 
-| Difficulty | Medium | 
-| Expected Outcome | Working Web tool to mine u-boot | 
- 
-=== Description === 
- 
-%%FreeBSD%% has grown support for a large number of boards over the past few years, far too many to release images for all of them.  We need a way to securely distribute boot images for dozens or even hundreds of boards. The web app would collect user input, run a script to generate the image, sign the image with a secure signing key, then download the results to the user.  This project could be combined with the release script project described above to creata a 350-hour project. 
  
 ---- ----
Line 405: Line 399:
  
 A rewrite in Python, using pytest, could fix all of these problems except the last.  I have already written a proof of concept demonstrating the basic organization and key features like configurability and privilege modes.  However, there are about 7,000 lines of tests that need to be rewritten.  This project would be great for a beginner, because each test case is small and self contained, and no advanced skills are required.  Also, even an incomplete port would have value.  A partial test suite would still be useful for other projects' CI testing, and another student can easily pick up where this project leaves off.  The student could also make a case for using a different language than Python.  Go and Rust, for example, have been mooted.  But you'll need to find a different mentor if you want to use Go. A rewrite in Python, using pytest, could fix all of these problems except the last.  I have already written a proof of concept demonstrating the basic organization and key features like configurability and privilege modes.  However, there are about 7,000 lines of tests that need to be rewritten.  This project would be great for a beginner, because each test case is small and self contained, and no advanced skills are required.  Also, even an incomplete port would have value.  A partial test suite would still be useful for other projects' CI testing, and another student can easily pick up where this project leaves off.  The student could also make a case for using a different language than Python.  Go and Rust, for example, have been mooted.  But you'll need to find a different mentor if you want to use Go.
 +
 +----
  
 ===== Build infrastructure ===== ===== Build infrastructure =====
 +
 +----
  
 ==== Integrate MFSBSD into the release building tools ==== ==== Integrate MFSBSD into the release building tools ====
  
-| Mentor | [[BradDavis|Brad Davis]] <brd@freebsd.org> |+| Mentor | ? (Email hackers@%%FreeBSD%%.org list for direction) |
 | Skills | C (beginner), make (intermediate), shell (intermediate) | | Skills | C (beginner), make (intermediate), shell (intermediate) |
 | Mid-term deliverable | 'make release' will build MFSBSD | | Mid-term deliverable | 'make release' will build MFSBSD |
Line 425: Line 423:
  
 The issue is that only images for the release versions are usually produced, and MFSBSD tends to get out of sync with the tools in base. The issue is that only images for the release versions are usually produced, and MFSBSD tends to get out of sync with the tools in base.
-There is a desire to have MFSBSD images of the weekly snapshots of -current and -stable that are created by the release engineering time.+There is a desire to have MFSBSD images of the weekly snapshots of -current and -stable that are created by the release engineering team.
 This requires that the process be automated as an additional target in the makefile in src/release. This requires that the process be automated as an additional target in the makefile in src/release.
 It would be similar to the process used now to generate VM images. It would be similar to the process used now to generate VM images.
Line 455: Line 453:
  
 ---- ----
 +
 +==== CI test harness for boot loader ====
 +
 +| Mentor | [[WarnerLosh|Warner Losh]] <imp@FreeBSD.org> |
 +| Skills | shell-script or python (intermediate) |
 +| Mid-term deliverable | An end-to-end test for at least 2 of the %%FreeBSD%% boot environments |
 +| Duration | 175 hours or 350 hours |
 +| Difficulty | Medium |
 +| Expected Outcome | An end-to-end test for all %%FreeBSD%% boot environments that can be added to our CI infrastructure |
 +
 +=== Description ===
 +
 +%%FreeBSD%% can boot in about 40 different boot environments when you count all the combination of architecture, disk partitioning schemes, root filesystem,
 +and encryption. Currently, there's a hodge-podge of shell scripts that are able to build some of these environments, test in others. But there's no unified system to do the building, testing and reporting the results.
 +
 +A successful application will include the above matrix (send email to the Mentor before the deadline to ensure its correctness, or to specifically call out any environments that won't be done in the scope of the project). It will include plans for how to accomplish this task. Bonus points for a good plan for how to integrate into the %%FreeBSD%% CI system and/or github / cirrus-ci system.
  
 Mentors: use this as a template for new ideas: Mentors: use this as a template for new ideas:
Line 470: Line 484:
  
 === Description === === Description ===
- 
-%%-%%--- :!: **End of edit conflict** ---- 
  
 ---- ----
  • summerofcodeideas.1674766622.txt.gz
  • Last modified: 2023/01/26 20:57
  • by WarnerLosh