FreeBSD Google Summer of Code Ideas

Below are ideas for FreeBSD GSoC which the FreeBSD community have suggested. They should be approximately 12-week of work for Summer of Code.

These are only suggestions: copy/pasting the text in your proposal doesn't guarantee we will acccept it. You can propose ANY FreeBSD-related idea/project you want but we want to see that you have researched the project and that you have a clear plan. We like original ideas, since we know you'll be most interested in working on something you came up with and are passionate about. Remember this must be a 12-week project and we want to see some schedule.

It is especially important that Summer of Code applicants contact idea owners or suitable mentors early so that they can get feedback during the application process, and that the project can reasonably be completed in the GSoC timeframe. For projects where no mentor is listed, or for project proposals created by students, we recommend you try to contact committers working in the area and discuss the project with them. Please add '@FreeBSD.org' to any email address listed in the form gavin@. If you are unsure who to contact, please see the SummerOfCodeContacts page.

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: SummerOfCode2017, SummerOfCode2016, SummerOfCode2015, SummerOfCode2014, SummerOfCode2013, SummerOfCode2012, SummerOfCode2011, SummerOfCode2010.

How to use this idea list

For students

Skill levels

Remember that GSoC is 12 weeks of full time (30-40 hours/week) work. Choose a project you feel you can realistically do within the 12-week timeline

Ideas list


Kernel Projects

Import the Xen grant-table bus_dma(9) handlers from OpenBSD

Mentor

 Roger Pau Monné royger@FreeBSD.org

Skills

C (advanced), knowledge of virtualization is a bonus

Mid-term deliverable

Have a Xen-specific implementation of bus_dma(9) in order to map and share grants with domains

Final deliverable

Have the interface fully integrated with all the frontends and backends present in FreeBSD

Description

In order to implement Xen paravirtualized drivers, an abstract reference to memory pages is used. This mechanism is called grant references and are used in order to exchange information in a safe way between Xen domains. This interface is also extensively used by Xen paravirtualized IO drivers, and it's current implementation in FreeBSD is lacking a proper integration with the rest of the system. OpenBSD has integrated grant references into it's bus_dma(9) subsystem, allowing Xen drivers to use a more transparent integration with the rest of the OS. The aim of this project is to bring the OpenBSD bus_dma(9) grant table handlers from OpenBSD into FreeBSD, expand them in order to support all the grant operations (share and map), and modify the existing frontends and backend in FreeBSD in order to make use of them.

The OpenBSD implementation can be found in src/sys/dev/pv/xen.c and a talk about it at Implementation of Xen PVHVM drivers in OpenBSD

Add support for booting a Xen Dom0 from EFI

Mentor

 Roger Pau Monné royger@FreeBSD.org

Skills

C (advanced), EFI, knowledge of virtualization is a bonus

Mid-term deliverable

Have a multiboot2 implementation capable of booting Xen from the FreeBSD/EFI loader

Final deliverable

Be able to boot a FreeBSD/Xen Dom0 from EFI using the FreeBSD loader

Description

The current multiboot support in the FreeBSD loader only allows booting a FreeBSD/Xen Dom0 when booted from legacy BIOS. In order to boot a FreeBSD/Xen Dom0 from EFI the FreeBSD loader must implement support for the multiboot2 protocol [0]. This has been recently implemented in both grub and Xen in order to boot Xen plus a Linux kernel from EFI using grub.

The following is a rough list of the task to perform:

[0] https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html


Kernel fuzzing suite

Mentor

??

Skills

C (intermediate), kernel(intermediate)

Mid-term deliverable

Get a fuzzing tool working

Final deliverable

Fuzz test the FreeBSD Kernel

Description

FreeBSD's memguard(9), and the compiler stack protection offer a good framework to detect memory leaks and buffer overflows in the kernel and the complete OS is frequently checked with static analysis tools, but we lack kernel specific fuzzer testing tools to aid in such detection. Originally the linux Trinity fuzzer was the main example of such tool, Dmitry Vyukov's syzkaller is somewhat more promising, and as of lately there is also the TriForceAFL used for OpenBSD.

