• SummerOfCodeIdeas

FreeBSD Google Summer of Code Ideas

This page lists FreeBSD project ideas for Google Summer of Code (GSoC). If you plan to apply to work on a FreeBSD GSoC project, you should contact one or more mentors as soon as possible to get feedback. We want to ensure projects have a reasonable chance of being successfully completed.

How to use this idea list

This list of project ideas should be regarded as inspiration, not an exclusive list. You can propose any FreeBSD-related project you want, but whether you apply using your own project idea or one here, we want to see that you thoroughly researched the project in coordination with one or more potential mentors and that you have a clear plan. If you are interested in working with a mentor who is not listed here, you can contact FreeBSD developers using one of these methods.

• Send an email to the <freebsd-hackers AT FreeBSD DOT org> mailing list.

• Join the #freebsd-soc IRC channel on the Libera.Chat network. We use this channel for communication during both the application period and the coding period. You can join the channel either using an IRC client like irssi, or using Libera.Chat's web client. You can read about how to connect to the Libera.Chat network. Due to timezone differences, there may be delays before questions are answered, so please be patient.

• If you do not get a response on IRC or on the mailing list, you can email <soc-admins AT FreeBSD DOT org>.

We also have a few pages that list other project ideas: Ideas Page, Junior Jobs, and Wanted Ports. Note that many of these ideas may not be suitable GSoC projects as-is but may provide inspiration.

If you need even more inspiration, see SummerOfCode for projects from previous years.

Skill levels

Starting in 2024, projects can be small (~90 hours), medium (~175 hours), or large (~350 hours) and last from 8 weeks to 12 weeks or be extended up to a 22-week work term. Choose a project that you feel you can realistically complete within one of those timelines. Again, mentors can help you gauge how much effort and experience a given project may require.

• C: For C-related ideas, at least some experience coding in C is necessary. Generally, it is easier to work on the userland than the kernel. Kernel programming and debugging are harder and can involve skills ranging from understanding operating system internals to computer architecture.

• Kernel: The FreeBSD kernel is written in C, so at least a basic proficiency in C is required for a kernel project. Various levels of other skills may be necessary, but you can certainly assume that knowing how to do "Hello world" in the kernel and knowing how to recompile the kernel should be an essential starting point.

• Network: Understanding TCP/IP will be required for these projects. It would be beneficial if you understood socket API for any programming language and understood how sockets work.

• Security: For these tasks, you must have a general understanding of security issues, the UNIX permission model, and the basics of cryptography and its applications.

• Scripting: For scripting projects, unless otherwise stated, we won't enforce a specific scripting language on you. However, there are certain factors to consider. If you are willing to work with /bin/sh (+awk, sed, etc.) or Lua, there is a chance that whatever you produce could be committed to the base system. If you pick something like bash, which is not part of FreeBSD's base system, your tool can only be considered for the ports tree, which is a repository with instructions to build third-party software for FreeBSD.

Kernel Projects

mac_do(4) improvements

[last updated: 2025-01-28]

Please see also the related project mdo(1) improvements. To interested students: Please consider combining both in a single medium-duration project (175 hours).

mac_do(4) is a kernel module that can enable controlled process credentials transitions, such as changing the user IDs or group IDs to particular values. Processes that make such requests and are authorized by mac_do(4) do not need to be root, in particular not to have been spawned from an executable tagged with the setuid bit.

For more information about mac_do(4), please consult the 2024 Q3's status report. Note that all the changes evoked in this report have been completed and are now in the tree.

