✎ soc:ideas - Etherboot/gPXE Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Etherboot Project GSoC Ideas ======

This list is not exhaustive, and we welcome new suggestions.  Some of these ideas are not in themselves complete projects; feel free to ask us how much work is likely to be involved, and how many ideas you might sensibly attempt as a Summer of Code project.  The approximate difficulty level of each idea has been marked with one or more :-/ symbols; the more :-/, the more difficult the project is expected to be.

{{ :nic.jpeg?237×222|A network card}}

==== Device drivers ====

gPXE is always in need of more device drivers.  In the case of network card drivers, existing drivers and Linux kernel drivers are available as starting points.  Data sheets are also generally available for most NIC variations, though such documentation is sometimes unreliable.  You could:

  * :-/ :-/ Update some of the old Etherboot drivers to work with the new gPXE driver API.  All drivers are written in C, and you will need to have hardware (network cards, server and client computers) to test driver changes.  (We may be able to provide some of the required cards for development and testing.)

  * :-/ Add support for newer network card variants to an existing gPXE driver.

  * :-/ :-/ :-/ Add a device driver for a new, currently-unsupported network card to gPXE.

If you are feeling more adventurous, and have access to appropriate hardware, you could:

  * :-/ :-/ :-/ :-/ Add a driver for a wireless network card.  There is some out-of-date support for one type of 802.11b wireless card; you could expand this into a general framework for wireless networking, and add drivers for one or more modern wireless NICs.

  * :-/ :-/ :-/ Add a non-Ethernet driver, e.g. a driver for an Infiniband card.  (gPXE does have a working Infiniband subsystem.)

  * :-/ :-/ Fix up the support for legacy bus types such as ISAPnP.  These devices are allegedly supported, though most have not been tested for many years, and it is unlikely that the current code is in a working state.

  * :-/ :-/ :-/ :-/ Add support for a new bus type, e.g. PCMCIA or USB.

==== Protocols ====

gPXE already supports several common (and less common) protocols, including TFTP, FTP, HTTP, HTTPS, DNS, iSCSI and AoE.  There are several more (mostly fairly esoteric) protocols that people may find useful.  You could add support for:

  * :-/ :-/ Fibre Channel over Ethernet (FCoE)

  * :-/ :-/ Novell's Remote Program Load (RPL)

  * :-/ :-/ iSCSI extensions for RDMA (iSER)

{{:nullmodem.jpeg?200×200 |A null-modem cable}}

==== Automated regression testing ====

:-/ :-/ :-/ :-/ :-/ gPXE has a relatively large feature set given the code size.  Many features are rarely used, and there has been a tendency for parts of the code to suffer from bit-rot.  The measures we have taken so far will ensure that we never end up with unbuildable code; we now avoid the use of #ifdef wherever possible, and have automated tests in place to identify missing or redundant symbols.  However, we do not have any systematic method for functional testing. 

We would ideally like to be able to run a series of tests to verify different functional units (e.g. http download, Linux kernel booting, PXE booting, serial console support, etc.).  Most of these tests can be carried out inside a virtual machine such as bochs or qemu.  Some tests (e.g. specific device driver tests) will need to be carried out on real hardware.  The tests should be fully automated, and should produce a clear pass/fail status indicator.  It should be possible for a developer to simply run “make test” and, some time later, receive an overall pass/fail status, together with a list of any failed tests.

You would design and create an infrastructure for automated testing of gPXE.  Your test harness would have to set up the environment required for the particular test (e.g. building the gPXE image to be tested, configuring the DHCP server), initiate the test (which may involve starting up an emulator such as qemu, or powering-on a test machine), identify and record the test result, then move on to the next test.  Test results should be collated and reported to the developer.

Having such an automated test suite would enable us to offer quality control guarantees; we could then be confident that upgrades would not break existing functionality.

==== IPv6 Support ====

:-/:-/:-/ One of the many strong dependencies on IPv4 is the PXE specification. By having Ipv6 support available in gPXE would make the dependency on IPv4 PXE a non-issue in some environments and only a minor dual-stack inconvenience in larger data center deployments.  

gPXE already has the IPv6 framework in place but doesn't have support for state-less/full IPv6 DHCP. The most basic requirement would be stateless DHCP and stateful DHCP for the DNS servers.  As with all IPv6 support, it would be preferred over IPv4 communications, attempted first, and perform AAAA lookups over A lookups in DNS.

==== ProxyDHCP server for Linux ====

:-/ :-/ ProxyDHCP provides a mechanism for supplying DHCP options to clients independently of IP addresses.  It is a PXE extension to DHCP, and is already supported by gPXE.  It is potentially useful in situations such as adding a network booting infrastructure to a network that already has a DHCP server that cannot be reconfigured.  (This is a fairly typical problem in corporate networks.)

There is currently no open source ProxyDHCP server software.  It would be desirable to extend ISC dhcpd to provide this functionality.  ISC dhcpd already has a rich configuration file syntax including the ability to perform conditional behavior depending on the contents of packets it receives.  It currently lacks the ability to offer DHCP options without simultaneously offering an IP address.

You would extend ISC dhcpd to be able to support operation as a ProxyDHCP server.  This would include designing appropriate extensions to the dhcpd.conf syntax, implementing and testing the changes, and working with the dhcpd maintainers to get your changes integrated upstream.

