Google Summer of Code Ideas/2009
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.
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.
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.