A native tool would be good but perhaps just running the Trinity tool under the linux emulator, along with memguard(9), would reveal general bugs in the kernel.


Verification of bhyve's instruction emulation

Mentor

Peter Grehan grehan@freebsd.org

Skills

C (intermediate), computer-architecture(intermediate)

Mid-term deliverable

Tests for a couple of instructions

Final deliverable

Set of automated tests for all instructions

Description

Intel VT-x provides very little assistance to the hypervisor when a guest issues an MMIO access, instead leaving it up to the hypervisor to emulate the instruction used by the guest.

bhyve has software emulation of a small number of instructions. However, it is difficult to prove that these emulations are correct. They have to execute in a number of processor modes, and the side effects of the instructions can be intricate.

This project will attempt to create a test harness for the instruction emulation code, perhaps using the open-source Intel XED tool, which should give confidence that the existing code is correct and provide a mechanism to develop future instruction emulation.


VGA emulation improvements for bhyve

Mentor

Tycho Nightingale tychon@freebsd.org

Skills

C (intermediate), computer-architecture(intermediate)

Mid-term deliverable

Performance improvement in text mode for FreeBSD guests

Final deliverable

Text and VESA modes tested against different guest o/s's

Description

bhyve ships with a VGA/VESA device emulation, though it is little-used compared to the UEFI frame buffer. However, this is useful for booting older guest o/s's.

There are some functional and performance limitations with this code. For example, text-mode rendering uses most of one CPU even when a guest is idle.

Although a linear frame buffer is available through VESA, this hasn't been significantly tested, and should be verified by running a number of different guest operating systems.

This project will examine the VGA emulation in detail. The student should have an interest in computer graphics as well as virtualization.


PowerPC, ARM, MIPS new platform bring-up

Mentor

Unknown, see details below

Skills

C (advanced) kernel (advanced), computer-architecture (intermediate)

Mid-term deliverable

Must boot to the point where the kernel can print stuff on UART/console

Final deliverable

Ideally, reach at least single-user mode

Description

There's a number of PowerPC, ARM, and MIPS SoCs (system-on-chip) that are in consumer grade routers, mobile phones, etc that have chips that are supported by FreeBSD, or nearly supported by FreeBSD. Pick one and get FreeBSD booting on it. Integrate it into the tree.

For PowerPC/ARM/MIPS a lot of code already exists and can likely be made use of for several devices. For new CPUs some very low-level code may well need to be written, which will involve a good understanding of the low-level hardware or a willingness to learn. Some device drivers for e.g. timer devices may also need to be developed.

As each platform is different, it's not possible to suggest a mentor to contact in this description. Instead, it's recommended you email the freebsd-embedded@FreeBSD.org mailing list, detailing the CPU you would like to work on, and appeal for a mentor. If you can't find a mentor, please email soc-admins@FreeBSD.org and we'll assist.


Improve support for an embedded CPU/board

Mentor

Unknown, see details below

Skills

C (intermediate), kernel(intermediate)

Mid-term deliverable

To be determined

Final deliverable

To be determined

Description

FreeBSD has a variable level of support for a wide range of ARM and MIPS CPUs and system-on-chips, but not all of the hardware available on them are supported fully. Some CPUs entirely lack support or do not fully support all available peripherals. For example, sometimes SATA interfaces are not supported, or USB controllers, or graphics hardware, etc. This project is to take a common CPU/embedded board, and write missing drivers and/or improve existing drivers, with the end goal that all peripherals on a particular CPU would be fully supported. See https://wiki.freebsd.org/FreeBSD/arm and https://wiki.freebsd.org/FreeBSD/mips for details on supported boards, though please be aware that these pages are not fully up-to-date.

