Google Summer of Code Ideas/2009

We are inviting students to help us out by joining the Google Summer of Code. This page lists some project suggestions, see also the Help wanted page.

All our projects will require a solid understanding of C programming and Unix/GNU style Makefiles. Most projects will require an understanding of PC hardware, and the most advanced projects will require x86 assembly language (NASM and gas syntax). Our development platform is Linux, and our revision control system is git.

A COM32 module (Comboot_API) is a module written in C using an API very similar to the standard C library.

Finish the Lua engine

We already have a Lua interpreter integrated with the Syslinux build. However, right now it is not very useful. We need to create a set of bindings to the Syslinux functionality, and have an array of documentation and examples so users can use them.

This is not a documentation project, but the documentation deliverable will be particularly important for this one, since the intended target is system administrators, not developers.

Rewriting Gfxboot as a COM32 module

A few distributions (e.g. SuSE and Ubuntu) uses a patched version of SYSLINUX that contains an interpreted graphics engine called gfxboot. This has recently been redone as a 16-bit assembly (COMBOOT) image. This project is to do a clean reimplementation in C, using existing graphics libraries already available as part of the COM32 libraries that are part of SYSLINUX.

Part of this project will be to create a specification for the Gfxboot byte code.

Knowledge of x86 assembly is probably essential, as well as good reverse-engineering skills.

An alternative might be to consider if the equivalent functionality can be implemented in a different way.

For reference, Open Suse Gfxboot page and Ubuntu CdBootloader page.

Rewriting the command-line interface as an internal COM32 module, module compression

At the moment, the basic SYSLINUX command-line interface and configuration file parser is written in assembly language. This is bad for maintainability. This project involves rewriting these in C, using existing libraries, as well as integrating it with the existing core code. Since it needs to be an internal module, some kind of data compression will probably be required (see below).

Knowledge of x86 assembly language would make the integration aspects of this project significantly easier.

Compressed modules

Support compressed COM32 modules. One way to solve that would be to add support for the COM32 format to UPX.

Knowledge of x86 assembly language would almost certainly be necessary.

Designing a tool for dynamic booting

The SYSLINUX API includes the ability to compose a Linux initial RAM filesystem (initramfs) on the fly. This is not widely used at the time, since the higher-level support is not there. This project involves design, implementation and documentation of a tool to perform such a dynamic boot.

This project requires a basic understanding of PC hardware, especially PCI. The design component of this project is probably more significant than the actual implementation, as the tool will have to offer considerable flexibility in order to be widely adopted. Ideally this should be integrated or combined with the scripting interface project mentioned above.

Revamp the build system

SYSLINUX currently is using a mishmash of several different build systems, having grown organically for 13 years. A new build system needs to handle, at a minimum:

• Multiple different compilers (host Linux gcc, MinGW gcc, target i386 gcc, NASM)
• Proper dependency generation
• Operation across subdirectories
• Precious files which should not be cleaned up when building for release
• Building new files from said precious files

This project requires understanding of the more complex pieces of GNU Make, and preferrably Perl. Ideally this should be done in such a way that it can be re-used for other projects. HPA has several ideas in this area; if you are interested in this project please contact the #syslinux channel (irc.freenode.net) for a better idea on how to shape the project.

boot.kernel.org - Universal remote network booting for the masses

Note: This is a cross posting on both Etherboot.org and Syslinux as the project is, literally, a cross disciplinary project. Please also see Etherboot's SOC idea's page as an applicant will be working closely with both projects.

The basic idea for boot.kernel.org is to provide a universal location for basic computer system tasks such as:

* Run Diagnostics
  * Memory Testers
  * Hard Drive Testers
  * CPU / Memory "burn-in" testers
* Get System information
  * Display PCI Layouts
  * Display Hardware attached to the system
* Install network installable OSes
  * Linux - a specific and primary goal, listings should be able to auto-update, etc
    * Fedora
    * CentOS
    * Debian
    * Ubuntu
    * OpenSuse (NOTE: assuming this can be done sanely)
    * Classic Distros
    * etc, specific emphasis on distro's available at mirrors.kernel.org
  * Other OSes could be added but not explicitly a requirement
    * BSD based distro's
    * OpenSolaris
    * etc

The work that would need to go into making this happen is going to be based on an existing project called PXE Knife which is already in the process of breaking up it's components into various states to allow for a subset to be included on Kernel.org

boot.kernel.org will need to provide a simple and easy mechanism to generate a custom CD, floppy or usb stick image that can be trivially loaded by an end user. This custom CD will be based on the Etherboot project's gPXE code and may include additions from the syslinux project as well.

This is a very interdisciplinary project, needing and involving an understanding of the entirety of Syslinux (configuration of both text and graphical interfaces including menu.c32 and vesamenu.c32, memdisk, etc), Web programing for customized menuing options (preference for php or perl), a solid understanding of gPXE and how network booting works, along with a good understanding of Linux network booting.

ext4 support in EXTLINUX

Make all necessary adjustments to support ext4 in EXTLINUX. This will require either familiarity with x86 assembly, modifying the existing code, or working with the Syslinux core developers to establish the infrastructure needed to be able to rewrite the EXTLINUX filesystem code in C.

Improving Menu system

The current menu system offer to Syslinux an API to generates ASCII-based menus. The current code features a single layout. This layout is a limit for several applications that needs to display complex output. This GSOC student will have to improve the current code to offer several layouts like:

* a layout to maximize the width of sub-menus, 
* a multi-layout design that display many layouts at a time

This project requires a good C-language skill and will requires to understand & manipulate ANSI escape sequences.