(Remark: The online manual page for mac_do(4) (from man.freebsd.org) has not been updated to the current in-tree version. The latter's source can be found at https://cgit.freebsd.org/src/tree/share/man/man4/mac_do.4.)

Currently, mac_do(4) only authorizes processes spawned from the /usr/bin/mdo executable, and this is not configurable. By contrast, credentials transition rules are configurable and per-jail (via the sysctl(8) knob security.mac.do.rules and the mac.do.rules jail parameter). We would like to enable mac_do(4) to support a list of executable that are authorized to request credential transitions (with the aim to leverage mac_do(4) with user applications in the future), and to be able to specify a specific list for each jail (to accomodate thin or custom jail scenarios). The framework to do that basically already exists, as it has been developed to implement the above-mentioned handling of rules. This task thus consists in leveraging it, changing some of the internal structures that are associated to jails to hold the allowed paths list, modifying the code that needs to read the list in order to support parallel accesses, and coding accessors so that an administrator can control the list via sysctl(8) and jail parameters.

mac_do(4) currently can only authorize credential transitions that are requested via the companion setcred(2) system call. The reason for the need of this specific system call is explained in more details in the 2024 Q3's status report but, in a nutshell, as mac_do(4) only authorizes configured credential transitions, it needs to see both the current process credentials state unmodified and the requested final one. However, each call to traditional and/or standard credentials-changing functions, such as setuid(2), seteuid(2), etc., can be considered as a (limited) full transition on its own, which mac_do(4) could decide upon. This functionality could allow to control transitions to root and, combined with that of the previous point, to install credentials-granting programs without the setuid bit set. An earlier version of mac_do(4) used to hook some of these calls, and lead to developing an infrastructure that helps to code fine-grained checks on top of the MAC framework interfaces, which are too limited for a straigtforward implementation, and in a safe manner with respect to parallel changes (e.g., to configured rules). (In mac_do(4)'s code, see in particular struct mac_do_data_header and struct mac_do_setcred_data.) Leveraging this infrastructure, the student is expected to code in mac_do(4) the appropriate MAC hooks for all traditional and/or standard credentials-changing functions.

While mac_do(4) can log diagnostics on failure to set rules (because of syntax errors), it currently does not log whether it denies or accepts credentials transition requests. Having this functionality to diagnose rule problems and/or unauthorized accesses would be desirable. If time permits, we could consider adding audit logging in mac_do(4) proper, in addition to what is already present in the various credentials-changing system calls.

Port FreeBSD to QEMU MicroVM

[last updated: 2025-01-24]

Example tasks:

• Write device drivers for QEMU MicroVM
• Create kernel configuration
• Create FreeBSD boot images for MicroVM

There is an existing POC of this port, by thj@, but it is unstable and needs further investigation. A log of this effort is here: https://adventurist.me/posts/00320

Implement a new VLAN filtering software bridge

[last updated: 2025-01-24]

The existing if_bridge(4) driver impedes FreeBSD suitability as a host for virtual machines and vnet enabled jails in design and implementation. Its configuration interface encourages misconfigurations by being too permissive, yet it lacks expected features.

Other operating systems have encountered similar design problems with their respective bridge drivers. After two attempts, OpenBSD came up with a clean design we can learn from: veb(4) and vport(4).

Our bridge member interfaces remain usable as IP capable interfaces which violates IP's (both v4 and v6) interface scope rules. Several bhyve and jail managers attempt to use this to add already configured network interfaces as member to bridges they manage with minimal changes to the host network configuration resulting in unreliable IPv4 and completely broken IPv6 processing. The new driver should restrict member interfaces to be only switch ports refusing to add member interfaces with configured IP addresses and prevent adding IP addresses to members.

In its current state the if_bridge(4) driver does not support VLAN filtering between member interfaces. Neither adding the (untagged) network interfaces nor creating one bridge per VLAN nor and using vlan(4) interfaces as members provides the correct semantics needed. Using IPFW express VLAN filtering between member interfaces or a member interface and a bridge interface is both slow and error prone. The new bridge driver should perform per member port VLAN and MAC address filtering.

Unlike if_bridge(4) the new driver should not be an IP capable network interface. Instead virtual member ports should be created to connect the host to the bridge, acting similar to one half on an if_epair(4).

Such a bridge would also provide the groundwork to improve bhyve(8)'s para-virtualised networking with an if_tap(4) like member port supporting multiple bidirectional packet transfers with a single system call.

Example Device Driver in Rust

[last updated: 2025-01-21]

Example tasks:

• Convert example C kernel module in examples to Rust
• Read timer hardware for current time of day etc.

Implement native OpenBFS for FreeBSD