Suggested CPUs (and boards) include boards based on Allwinner (CubieBoard1, CubieBoard2) or Rockchip (Radxa Rock, Radxa Rock Lite) CPUs, or platforms like the Samsung Chromebook (Exynos 5 CPU) or the BeagleBone (TI AM335x CPU). All of these are available in a number of easily-obtainable boards. Peripherals you should aim to test and/or write/complete support for include SATA controllers, SD/MMC interfaces, I2C and SPI interfaces, sound, graphics hardware (2D only), USB/USB2/USB3, GPIO, wired Ethernet, RNGs, and crypto offload hardware. If there is time, other peripherals such as WiFi and 3D graphics etc support could be investigated, although be aware that each of these could be an entire GSoC-sized project by itself.

Many of these peripherals are under-documented. As a result, this project is likely to involve looking at vendor code and code in other operating systems, determining how that code drives the hardware in question, and implementing equivalent code in FreeBSD. Note that copying code directly from GPL sources is not permitted.

Before signing up to do this task, you should determine exactly how well a platform is supported, either through mailing list discussions, IRC discussions, etc. Please note that it is unlikely that FreeBSD will be able to supply hardware for this project, students are expected to already have access to suitable hardware.

As each platform is different, it's not possible to suggest a mentor to contact in this description. Instead, it's recommended you email the mailing list for the architecture you're wanting to work on (e.g. freebsd-arm@FreeBSD.org, freebsd-mips@FreeBSD.org or freebsd-powerpc@FreeBSD.org), detailing the CPU you plan to work on, and appeal for a mentor. If you can't find a mentor, please email soc-admins@FreeBSD.org and we'll assist.


Implementing the Parallel Scheduling Parallel Transmission (PSPAT) subsystem on FreeBSD

Mentor

Giuseppe Lettieri giuseppe.lettieri@unipi.it

Skills

C (advanced), knownledge of the kernel networking subsystem

Mid-term deliverable

Mechanism to intercept outgoing packets and divert them to one or more dispatcher kthreads (no scheduling)

Final deliverable

Integration with dummynet to have one of the kernel threads to perform packet scheduling

Description

Virtual Machines in the data center may legitimately generate millions of packets per second. The hosting platform, hence, needs robust packet scheduling mechanisms that support these rates and, at the same time, provide isolation and dependable service guarantees under all load conditions. Current hardware or software packet scheduling solutions fail to meet all these requirements, most commonly lacking on either performance or guarantees. In particular, scheduling outgoing packets at high rate may cause high locking contention (on the scheduler) among transmitting threads running on different CPUs. This often causes reduced throughput and divergence from the nominal rates. The PSPAT architecture proposes a different approach where scheduling (and actual transmission) is performed by a separate kernel thread, and clients are decoupled from the scheduler using lock-free queues. A first prototype, implemented for the Linux kernel, already shows the benefits of this approach. The student is asked to implement the PSPAT architecture in the FreeBSD kernel, in the following way: 1) Intercept all the packets right before the if_output, and push them to an ad-hoc per-CPU lockless queue (queue implementation is already available) 2) Implement a "scheduler" kernel thread, that reads from the the per-CPU lockless queues and runs the scheduling algorithm (without the need of locking, as it is the only user of the scheduling algorithm). 3) As packets exit the scheduling algorithm, transmit them (in batch), either directly from the scheduler thread or using separate dispatcher threads.

The PSPAT paper is available at http://info.iet.unipi.it/~luigi/papers/20160921-pspat.pdf. An implementation for the Linux kernel can be found at https://github.com/giuseppelettieri/linux-pspat/tree/pspat-4.13, in the net/pspat directory.


Integrate QEMU and libvmm

Mentor

Giuseppe Lettieri giuseppe.lettieri@unipi.it

Skills

C (advanced), knownledge of virtualization technologies

Mid-term deliverable

Add an abstraction layer inside QEMU towards hardware acceleration functionalities (currently KVM)

Final deliverable

Extend libvmm to match the same functionalities that KVM offers to QEMU on Linux

Description

QEMU is a very popular and feature-rich hypervisor, already available for FreeBSD. However, currently QEMU does not integrated with libvmm to benefit from FreeBSD support for hardware-assisted virtualization. The idea for this project is to: 1) identify the current differences between FreeBSD libvmm and Linux KVM kernel modules (and related APIs) 2) introduce a shim layer inside QEMU to abstract away how QEMU uses these hardware assisted virtualization technologies. 3) extend libvmm to match the features exposed by KVM, so that QEMU can run with hardware acceleration also on FreeBSD.


