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" 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. Unfortunately, the patch is in assembly, and of very poor code quality, and therefore has not been merged. 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.

A specification exists for the Gfxboot byte code.

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.

Dynamic linker/loader for modules - DONE

Right now, SYSLINUX modules are in a flat, binary format called COM32. This only permits one module to exist in memory at any time. We would prefer to be able to have more than one module in memory at any time; the preferred method for this would be using the existing ELF format and dynamic linking, although there are other technical alternatives for this.

This project would require a firm understanding of binary formats, relocatable code, and a working familiarity with x86 assembly language.

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.