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 [2022/11/03 18:41] – JosephMingronesummerofcodeideas [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 106: Line 104:
  
 To come. To come.
- 
----- 
- 
-==== Convert all FDT drivers attachments to be table driven and mark with PNP_INFO ==== 
- 
-| Mentor | [[WarnerLosh|Warner Losh]] <imp@FreeBSD.org> | 
-| Skills | C (intermediate), knowledge of kernel build a plus | 
-| Mid-term deliverable | First 2/3 of drivers converted, preliminary GENERIC pruning for 1 board that boots with drivers loading | 
-| Duration | 350 hours | 
-| Difficulty | Medium | 
-| Expected Outcome | All drivers converted, armv7 GENERIC pruned, booting on multiple boards with drivers loading at boot as needed | 
- 
-=== Description === 
- 
-The devmatch infrastructure gives us a way to match up hardware with kernel modules that implement drivers that claim the hardware. One problem, however, is that these drivers need some modification before devmatch can use them. Specifically, they need to have their compatibility scans done via a table, and that table needs to be decorated with a PNP_INFO tag so the compiler and kld_xref extract the metadata that devmatch needs to do its job. In addition, the armv7 GENERIC kernel needs to be trimmed of the drivers that can be loaded like this. Three different boards from different %%SoC%% families have to successfully boot with their drivers that can be loaded automatically. 
- 
----- 
- 
-==== Command Line Editing, history and escape completion in Boot Loader ==== 
- 
-| Mentors | [[WarnerLosh|Warner Losh]] <imp@FreeBSD.org> | 
-| Skills | C (intermediate) and Lua (intermediate) | 
-| Duration | 175 Hours | 
-| Difficulty | Medium | 
-| Expected Outcome | Boot loader prompt that supports command line editing and history | 
- 
-The current boot loader lacks any kind of command history and editing. This is because it was designed to be small. Now that UEFI has greatly expanded the limits, it makes sense to bring in functionality like this.  This effort would involve creating a number of primitives for expansion, storing the history, etc. It would likely also require some lua integration to work.  This project is one that has a lot of sub-parts, some of which may be omitted (eg command history w/o filename completion) and still result in good project. 
  
 ---- ----
Line 166: Line 137:
 ---- ----
  
-==== Complete FreeBSD's MPLS implementation ====+==== Implement MPLS support for FreeBSD ====
  
-| Mentor | George V. Neville-Neil gnn@%%FreeBSD%%.org |+| 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.+
  
 ---- ----
  
-==== Linuxulator on powerpc64 ====+==== Improve netgraph concurrency ====
  
-| Mentor | [[JustinHibbits|Justin Hibbits]] <jhibbits@FreeBSD.org>, [[BrandonBergren|Brandon Bergren]] <bdragon@FreeBSD.org> | +| Mentor | Alexander Chernikov <melifaro@FreeBSD.org> | 
-| Skills | C (intermediate), kernel (intermediate) | +| Skills | C (intermediate), networking (intermediate) | 
-| Duration | 175 hours |+| Mid-term deliverable | Traffic is able to pass in a lockless fashion in 2-node netgraph topology | 
 +| Duration | 350 hours |
 | Difficulty | Medium | | Difficulty | Medium |
-| Expected Outcome | Simple Linux binary support on %%FreeBSD%%/powerpc64 |+| Expected Outcome | Traffic is able to pass in a lockless fashion between ng_%%<%%ppp%%|%%car%%|%%tee%%|%%iface>, compatibility retained with non-converted nodes |
  
 === Description === === Description ===
  
-%%FreeBSD%% provides optional binary compatibility with Linux, allowing users to install and run unmodified Linux binaries. The Linux binaries can be started in the same way native %%FreeBSD%% binaries can.  They behave almost exactly like native processes and can be traced and debugged the usual way.  The "linuxulator" is available for the i386, amd64, and arm64 architectures.  This aim of this project is to add preliminary linuxulator support for %%FreeBSD%%/powerpc64.+[[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 
  
 ---- ----
  
-==== Implement  Netlink (RFC 3549) kernel support ====+==== Linuxulator on powerpc64 ====
  
-| Mentor | [[AlexanderChernikov|Alexander Chernikov]] <melifaro@FreeBSD.org>, [[MahdiMokhtari|Mahdi Mokhtari]] <mmokhi@FreeBSD.org> | +| Mentor | [[JustinHibbits|Justin Hibbits]] <jhibbits@FreeBSD.org>, [[BrandonBergren|Brandon Bergren]] <bdragon@FreeBSD.org> | 
-| Skills | C (intermediate), Kernel (intermediate) | +| Skills | C (intermediate), kernel (intermediate) | 
-| Mid-term deliverable | able to setup AF_NETLINK sockets and pass a request to the routing subsystem (NETLINK_ROUTE) | +| Duration | 175 hours |
-| Duration | 350 Hours |+
 | Difficulty | Medium | | Difficulty | Medium |
-| Expected Outcome | Routing daemon of choice (bird,frr,..) is able to interact with kernel routing subsystem via netlink. implement another netlink family, preferrably NETLINK_KOBJECT_UEVENT |+| Expected Outcome | Simple Linux binary support on %%FreeBSD%%/powerpc64 |
  
 === Description === === Description ===
-Netlink is widely used in Linux for many network-related kernel to userspace communications. Many apps require kernel netlink support to work, making them hard to port to %%FreeBSD%%. The goal of this project is to add Netlink support to %%FreeBSD%% kernel for route and notification protocol families.+ 
 +%%FreeBSD%% provides optional binary compatibility with Linux, allowing users to install and run unmodified Linux binaries. The Linux binaries can be started in the same way native %%FreeBSD%% binaries can.  They behave almost exactly like native processes and can be traced and debugged the usual way.  The "linuxulator" is available for the i386, amd64, and arm64 architectures.  This aim of this project is to add preliminary linuxulator support for %%FreeBSD%%/powerpc64.
  
 ---- ----
Line 237: Line 218:
  
 ===== Userland projects ===== ===== Userland projects =====
- 
-==== ELFToolChain improvements ==== 
- 
-| Mentor | [[EdMaste|Ed Maste]] <emaste@FreeBSD.org> | 
-| Skills | C (intermediate) | 
-| Mid-term deliverable | LLVM bytecode support for ar/nm/ranlib | 
-| Duration | 175 or 350 hours | 
-| Difficulty | Easy | 
-| Expected Outcome | Support archive files containing LLVM bitcode | 
- 
-=== Description === 
- 
-The elftoolchain project provides %%FreeBSD%% with several commands for handling ELF executables, including "ar", "addr2line", "elfdump", "nm", "strings", amongst others.  These replaced the equivalent tools from GNU binutils.  A useful project needed to support LLVM's Link-Time-Optimization would be to extend ar, ranlib and nm to support archive files containing LLVM bitcode files.  These files have their own container format; the project would involve adding a small parser that is sufficient to extract information required by these tools (e.g., the symbol table). 
- 
-Another potential task within the project would be to investigate the GNU binutils test suites for these tools and attempt to run them using the %%ELFToolChain%% equivalents, with the aim of finding and fixing bugs and incompatibilities. 
  
 ---- ----
  
-==== 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 261: 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 275: 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 282: Line 248:
  
 === Description === === Description ===
- 
-%%FreeBSD%%'s [[https://svnweb.freebsd.org/base/head/sys/ufs/|UFS]] is arguably the longest standing UNIX file system still under active development. It is well documented and has many interesting features.  While UFS has been ported to Linux and Mac OSX, the ports are not very good or have been deprecated. Using fusefs as a userland option would let the filesystem be used on many other systems. Existing %%FreeBSD%% headers and code can be reused but a fresh design using modern C++ constructs would be interesting. 
  
 **This project is challenging**: any proposal must include a coding plan and should include credible evidence of userland filesystem development. **This project is challenging**: any proposal must include a coding plan and should include credible evidence of userland filesystem development.
Line 311: 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 465: 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 485: 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 491: Line 429:
  
 ---- ----
 +
 +==== Finish upstreaming bsd-user enhancements ====
 +
 +| Mentor | [[WarnerLosh|Warner Losh]] <imp@FreeBSD.org> |
 +| Skills | C (intermediate) |
 +| Mid-term deliverable | All system calls into a patch stream for upstream, and can build packages with poudriere |
 +| Duration | 175 hours |
 +| Difficulty | Easy |
 +| Expected Outcome | All bsd-user changes from our fork are upstream |
 +
 +=== Description ===
 +
 +bsd-user is a set of modifications to the QEMU project. It is similar to the linux-user feature that's integrated into the QEMU project. Years ago, we forked our own tree, and had difficulty getting the changes at the time upstream. Since then, upstream attitudes have changed and they are very eager to get the bsd-user changes committed.
 +
 +The current bsd-user fork is up-to-date with the latest qemu-project repo (as of the 7.2 release). The task here would be to break down the differences between our tree and upstream.
 +
 +There's three groups of changes:
 +(1) Changes to the binary loading. These are mostly the same upstream, but were originally based on linux-user. linux-user has evolved, but some of the relevant changes have not been merged over from linux-user. It is also desirable that refactoring the common items, like elf loading, could result in more code reuse and bsd-user's ability to keep up faster than it can today.
 +(2) bsd-user has a number of architectures (powerpc, riscv and aarch64) that aren't in upstream today. These changes need to be broken down in to 50-100 line chunks, reviewed by the upstream and contributed to the maintainer to get into upstream. In addition, any adjustments or enhancements to the ABIs that have happened since the code was originally written may require adjustment to the current code.
 +(3) bsd-user only has about half of the system calls implemented in the fork upstreamed. These also need to be chunked into small patches that can be reviewed upstream. There are some system calls that are poorly placed as well and may need changes to bsd-user's fork to correct.
 +
 +A successful project will result in all or most of the changes being upstreamed. The successful candidate will also need to understand where to find %%FreeBSD%%'s implementation for the architectural specific bits, as well as an understanding of setting up a poudriere build world, using poudriere jails and ways to effectively test subsets of the all the packages to ensure problems are corrected. A/B testing with the current really old version of qemu bsd-user based on 3.2 will help control regressions.
 +
 +----
 +
 +==== 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:
  • summerofcodeideas.1667500904.txt.gz
  • Last modified: 2022/11/03 18:41
  • by JosephMingrone