Convert all FDT drivers attachments to be table driven and mark with PNP_INFO

Mentor

 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

Final deliverable

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. 3 different boards from different SoC families have to successfully boot with their drivers that can be loaded automatically loaded automatically.


Convert all PCI drivers attachments to be table driven and mark with PNP_INFO

Mentor

 Warner Losh imp@FreeBSD.org

Skills

C (intermediate), knowledge of kernel build a plus

Mid-term deliverable

First 2/3 of drivers converted, preliminary trimmed GENERIC booting w/autoload

Final deliverable

All drivers on the list converted, final GENERIC trim, kernel booting w/autoload

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 device ID 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. The problem is that the PCI drivers are all over the place in terms of how they match device IDs, etc, so work will be needed to move some of the in-line code to tables, some of the tables lookups may be able to be move to standardized routines, etc. There's a lot of these drivers, so a significant subset would be acceptable, but the list must be set up front and shouldn't cherry-pick just the easiest drivers. Trimming GENERIC to show that the converted drivers work is also required.


Userland projects

IPv6 Userland Cleanup

Mentor

TBD

Skills

C (intermediate), networking (intermediate)

Mid-term deliverable

Have at least rpc.statd and rpc.quotad work over IPv6

Final deliverable

Have more tools work over IPv6

Description

Several userland network utilities do not work correctly with IPv6.

This project could also include a broader survey of other network services in /usr/bin and /usr/sbin to make sure they're all IPv6 clean. This project could fube further developed. Some more of this includes:


Dual-stack ping(1) command

Mentor

 Gavin Atkinson gavin@FreeBSD.org

Skills

C (intermediate), networking (intermediate)

Mid-term deliverable

Version of "ping" with basic functionality for both v4 and v6 hosts

Final deliverable

Fully functional unified ping command, maintaining all functionality from both versions

Description

Currently there are two tools: ping (for IPv4 networks), and ping6 (for IPv6 networks). Between the two commands there's a lot of duplicate functionality, but there's also a lot of necessary divergence. Unifying these commands (and allowing user selection for IPv4 or IPv6 functionality) would mean only requiring one utility.

Care will need to be taken to not change any output from the commands which may be relied upon in scripts, etc.


Dual-stack traceroute(1) command

Mentor

Gavin Atkinson gavin@FreeBSD.org

Skills

C (intermediate), networking (intermediate)

Mid-term deliverable

Version of "traceroute" with basic functionality for both v4 and v6 hosts

Final deliverable

Fully functional unified traceroute command, maintaining all functionality from both versions

Description

Currently there are two traceroute tools: traceroute (for IPv4 networks), and traceroute6 (for IPv6 networks). Between the two commands there's a lot of duplicate functionality, but there's also a lot of necessary divergence. Unifying these commands (and allowing user selection for IPv4 or IPv6 functionality) would mean only requiring one utility.


elftoolchain bug finding/fixing

Mentor

Ed Maste emaste@FreeBSD.org

Skills

C (intermediate)

Mid-term deliverable

(need midterm goal)

Final deliverable

(need final goal)

Description

The elftoolchain project provides FreeBSD with several commands for handling ELF executables, including "ar", "addr2line", "elfdump", "nm", "strings", amongst others. The GNU Project provides a testsuite which could be used to find bugs and incompatibilities in these tools. The goal here would be to test the elftoolchain tools, and for each issue found, fix it.


Move to GENERIC armv7 distribution scripting

Mentor

Warner Losh imp@FreeBSD.org

Skills

Shell / Make (intermediate)

Mid-term deliverable

release scripts working, u-boot ports updated

Final deliverable

User tool

Description

FreeBSD has grown a large number of boards over the past few years. Far too many to release images for all the boards for. 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 SoC's or board's u-boot and other pieces are places 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.


Move to GENERIC armv7 distribution web interface

Mentor

Warner Losh imp@FreeBSD.org

Skills

Shell / Make (intermediate)