Having this ability would make it easier for users to deploy gPXE in large corporate networks with restrictive policies on changes to the DHCP infrastructure.

==== Enhanced scripting language ====

:-/ :-/ :-/ gPXE has a [[:commandline|command language]] that allows users to boot interactively but is also used for scripts.  Scripts allow users to customize gPXE behavior for site-specific network and boot configurations.

There is currently no support for looping, conditional branches, or the arithmetic and string manipulation operators that allow powerful scripts to be written.  Enhancing gPXE scripting with these language constructs will make it possible for users to implement advanced boot policies without modifying gPXE's source code.

You would design a scripting language with input from the gPXE community to make advanced boot use cases possible.  You would then implement, test, and document the language so it can be included in mainline gPXE.

Having a powerful scripting language would make it possible to customize network boot behavior without being an expert in low-level C programming and gPXE internals.

==== R.O.M. - Rom-O-Matic ====

:-/ Rom-O-Matic is the web / graphical fronted to creating Etherboot & gPXE roms, there are several things that need to be worked on within the code base to make it better & more user friendly

 * Updating and merging of the new configuration file reading code originally done by John 'Warthog9' Hawley
 * Updating configuration files to include, inline, syntax information hints for things like R.O.M.
 * Trivial ROM creation based on relative place in gPXE source tree
 * User Interface clean-ups

Knowledge of gPXE building & configuration, ability to read and understand C and programing in php are required.

==== 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 [[http://syslinux.zytor.com/wiki/index.php/Google_Summer_of_Code_Ideas|Syslinux'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 [[http://pxeknife.erebor.org|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.


===== What you will need =====

{{ :disk.jpeg?240×186|A disk}}

For almost all gPXE development work, you will need to have:

  * A development machine, running Linux, that you have root access to.  You will edit and compile gPXE on this machine, and you may also need to set up software such as a DHCP server etc.  (We will talk you through getting your machine set up for development; the important thing is that you must have a machine available.)

  * A testing machine, which you can reboot very frequently.  You will test gPXE on this machine.  This machine cannot be the same as your development machine; it must be a separate computer.

  * A working network between the two machines.

  * Access to IRC (Internet Relay Chat), so that you can talk to us.

Depending on the project idea that you choose, you may also need:

  * One or more specific network cards, if you are writing a driver for that card.  We may be able to provide these.

  * Support for specific bus types (e.g. PCI express, PCMCIA) on the testing machine, if your project idea involves working with these buses.

It is useful, though not always essential, to have:

  * Serial ports on both the development and testing machines, and a null-modem cable to connect them.

  * A digital camera (for taking screenshots; we have found situations in which this is the only sensible way to report diagnostic information!)

===== How to apply =====

First, take a look at the above list of project ideas and see if anything takes your fancy.  If you have an idea of your own that isn't listed above, that's great.  Take some time to think about your idea; how might you approach the problem, how long do you think it would take, how interesting do you find it, how useful will it be to other people, etc.?

Second, introduce yourselves to us.  Preferably via the IRC channel, though e-mail is perfectly acceptable.  We will want to spend some time talking to you about your proposal.  We will base our decision mostly on the interactions we have with you, rather than on the project proposal you submit via the GSoC web interface.

Thirdly, once you've talked to us on IRC or via e-mail, submit a project proposal via the official Summer of Code web interface.  Your proposal should clearly state the project idea you'd like to work on, and should give some background information on your experience, and a rough overview of how you would approach the problem.  We will interview all applicants (via IRC), and our decision on who to accept will be based primarily on the interview (and on any other contact we've had with you via IRC).

===== Hints and tips =====

  * Do get in touch with us.  Unlike the larger projects, we **will** take the time to talk to you personally.  If we haven't spoken to you, we're very unlikely to accept you as a student.

  * Do ask for help when you need it.  You're not in class, and you won't be penalised for not knowing the answer immediately.

===== Potentially useful links =====

==== Google Summer of Code ====

  * Main page: [[http://code.google.com/soc/]]
  * Student FAQ: [[http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs]]
  * Student Application: [[http://socghop.appspot.com/]] 

==== Etherboot Project Links ====

  * Project Home Page: [[http://www.etherboot.org/]]
  * Source Code: [[http://www.etherboot.org/wiki/download]]

==== Etherboot Mailing List Links ====

  * Etherboot-Discuss Mailing List Archives: [[http://sourceforge.net/mailarchive/forum.php?forum=etherboot-discuss]]
  * Etherboot-Discuss Mailing List Subscription Page: [[https://lists.sourceforge.net/lists/listinfo/etherboot-discuss]]

==== Etherboot IRC Channel ====

  * ''#etherboot'' on the FreeNode network (irc.freenode.net)



We hope you have enjoyed reading about the [[http://www.etherboot.org/|Etherboot Project]], and we look forward to meeting you and discussing your project ideas.
Trace: • ubuntu_aoe • commandline • debian_lenny_iscsi • iscsibootprepfc5 • qemupxe • implementation • winnt_aoe • 2009 • centos_iscsi_install • unity-patch • 2006 • yazzy • winnt_iscsi • ubuntu_iscsi • 2008 • abft • 2010 • qemu • appnotes • stefanha