[last updated: 2024-07-03]

The Be File System was developed by Dominic Giampaolo and Cyril Meurillon to provide BeOS with a modern 64-bit-capable journalling file system. The project would be to bring BFS support for FreeBSD, perhaps considering some reuse of the open implementation made by Haiku-OS.

Unified kernel tracing interface

[last updated: 2024-03-15]

Description

The FreeBSD kernel contains several subsystems which add hooks to core pieces of the kernel. For example, the context switch code in the scheduler contains this snippet:

        if (td != newtd) {
#ifdef  HWPMC_HOOKS
                if (PMC_PROC_IS_USING_PMCS(td->td_proc))
                        PMC_SWITCH_CONTEXT(td, PMC_FN_CSW_OUT);
#endif
                SDT_PROBE2(sched, , , off__cpu, newtd, newtd->td_proc);

#ifdef KDTRACE_HOOKS
                /*
                 * If DTrace has set the active vtime enum to anything
                 * other than INACTIVE (0), then it should have set the
                 * function to call.
                 */
                if (dtrace_vtime_active)
                        (*dtrace_vtime_switch_func)(newtd);
#endif
                td->td_oncpu = NOCPU;
                cpu_switch(td, newtd, mtx);
                cpuid = td->td_oncpu = PCPU_GET(cpuid);

                SDT_PROBE0(sched, , , on__cpu);
#ifdef  HWPMC_HOOKS
                if (PMC_PROC_IS_USING_PMCS(td->td_proc))
                        PMC_SWITCH_CONTEXT(td, PMC_FN_CSW_IN);
#endif

There are three hooks that may be called before switching into the new thread, and two hooks that may be called after the switch. They are used by DTrace and HWPMC to collect information about context switch events. These hooks are disabled most of the time, but each hook introduces overhead even when disabled since we must check whether it is enabled each time the code is executed.

The goal of the project is to identify useful kernel tracepoints, and design and implement a unified interface that can be used by different consumers to collect information about the event corresponding to a particular tracepoint. This would make it easier for new subsystems to collect information from existing tracepoints, rather than modifying the core kernel to add more hooks. An additional aim would be to ensure that such tracepoints have minimal overhead, probably by using hot-patching to enable and disable a particular tracepoint. FreeBSD-CURRENT now uses clang 10.0, which implements the "asm goto" construct that could be useful here.

Add IPv6 scoped-address support in in-kernel ONC RPC and NFS

[last updated: 2024-01-31]

FreeBSD’s NFS and other implementations relying on ONC RPC do not work with non-global IPv6-scoped addresses (e.g., link-local) because the RPC universal address format specified in RFC 5665 is used and it does not include the scope ID. This project aims to eliminate this limitation. The required steps are as follows:

• Implement a function handling text representation of an IPv6 address with the scope ID and replace inet_ntop() with it.
• Add support for IPv6-scoped address format to conversions between a taddr and a uaddr in the kernel.

Implement MPLS support for FreeBSD

[last updated: 2023-01-27]

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

The OpenBSD's MPLS stack or the NetBSD's MPLS stack overviews of other *BSD implementations can provide more datapoints.

Improve netgraph concurrency

[last updated: 2023-01-27]

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 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 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

Userland projects

mdo(1) improvements

[last updated: 2025-01-28]

Please see also the related project mac_do(4) improvements. To interested students: Please consider combining both in a single medium-duration project (175 hours). This related project's proposal provides an overview of what mac_do(4) is, and is recommended reading anyway.

mdo(1) is the companion userland program to mac_do(4). It currently can run another program as a different user, either keeping the calling process' groups or replacing them with the new user's ones.

Since the recent revamp of mac_do(4), an administrator can authorize fine-grained transitions of both user and group IDs. However, mdo(1) has not yet been updated to provide the required functionality. In particular, mdo(1) should be able to:

• Specify any list of target groups (primary or supplementary), possibly based on user names (an implicit list would be constructed from the related content of both /etc/passwd and /etc/group) but also allowing some tweaks (such as excluding a particular group in the final credentials).

• Allow changes of groups only in an easier way than the current interface (requires specifying the current user if it isn't root).

• Grow a mode producing the target part of mac_do(4) rules corresponding to the requested transition.

• If time permits, ponder on an architecture and implementation for requesting a password before calling setcred(2) in certain cases.

Port virtual_oss to base

[last updated: 2025-01-27]

virtual_oss is an audio server written by Hans Petter Selasky for FreeBSD's sound system, OSS (Open Sound System), which provides support for (de-)multiplexing audio devices, switching audio devices on the fly, as well as bluetooth sound, among other features. FreeBSD currently lacks a built-in audio server, since virtual_oss is only provided as a port.

The goal of the project is to successfully port virtual_oss to the base system and integrate it in programs and scripts that might benefit from using it.

Even though this project is largely about integration, virtual_oss uses third-party libraries, namely libsamplerate and fftw3, which will most likely need to be replaced by rolling our own code in order to make virtual_oss completely standalone.

sockstat UI improvements

[last updated: 2025-01-24]

Sockstat is a utility that prints details about any connected socket on the system. It's useful, but the current user interface is lacking. It could greatly benefit from libxo output, and it's also a good candidate for a C++ conversion. The entire -w option is an avoidable hack, if output were printed more intelligently. Most ambitiously of all, this program is fairly begging for some kind of "xo_print_table" function, that would automatically size the columns.

Network Configuration Libraries

[last updated: 2024-01-29]

Deliverables: A simple tool to configure the network on a laptop to allow a bhyve VM to access the internet.

Use Cases:

• A bhyve VM running on a laptop NAT'd out the laptop's wifi connection
• A bhyve VM bridged to the hosts Ethernet network

Stretch goal: Extend the tool to support configuring network access for standard and VIMAGE jails

Build a libipfw to enable programmatic configuration of the firewall, implement basic functionality to add rules and configure NAT instances.

Optional: relocate most functionality available in the command line interface into the library and replace the replace the command line interface with a thin wrapper around the new library.

Build a libbsdnat that can be used by bhyve VM managers and Jail management tools to configure NAT on the host to allow the guest access to the internet via the host's network. This library will then be extended to handle creating 'port forwarding' rules to expose services in the guest to the public network via the host. Network mappings will be ephemeral and will need to be recreated by the management tools when the VM or jail is restarted.

Possible design for final tool:

• libifconfig - used to create and manage bridge interface for bhyve, epairs for jails
• libbsdnat - Configure NAT for outbound, and port forward rules for inbound.
• libipfw - Used to insert rules routing traffic via above NAT instances.

• netlink - Used for network stack configuration

IPv6 support and cleanup of address family dependency in userland utilities

[last updated: 2024-02-11]

Many of our tools are not IPv6 "clean", such as these tools:

• rwhod(8)
• Various yp(8) daemons
• rpc.rquotad(8)

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. Other possible work could involve

• remove/rework the about 200 gethostby*() calls all in the base system and contrib to use getaddrinfo().
• make more code to conditionally compile in INET or INET6 support.

Speed up the FreeBSD boot process

[last updated: 2024-01-12]

Using the TSLOG framework and one or more systems running FreeBSD, profile the boot process and identify targets for improving boot performance. This is likely to involve delving into multiple different parts of FreeBSD, ranging from the kernel to daemons launched from rc.d scripts; there are likely a large number of places where improvements can be made, and work will be guided by the amount of time which could potentially be saved and the likely complexity of making improvements. In many cases, a student will need to collaborate with other FreeBSD developers familiar with different parts of the system.

syzkaller improvements

[last updated: 2020-03-04]

syzkaller is a suite of tools that performs coverage-guided system call fuzzing. Originally targeting Linux, it can now fuzz many different operating system kernels and has been extremely effective at finding bugs, many with security implications. It creates, monitors and fuzzes a set of virtual machines running the target kernel. More information can be found in its documentation, and in these slides. Google kindly runs a public syzkaller instance targeting FreeBSD.

For a while it has been possible to run syzkaller on FreeBSD; that is, fuzz FreeBSD on FreeBSD. syzkaller makes use of ZFS and bhyve (or QEMU) to do so. This makes development and testing of FreeBSD-specific syzkaller features much easier.

Though syzkaller has found quite a few bugs in FreeBSD, it does not cover as much as it does on Linux, so it is virtually guaranteed that there are plenty of bugs waiting to be found. This project consists of several subtasks that would improve FreeBSD's coverage:

• Extend syzkaller's FreeBSD system call descriptions. For each system call, syzkaller requires a set of annotations that describe the system call's arguments. It is missing many of FreeBSD's system calls. syzkaller similarly needs to be taught about device-specific ioctls.
• Support fuzzing of FreeBSD's Linux system call compatibility layer. Since syzkaller can of course fuzz Linux natively, it should be straightforward to run a Linux fuzzer on FreeBSD.
• Support external injection of USB traffic.
• Support running the fuzzer in a jail, optionally with various resource limits in place.
• Test syzkaller with a ZFS root filesystem instead of UFS. Work with the syzkaller developers to get a FreeBSD+ZFS target running in syzbot.

• Port support for automated patch testing and crash bisection to FreeBSD. Some details are listed here.

• Work with the project mentor to triage and possibly fix any kernel bugs found in the process.

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.

Capsicumization of the base system

[last updated: 2020-03-02]

Capsicum is a sandboxing technology used in FreeBSD. It is complemented by Casper, a framework for defining application-specific capabilities. A large number of utilities in the FreeBSD base system have been converted to run under Capsicum and Casper, but many programs have yet to be converted. The project would consist of identifying several high-profile daemons and utilities in the base system or ports, and modifying them to run in capability mode. One good candidate is syslogd, the system logging daemon.

As part of this work it may be necessary or useful to add additional Casper services to the base system. For example, we do not yet have a Casper service which allows an application to make outbound network connections.

Note: Converting applications to run under Capsicum/Casper can take a lot of effort, especially when they are large or when they are not designed with privilege separation in mind. Some applications, like a shell, can't really be run in capability mode at all. Before attempting to sandbox a given application, take care to study the ways in which it interacts with the system. For example, does the application need to open any files? If so, are the file names statically defined or are they derived from user input? This will provide insight into the difficulties that will arise when sandboxing the application.

Add QCOW2 compressed image support to mkimg(1)

[last updated: 2025-02-04]

mkimg(1) is a FreeBSD tool used for creating disk images in various formats, such as raw images, QCOW/QCOW2, VHD/VHDX, and VMDK. However, it currently lacks support for creating compressed QCOW2 (QEMU Copy-On-Write v2) images. QCOW2 is widely used in virtualization due to features like snapshot support, compression, and efficient disk space utilization through sparse file support.

Integrating QCOW2 compression into mkimg(1) would extend its utility, allowing FreeBSD users to generate smaller QCOW2 images directly without relying on external tools. This enhancement will benefit those deploying FreeBSD in virtualized environments.

There are (currently) two QCOW2 versions: v2 and v3. v2 supports only deflate (zlib) compression; v3 adds support for zstd. mkimg currently implements v2 support, without compression. The minimum scope for this project is implementing zlib compression, but the project may be made larger by support for QCOW2 v3 and zstd compression.

This project will also include improvements to the mkimg test suite, in order to properly test the new functionality.

References: QCOW2 spec https://github.com/qemu/qemu/blob/master/docs/interop/qcow2.txt

Tools

Improve LLDB on FreeBSD

[last updated: 2024-03-12]

The LLVM debugger, lldb, is part of the FreeBSD base system. This project aims to extend lldb on FreeBSD in two ways.

1. Improve lldb Lua bindings

lldb supports scripting in C++, Python, and Lua. The Lua bindings are a more recent addition, and some features that would make them much more usable on FreeBSD are missing. The first goal of this project is to improve Lua binding support, add documentation, and bring the Lua bindings to parity with the Python bindings.

Example tasks:

• Enable Lua bindings to create new LLDB commands
• Generate Lua documentation similar to the Python documentation
• Write a tutorial for scripting LLDB with Lua

• Add convenience methods to support common FreeBSD kernel debugging tasks from Lua, such as those described in https://freebsdfoundation.org/wp-content/uploads/2019/01/Debugging-the-FreeBSD-Kernel.pdf

2. Integration lldb into crashinfo

FreeBSD provides a script, /usr/sbin/crashinfo, which runs after a system (kernel) crash and extracts information from the core dump to store in a text file. See the crashinfo man page for more information. crashinfo currently makes use of the GNU debugger, gdb, which must be installed from the package collection or ports tree. The second goal of this project will be to add lldb support to crashinfo, providing the same information that crashinfo's gdb integration provides. (gdb support should be retained in the script and used when gdb is available).

GEOM management UI

[last updated: 2025-01-30]

On Linux, many users use the graphical gparted utility for disk and partition management. Such a utility is currently missing on FreeBSD; users have to make use of somewhat unintuitive command line utilities to set up disks. It would be great if that hole could be filled.

The goal of this project is to have a partition management utility similar to gparted, but for FreeBSD. It could also mean porting gparted to FreeBSD. If this project is taken as a long (350 hours) project, it might be interesting to extend the utility to more GEOM classes, such as gstripe(8), geli(8), glabel(8), and gmirror(8). The management tool will be developed in a separate repository. It can be written in any programming language supported on FreeBSD, though ideally one that works on all architectures we support. The interaction with GELI can be done through libgeom(3) or by wrapping the various GEOM command line utilities. The project could be done either as a curses-based TUI or a GUI for X11/Wayland.

Once a viable prototype (mid-term deliverable) is complete, the project is added to the FreeBSD ports collection. If a TUI and free of third-party dependencies, it could later be added to the base system.

WiFi Management UI

[last updated: 2025-01-31]

Many new users install FreeBSD on their laptops but miss utilities common on other systems like Linux, our current tools are a bit obtuse. This project aims to bring some of those niceties to FreeBSD. This project proposes a tool that can act as nice single entry point to list available networks and connect and save configurations.

The tool could be implemented as a REPL like iwctl on linux or as a TUI although the latter is preferred. The project can be completed in any programming language supported on FreeBSD (C, Rust, etc.) although some knowledge of C is expected. Once a viable prototype (mid-term deliverable) is complete, the project can be added to the FreeBSD ports collection. If free of third-party dependencies, it could later be added to the base system.

PS. We are also very open to other project ideas revolving around things that makes life easier when using a laptop.

Power profiling tool

[last updated: 2025-02-04]

Currently, the only power statistics you can get on FreeBSD is the whole system's power consumption (reported by ACPI). If a certain process is using up a lot of power or something else is causing high power consumption, it can be difficult to debug this. This project aims to either port powertop from Linux to FreeBSD or write a wholly new tool.

If we go the route of porting powertop as-is, this could be made into a port, but ideally we'd have a tool in the base system for doing this. It might also be interesting for this tool to run a suspend test and report common issues similar to what the amd_s2idle.py script does for AMD Linux systems.

Raw Ideas

Warner Losh maintains a list of quick ideas that are little more than 'one liners' at Warner's Crazy Idea Page. This page requires more work than the ideas listed above. They would fit into small project category, especially for someone new to FreeBSD that wants to do a specific programming task to learn about the system. However, these ideas also require more planning on the part of the student than the ideas listed above, but could also be a better fit for some student's interest that aren't captured in the above ideas. The ideas are centered around lua, acpi, the boot loader, and FreeBSD's git/github integration.

To work on this:

• Join the FreeBSD discord server (invite) #kernel channel and tag me (@bsdimp).

• Explain what aspects of my crazy idea might be interesting
• We can flesh out the spec to the point it can be used to submit to GSoC.
• These ideas most likely would be in the 'small' category, though some might be too small (but don't let that stop you from reaching out)
• Not all the ideas are in the kernel: many are in the boot loader or are primarily working with lua. I just hang out on the #kernel channel since we don't have a GSoC one yet.
• Ideas don't strictly need to be on my list either: if you're inspired by the list to ask about something else, please don't hesitate to do so.

---

CategoryGsoc