Google Summer of Code Ideas/2008

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.

Scripting interface

We would like to have a scripting language to automate boot selections based on the hardware, and on the user's choices. This task would involve both the design of the scripting language and its implementation. This may mean integrating an existing lightweight scripting language, such as Lua, or designing and implementing one from scratch. In the latter case, familiarity with lex and yacc will probably help.

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

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.oftc.net) for a better idea on how to shape the project.