Mid-term deliverable

scripts to mine u-boot ports and screen mock-ups

Final deliverable

Web tool working

Description

FreeBSD has grown a large number of boards over the past few years. Far too many to release images for all the boards for. 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.


Porting lldb to the new Native API

Mentor

Domagoj Stolfa domagoj.stolfa@cl.cam.ac.uk

Co-Mentor

Ed Maste emaste@freebsd.org

Skills

C++ (advanced), debuggers (advanced), knowledge of kernel APIs, willing to learn FreeBSD's

Mid-term deliverable

An initial port that runs and can debug simple programs

Final deliverable

A new port of lldb that has near-feature parity with the current one using the new API

Description

LLDB aims to be a an official debugger for the LLVM project. FreeBSD currently has a port of it using the old API that is slowly being deprecated. This results in lack of support for features such as lldb-server, no support for updates that happen in upstream with respect to the new API and subpar error reporting.

The purpose of this project is to develop a new port of LLDB to FreeBSD using the NativeProcess, NativeThread and NativeRegisterContext APIs in order to allow us to exploit the new features that appear in the generic code in upstream LLDB and fix long-standing bugs in the current port. There is existing code that implements initial functionality based on the NetBSD code which the student could use as a starting point. The first step would be to clearly identify what the current LLDB port supports and identify goals that have to be met in the new port to achieve feature parity, which can be guided by the extensive LLDB test suite.


Testing

audit framework test suite

Mentor

George Neville-Neil gnn@freebsd.org

Co-mentor

Robert Watson

Skills

Python or similar (intermediate), Basic understanding of C

Mid-term deliverable

Tests for a small set of audit tracepoints integrated into Kyua framework

Final deliverable

Set of automated tests for a all audit tracepoints

Description

FreeBSD's audit(4) system is a widely used security mechanism for auditing access to the operating system kernel and its facilities, including storage and networking. Although the audit framework itself is quite mature, and is used outside of FreeBSD, notably on Mac OS and related products, it is in need of a set of automated tests so that it can be reliably extended with minimal risk of the introduction of security regressions.

On this project students will learn about computer systems security as well as how security mechanisms are implemented in a production operating system. The ideal student for this project is one who is interested in learning about computer security and security mechanisms permeate the system in a broad way, touching on every service provided by the operating system, including processes, file systems, networking etc.


Add more FreeBSD testing to Xen osstest

Mentor

Roger Pau Monné royger@FreeBSD.org

Co-mentor

Ian Jackson <ian.jackson AT eu.citrix DOT com>

Skills

Perl and shell (to write tests for osstest), FreeBSD system administration: pxe install, complete setup, build from sources, generate installer media

Mid-term deliverable

osstest should be able to setup a FreeBSD bare-metal box and automatically generate the installer media to setup itself

Final deliverable

osstest should be able to compile Xen on FreeBSD, generate guest install media and test it automatically

Description

The current Xen Project test system only has minimal support for FreeBSD: it's able to test a FreeBSD guest, but it's not able to setup a FreeBSD host or perform a Xen compilation on FreeBSD. This project aims to solve this by providing better integration of FreeBSD into the Xen test system (osstest).

First tasks will involve writing the necessary code so that osstest can setup a FreeBSD host and be able to build new FreeBSD host install media, so that we can start tracking FreeBSD upstream. Next steps will involve compiling Xen on FreeBSD and also generating FreeBSD guest install media, so that guests are also tracking upstream FreeBSD.

An initial attempt at this can be found on https://lists.xenproject.org/archives/html/xen-devel/2015-02/msg00280.html. The student can use part of this as a baseline if desired.


Integration testing for the netmap subsystem

Mentor

Giuseppe Lettieri giuseppe.lettieri@unipi.it

Skills

C (advanced), knownledge of the netmap subsystem

Mid-term deliverable

A scriptable library that allows to access all of the netmap control and data transfer APIs

Final deliverable

A set of positive and negative test scripts that cover the whole API

Description

