This is a place to collect ideas for people looking for a way to help illumos (and its derivatives) and serve as a starting point for Google Summer of Code. We also welcome projects for work on the shared OpenZFS codebase, including projects not specific to illumos. The OpenZFS community has a list of additional project ideas here: 

Please remember, projects you suggest need to list possible mentors, who should be people with time and willingness to help new contributors. Whether you wish to base your proposal on one of the below suggestions or offer an original one, you must identify a mentor via community channels (the developer mailing list and #illumos IRC channel) and spend time with that person discussing the project before applying. A good place to make initial contact and seek out a mentor is on the illumos "developer" mailing list.  Start by introducing yourself, and briefly describe the area in which you'd like to get involved.

Some projects do not have specific mentors listed, but if any of these interest you, please contact our developer community via the developer mailing list and we'll do our best to find you a mentor.

Breadcrumbs: only a handful of these projects include references to relevant source code, but resourceful students will be able to learn important fundamentals about navigating source by looking at these. Please spend some time learning how to identify relevant source, recent changes and associated issues, and open issues. Doing that kind of background work reflects well on applicants, even at the stage of discussing project ideas.

We do not attempt to assess difficulty for projects, as this is highly dependent on skills and previous experience. Students are therefore expected to consider how well they match the listed prerequisites and to discuss their level of subject matter expertise with potential mentors in preparing applications. Be aware that the risk of regressions involved in integrating a project will affect the requirements for testing and time needed for review prior to integration. It is best to discuss this aspect of your project schedule with potential mentors or other developers.

Available mentors for illumos

The following people have expressed willingness to mentor projects.  Some have areas of specialization noted after their names.

Other members of our developer community may also be willing to mentor, depending on the topic of the proposed project.  Just ask on the "developer" mailing list.

User-mode illumos-gate

Win. message DLL compiler@gwrC, some WindowsThe CIFS server needs one little "message DLL", which is not a DLL in the normal sense, as it contains no machine code, only messages. We'd like a tool that can build this file from a text input. Working notes: ( )
Scalable libc malloc implementation


or rmustacc

CMove libumem into libc, determine what kinds of enhancements to libumem might be necessary around areas such as start up time, etc. Must include benchmark results and integration. Talk to trisk who has ported nmalloc ( )
libc POSIX 2008 enhancementsgdamoreC, standards-readingUpdate some interfaces in libc to support POSIX 2008, especially adding support for thread-safe interfaces for locale handling.
localedef/libc locale featuresgdamoreClocaledef and libc need some enhancements to support required features in certain locales, such as support for "plu "pluggable" character type names (this is required for China). This is related to a recent change:
ND RDNSS support C, IPv6, standards-reading

Add ND RDNSS support to Illumos IPv6 stack, RFC 5006/6106 (see

Improve SysloggdamoreC, TLS, NetBSD usefulEnhance our syslogd to support more modern details. See RFC 5424, 5425 for example. This was done for NetBSD back in 2008, so having the same work done for illumos would be very useful. We would like this to be a full "in-tree" replacement for our native syslogd, rather than just importing rsyslog or syslog-ng, which are less desirable both as non-integrated systems, and have licensing challenges that may make them unacceptable for some illumos downstreams.

Instrumentation & Debugging

illumos performance tools C, performanceport some popular Linux performance tools to illumos, eg htop, dstat, free, netstat (who has this socket open)
userland post-mortem DTrace, C, debuggers, systems programmingWhen you have a target process, ring buffer added to the core dump so you can run DTrace on it. Related to lastwords.d
IDT DTrace provider DTrace, C, systems programmingA DTrace provider that operates by interposing on the interrupt descriptor table (IDT), not dissimilar to the mechanism used by the SPARC-based trapstat.
Node.js memory profiling Node.js, MDB, performance analysisNew MDB dcmds for understanding memory usage in Node.js apps based on a core dump.
MDB support for new kernel lock manager + NFS@gwrC, MDB, filesystem internals, kernel development

Replace closed-source MDB dcmds for NFS+KLM with a re-write for the the new open-source lock manager.
This project is partially completed. See mdb: Open source implementation of nfs module 

Embedding mdb modules in binaries

rmustaccC, MDB, ELF/executable formats, user-level core dump mechanicsOne of the current challenges that we have is that it is hard to ensure that you have the right version of a dmod for a language runtime for example, see node.js. This project will involve developing a way to glom a dmod into a binary. Make sure that it is included inside of a dump, and that mdb can find it when it runs on said core after the fact.
upanic(2) syscallJosef "Jeff" SipekC, syscall interfaceSometimes we want a process to die (dump core) without any hope for the rest of the process messing things up (e.g., by handling SIGABRT).  Creating a new syscall to simply dump core with a debug message (much like the kernel-level equivalent panic()) will allow a number of userspace programs and libraries to get simplified. (E.g., libumem does a abort() loop to make sure it truly kills the process.)
x86 xregs support C, proc fs, debugging supportOn x86, /proc/$PID/lwp/1/xregs exists but is empty.  As a result, debuggers do not have access to newer sets of SSE regs provided by x86.  Given the amount of change that x86 undergoes, the interface used here must be compatible with future additions to the floating point register file.

Platform support

Via Nano/Eden Support C, system architecture, x86Adapt our x86 support to support the latest Via processors, useful for very low power systems. For a bonus, 
provide enhanced support for Via features like PadLock (Via's security technology).
ARM supportJosef 'Jeff' SipekC, system architecture, ARMHelp with porting illumos to the ARM processor family. There is some progress on this project. ARM port
Remove pre-Pentium codeJosef "Jeff" SipekC, system architecture, x86The 32-bit x86 kernel support depends on the cmpxchg8b instruction.  This instruction first appeared in the Pentium processor.  Therefore, we can safely nuke any code for supporting pre-Pentium CPUs.

Device Drivers

Limited per-zone drivers supportgdamoreC, OS internals, device driversThere are some classes of kernel mode components like certain drivers that interact with the rest of the kernel only through well defined interfaces and do not modify global kernel state on their own. It is possible for this class of drivers to service only a subset of processes (e.g. from a zone). Kernel would be read-only to this drivers so they won't affect global stability and they would be mapped only in the processes from a zone, so a panic() would only crash a zone. This would allow us to have support for branded zones (even 3rd party) that don't have system-wide effects and would also simplify writing drivers.
Audio subsystems enhancementsgdamore, TriskeliosC, basic OS internals and/or device driversLots of ideas here... moving audio streams from one device to another, more flexible mixing options, etc. Boomer 2 deliverables that were never worked on. (Ask gdamore.)
Open Source version(s) of certain drivers (cadp)gdamoreC, device driversNew device drivers (possibly ported from a licence-compatible implementation), tested and integrated into illumos.
Device driver porting guidegdamoreC, kernel API(both illumos & foreign), technical writingWrite a porting guide to assist developers porting one or more types of device driver from Linux, BSD, or Windows to illumos.
Broadcom WiFi drivergdamoreC, device driversThere is a reverse engineered bcm wifi driver on Linux, and perhaps BSD. This would open illumos up to a wider range of laptops without relying on the NDIS shim.
DRI with KMS support for Intel graphicsgdamore
C, device driversA new kernel Direct Rendering Manager driver with support for mode-setting (KMS) on Intel graphics. Newer X drivers require KMS. It already exists on Linux, and some work is in progress for BSDs. Ongoing work for illumos can be found on github
Port OpenBSD's backported Intel graphics support to the older DRI C, device driversOpenBSD has a backport of functionality from newer Intel X server drivers on top on a pre-KMS DRM. This can be leveraged to support newer chipsets without porting a completely new DRM with KMS.
Bluetooth support C, device drivers, reading standardsAdd Bluetooth stack and support for mouse profile, possibly based on prototype port from NetBSD. See for more info.
Hardware Watchdog Drivers 

C, device drivers, reading standards, porting

Add support for hardware watchdog drivers, for advanced motherboards to be able to employ hardware reboot of hung systems. Possibly, port (or learn from) the Linux watchdog collection, and tie this in with bmc-watchdog and related FreeIPMI utilities in illumos.
Hardware Sensor Drivers 

C, device drivers, reading standards, porting

Add support for monitoring of system temperatures, fan speeds and other data provided by hardware sensors on most of the motherboards sold in the past decade or more. LM-Sensors project for Linux is a good start, and a worthy upstream (to allow future resyncs in order to get new drivers).
Extend "radeon" video driver support to APU processors C, device drivers, reading standardsillumos includes some support for AMD/ATI Radeon video cards as part of its driver subsystem as well as an X11 rendering driver. Some time ago new devices of this brand were released, AMD APUs, which combine a CPU and several graphics cores in one chip. These are now popular in notebooks, but are not recognized by the drivers which exist in illumos today (so the video works as generic VESA). Goal of this quest is to add at least basic support for this video hardware, including the ability to suspend it (so the notebook can go to sleep and resume – today attempts to suspend hang such system). Bonus points for 3D acceleration and other pretty video features.
Update net80211 stack C, device drivers, 802.11 standards, BSD net80211 stackUpdate the WiFi stack to make it easier to port drivers from BSDs. Align the basic stack with BSDs so that work is limited to lower-level interfaces. This requires a degree
sd & ssd cleanupJosef "Jeff" SipekC, device driverssd.c is one of the messiest pieces of code we have.  It gets compiled into two drivers for historical reasons (sd and ssd).  There is really no reason to have this split.  Either move the ssd bits into sd (if the devices it supports are still useful) or just nuke ssd support and clean up sd.c accordingly.


We will also be accepting projects for work on OpenZFS, check out

FUSE@gwrC, filesystem internals

Integrate either of (or both?) FUSE implementations. There's one from the old OpenSolaris project: that uses a traditional message passing model
and supports "low level" back-ends. (Those operate at the VFS level.)

There's a second by @gwr that gains some efficiency using door calls to reach the
user space program providing "back-end" functions, though this implementation only supports
"high level" FUSE back-ends. (Those operate at the open/read/write/close level.) See: 

If someone managed to combine the best features of both, that would be great!

NTFS and/or exFAT support C, filesystem internalsReliable kernel-mode drivers for NTFS (v3.1) and/or exFAT filesystems, under a compatible licence.
pcfse^ipi, Josef "Jeff" SipekC, filesystem internalsReplacement pcfs module for reading FAT32/vfat filesystems. Port from OSX or xBSD (or any other license compatible OS). Start with the existing implementation at:
GVFS module for smbfs C, Gnome app. dev.Implement a new GVFS module using smbfs. Can study the current SMB/Samba module for ideas.
Port ext4 C, filesystemsWrite a kernel implementation (without copying GPL code!) that can be used to mount Linux ext4 filesystems in illumos, possibly based on the existing ext3 driver.
ZFS ARC scalability C, filesystems (ZFS), perf. analysisThe ZFS ARC code needs some analysis and improvements, in particular the code has scalability issues when used with a great number of small files, or small block sizes. This will require more creative problem solving skills.
ZFS ARC working set size C, filesystems (ZFS), performance analysisProvide tools for analyzing memory consumed by ZFS ARC.
ZFS L2ARC persistence C, filesystems (ZFS), performance analysisAllow the ZFS L2ARC to persist across reboot.
ZFS ARC multi-tenancy C, filesystems (ZFS), performance analysis, zones, virtualizationImprove ARC performance and analysis tools for contention in virtualized environments such as cloud hosting.
ZFS encryption C, filesystems (ZFS), cryptographyImport and update the work started by Darren Moffat to provide cryptographic support for ZFS.
Paravirtualized file system for virtualized guests C, OS internals, basic filesystem internalsImplement (maybe port ZPL from ZFS) a thin filesystem that uses the hypercall interface to interact directly with the Transactional Object Layer and ARC of the host ZFS filesystem. Do the host-side work so that writing the guest-level filesystem on other OSes like Linux and Windows is simple. Also implement a guest-side /dev/zfs that talks to host-side /dev/zfs and hides the non-local state so that management of this file system happens exactly like ZFS.
UFS modernizationJosef "Jeff" SipekC, filesystems internalsOur UFS code suffers from several issues that should be addressed.  To name a few: (1) it is not endian agnostic (x86 can't read sparc disks, and vice versa), (2) certain functionality is bolted on awkwardly due to historical reasons (e.g., logging), (3) there are a number of tendrils into the rest of the kernel that shouldn't exist (e.g., the bio_*_strategy hooks in the bio code).

SMB Client

Use delete-on-close@gwrC, SMB protocolThe VFS remove entry point in smbfs (smbfs_remove) returns EBUSY when there are vnode references etc.
That really should rename the file and set the SMB "delete on close" flag for it, which will ensure that the
file will be deleted even if we lose our connection to the server.
Integrate mmap suport@gwrC, VFSThis work is mostly complete, here:
what remains is testing and integration.
SMB2 support for smbfs@gwrC, SMB protocolThe smbfs (SMB client) in illumos currently supports only SMB1. We'd like it to also support the SMB2 protocol.
Server-side SMB2+ is available for reference (see: )
@gwr can offer design advice based on the server-side changes from SMB1 to SMB2.

SMB Server

Update from illumos-nexenta@gwrC, VFS, SMB protocolTest and integrate the various "chunks" of work from: 
Dtrace provider@buffygC, DtraceThe SMB1 dtrace provider is incomplete, having only the probe sites implemented.
There's a bunch of missing code in libdtrace etc. Partial work here:  
Replace RPC support@gwr

Migrate DCE/RPC stack, replace existing IDL infrastructure, integrate with kernel credential plumbing.
Would like to use the code from  to replace the "ndrgen" based code in illumos.

Power Shell support@gwrC, WBEMWant server-side support for the interfaces used by Power Shell. In Windows, this is implemented in the
WinRM Service
using CIM and WBEM. For background, see:
There are open-source WBEM implementations, i.e.: (looks quite mature) also see:
SMB authentication via LDAP@gwrC, LDAPSome people would like to use a plain LDAP server (i.e. OpenLDAP) instead of an Active Directory server to authenticate users.
(Samba supports this.)  We should extend the name service switch to have a new back-end "method" similar to the current
"shadow password" method (maybe call it "smb password"?) letting the "files" back-end user the current /var/smb/smbpasswd
and the LDAP back-end get the NT password hash via LDAP similar to how shadow does. 
smbadm enhancements@gwrC. kernelAdd sub-commands to "smbadm" to do similar operations as one can do from a Windows client in the
Microsoft Management Console (MMC) such as: list connected users, trees, open files,
"kick off" users, force tree disconnects, file closes, (etc.) 


plugins for zone user management C, name services, security, systems programming, virtualizationPAM and NSS modules for managing users and groups in a zone via a plugin mechanism running in the global zone
ILB load balancer outside global zone C, networking, systems programming, virtualizationILB is a TCP load balancer that is only accessible in the global zone. This would allow a zone to set up its own ILB rules.
zone-aware sharefs@gwrC, systems programmingillumos now supports per-zone SMB servers. However, that work does not address issues with sharefs or sharemgr, and how those interact with ZFS etc. Those components need design work so that ZFS data sets delegated to a zone have their share information placed in the per-zone sharefs instance for that zone.
NFS server in a zone@gwrC, systems programming

We'd like the NFS server to be able to (at least) share out a ZFS data set that's delegated to some zone in only that zone.
There are some parked works-in-progress for this feature: 

Other kernel-related

Suspend-to-disk C, kernel, system architectureWe have suspend-to-ram, and we have suspend-to-disk for SPARC. It would be good to get suspend-to-disk (hibernate) for x86 systems. Much of the plumbing underneath is already there, but it will take some significant effort -- this will also require work to interface with the boot loader, and possibly with ACPI. See the existing code at: – This would be a massive investment in time and very difficult debugging with very little payoff. You almost certainly don't want to do this unless you would personally benefit from it working, and even then it's 50/50
Alternate boot loaders/UEFI boot C, UEFI, BIOS, kernel bootstrapProvide alternatives to grub2 for boot process, including support of machines bootstrapping off UEFI with root on GPT disks. (Currently a work-in-progress by Toomas Soome).

Dev environment

Build system improvements Build systemsImprove build system scalability, allow building from any directory in any state, make it easier to detect dependency problems, decrease incremental build overhead.
Automated test support C, POSIX, scriptingImplement test modules for testing various subsystems of the OS in illumos, revive STF test suites beyond ZFS that are of general interest to the illumos community
Fix writable strings C, compiler optionsBuild illumos with compiler options to put strings constants in read-only memory and fix the compile errors and any run-time breakage (problem is mostly the last bit)


Integrate Connectathon NFS tests@gwrC, scripting

Integrate the "Connectathon NFS tests", which are not specific NFS but rather are a useful file-system interface test.
These particular tests don't have a widely known home (there are a few copies around) but can be found here:  

Client/Server test automation C, scripting

We need some test automation that can test a server by orchestrating both client and server systems.

Either extend the framework under $SRC/test or select, evaluate, and integrate some test automation framework.

Use this client/server framework to run the well-known server tests like: (not an exhaustive list)
filebench, vdbench, iozone, smbtorture, "connectathon NFS tests" (above) ... 
(There's a good summary of such tests here: )

Porting and distro support

SmartOS appliancese^ipiSoftware packaging, automationpre-baked SmartOS-based appliance distros for things like storage (NAS box), networking (router box), others. Be creative. Bonus points for making a REST api and/or gui to manage them
Language, library, or application porting Porting, expertise in project to portTake expertise you already have with a project that has considerable barriers to illumos portability and work with both the illumos community and an upstream with which you are preferably already familiar to complete a port and make upstream commits for ongoing support. Organisations that don't otherwise participate in GSoC but are willing to partner via ad hoc umbrella arrangements are welcome.

Additional lists of ideas

The OpenIndiana distribution has another ToDo list here: 
The OpenZFS project has an "ideas" page here: