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: http://www.open-zfs.org/wiki/Projects
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.
|Win. message DLL compiler||@gwr||C, some Windows||The 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: ( https://www.illumos.org/projects/cifs/wiki/Msgdll )|
|Scalable libc malloc implementation|
|C||Move 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 ( https://hg.openindiana.org/projects/illumos/nmalloc/ )|
|libc POSIX 2008 enhancements||gdamore||C, standards-reading||Update some interfaces in libc to support POSIX 2008, especially adding support for thread-safe interfaces for locale handling.|
|localedef/libc locale features||gdamore||C||localedef 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:https://www.illumos.org/projects/illumos-gate/repository/revisions/13591|
|ND RDNSS support||C, IPv6, standards-reading|
Add ND RDNSS support to Illumos IPv6 stack, RFC 5006/6106 (see https://www.illumos.org/issues/2338)
|Improve Syslog||gdamore||C, TLS, NetBSD useful||Enhance 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, performance||port some popular Linux performance tools to illumos, eg htop, dstat, free, netstat (who has this socket open)|
|userland post-mortem||DTrace, C, debuggers, systems programming||When 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 programming||A 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 analysis||New MDB dcmds for understanding memory usage in Node.js apps based on a core dump.|
|MDB support for new kernel lock manager + NFS||@gwr||C, 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.
Embedding mdb modules in binaries
|rmustacc||C, MDB, ELF/executable formats, user-level core dump mechanics||One 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) syscall||C, syscall interface||Sometimes 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 support||On 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.|
|Via Nano/Eden Support||C, system architecture, x86||Adapt 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 support||C, system architecture, ARM||Help with porting illumos to the ARM processor family. There is some progress on this project. ARM port|
|Remove pre-Pentium code||C, system architecture, x86||The 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.|
|Limited per-zone drivers support||gdamore||C, OS internals, device drivers||There 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 enhancements||gdamore, Triskelios||C, basic OS internals and/or device drivers||Lots 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)||gdamore||C, device drivers||New device drivers (possibly ported from a licence-compatible implementation), tested and integrated into illumos.|
|Device driver porting guide||gdamore||C, kernel API(both illumos & foreign), technical writing||Write a porting guide to assist developers porting one or more types of device driver from Linux, BSD, or Windows to illumos.|
|Broadcom WiFi driver||gdamore||C, device drivers||There 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 graphics||gdamore|
|C, device drivers||A 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 https://github.com/raichoo/illumos-gate/tree/kms|
|Port OpenBSD's backported Intel graphics support to the older DRI||C, device drivers||OpenBSD 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 standards||Add Bluetooth stack and support for mouse profile, possibly based on prototype port from NetBSD. See https://www.illumos.org/issues/2267 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 standards||illumos 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.|
|sd & ssd cleanup||C, device drivers||sd.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 http://www.open-zfs.org/wiki/Projects
|FUSE||@gwr||C, filesystem internals|
Integrate either of (or both?) FUSE implementations. There's one from the old OpenSolaris project:
There's a second by @gwr that gains some efficiency using door calls to reach the
If someone managed to combine the best features of both, that would be great!
|NTFS and/or exFAT support||C, filesystem internals||Reliable kernel-mode drivers for NTFS (v3.1) and/or exFAT filesystems, under a compatible licence.|
|pcfs||e^ipi||C, filesystem internals||Replacement pcfs module for reading FAT32/vfat filesystems. Port from OSX or xBSD (or any other license compatible OS). Start with the existing implementation at:https://www.illumos.org/projects/illumos-gate/repository/show/usr/src/uts/common/fs/pcfs|
|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, filesystems||Write 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. analysis||The 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 analysis||Provide tools for analyzing memory consumed by ZFS ARC.|
|ZFS L2ARC persistence||C, filesystems (ZFS), performance analysis||Allow the ZFS L2ARC to persist across reboot.|
|ZFS ARC multi-tenancy||C, filesystems (ZFS), performance analysis, zones, virtualization||Improve ARC performance and analysis tools for contention in virtualized environments such as cloud hosting.|
|ZFS encryption||C, filesystems (ZFS), cryptography||Import 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 internals||Implement (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 modernization||C, filesystems internals||Our 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).|
|Use delete-on-close||@gwr||C, SMB protocol||The 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||@gwr||C, VFS||This work is mostly complete, here: https://github.com/gwr/jilin-smbfs-mmap|
what remains is testing and integration.
|SMB2 support for smbfs||@gwr||C, SMB protocol||The 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: https://github.com/gwr/illumos-gate/tree/smbsrv-rework2 )
@gwr can offer design advice based on the server-side changes from SMB1 to SMB2.
|Update from illumos-nexenta||@gwr||C, VFS, SMB protocol||Test and integrate the various "chunks" of work from:|
|Dtrace provider||@buffyg||C, Dtrace||The 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|
|C, DCE/RPC IDL|
Migrate DCE/RPC stack, replace existing IDL infrastructure, integrate with kernel credential plumbing.
|Power Shell support||@gwr||C, WBEM||Want 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: http://dmtf.org/about/faq/wbem_faq
There are open-source WBEM implementations, i.e.: http://openwbem.sourceforge.net/ (looks quite mature) also see:
|SMB authentication via LDAP||@gwr||C, LDAP||Some 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||@gwr||C. kernel||Add 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, virtualization||PAM 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, virtualization||ILB 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||@gwr||C, systems programming||illumos 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||@gwr||C, 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.
|Suspend-to-disk||C, kernel, system architecture||We 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: https://www.illumos.org/projects/illumos-gate/repository/show/usr/src/uts/common/cpr – 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 bootstrap||Provide 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).|
|Build system improvements||Build systems||Improve 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, scripting||Implement 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 options||Build 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||@gwr||C, scripting|
Integrate the "Connectathon NFS tests", which are not specific NFS but rather are a useful file-system interface test.
|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)
Porting and distro support
|SmartOS appliances||e^ipi||Software packaging, automation||pre-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 port||Take 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.|