The netmap framework was originally designed to provide a simple and efficient API for applications to directly transmit and receive Ethernet frames to/from physical NICs. However, in recent years netmap has been extended with many features to support fast Inter Process Communication (netmap pipes), virtual switches (VALE), interface monitoring (netmap monitors), Virtual Machine pass-through (ptnetmap), etc., and several options to specify how to bind a netmap file descriptor to a physical or virtual interface. Because of its flexibility and richness of features, netmap has become increasingly complex and hard to maintain or upgrade from a software engineering standpoint, leading to frequent inconsistencies and bugs. This project aims at developing a python library (or equivalently a set of command line tools written in C) that exports the whole netmap API, including the control operations (registering an interface, getting information about interface and pool allocation, etc.), and data transfer operations (transmitting/receiving packets with various patterns, using all the types of netmap ports in several combinations). Once the library is ready, the student would proceed to define a set of positive tests (check that things that are supposed to work do actually work), and negative ones (check that things that are supposed to fail do indeed fail).

The current netmap API (control and data transfer is available in this header file https://github.com/luigirizzo/netmap/blob/master/sys/net/netmap.h. The original netmap paper can be found here http://info.iet.unipi.it/~luigi/papers/20120503-netmap-atc12.pdf.


Audit Base for Read-Only and NFS Mount Compatibility

Mentor

Amazing Subject Matter Expert

Co-mentor

Michael Dexter dexter@freebsd.org

Skills

/bin/sh (moderate), System and Network configuration, sqlite, berkelydb and similar (moderate), hier(7) and general FreeBSD base awareness

Mid-term deliverable

Identification of in-base components that are r/o|NFS incompatible

Final deliverable

Report on the nature of each incompatibility, ideally with proposed solutions. Kyua test suite modules for each issue identified

Description

FreeBSD has supported read-only and "root on NFS" for decades but has not experienced consistent testing for compatibility under these circumstances. Issues can include the failure of utilities to create temporary files and locking failures with "databases" such as /etc/pwd.db, /var/db/pkg/local.sqlite and /var/db/xenstore/dbf. Temporary workarounds include tmpfs(5) mounts for directories such as /var/db/<utility>, MD/MFS mounts, iSCSI/FC/ggate devices, or network-based authentication. Long-term solutions can follow the model of pkg(8)'s NFS_WITH_PROPER_LOCKING=yes option.

Search terms to help understand the problem: "NFS flock", "sqlite on NFS". Motivation: "Cloud" and "Container" environments often achieve statelessness via simple mechanisms like read-only and network file system mounts.


Build infrastructure

Integrate MFSBSD into the release building tools

Mentor

Allan Jude allanjude@

Co-Mentor

Roger Pau Monné royger@FreeBSD.org

Co-mentor

Brad Davis??

Skills

C (beginner), make (intermediate), shell (intermediate)

Mid-term deliverable

'make release' will build MFSBSD

Final deliverable

Completed integration so all new releases of FreeBSD will include mfsbsd media

Description

MFSBSD is a version of FreeBSD designed to run from memory. It is often used as a rescue system, or the basis for automated installers.

It is currently maintained by a FreeBSD developer, Martin Matuška

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. 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. Adding flexibility to the MFSBSD build system to control additional features would be a bonus


Ports: Porting third-party software to FreeBSD

CoreCRL: add Microsoft's CoreCRL and CoreFX to the Ports tree.

Mentor

ports@

Skills

C ( intermediate), Ports (intermediate)

Mid-term deliverable

Ports for the base .Net support available

Final deliverable

Port Microsoft's Powershell

Description

CoreCRL is the Microsoft NET Core runtime and CoreFX are the .NET Core foundational libraries. Both are required to make Microsoft Powershell usable on FreeBSD.

Some work on porting .NET to FreeBSD exists already, including build bots, however it is not yet at the point where it can be fully bootstrapped yet. This project would involve moving the existing work forwards, ideally to the point where .NET is as usable on FreeBSD as on other platforms.

Once this is complete, it should then be possible to get PowerShell fully functional on FreeBSD.

SummerOfCodeIdeas (last edited 2018-02-22 19:33:02 by MichaelDexter)