Google Summer of Code 2013

This page presents a list of ideas that could be developed for iPXE as part of Google Summer of Code 2013. Please feel free to contact the iPXE developers about any of these ideas, or to suggest your own project ideas.

There is always a need for more network card drivers, and many existing drivers would benefit from being rewritten. Some drivers still use the legacy Etherboot driver API. Some drivers have been ported from Linux drivers, which typically results in excessively large drivers containing huge amounts of redundant code.

Ideally, network card drivers should be written from scratch using the iPXE network driver API. This will usually result in a small, efficient driver that is capable of supporting new network card variants with minimal changes.

You will be writing low-level C code to interact directly with hardware. You should have a good understanding of how computers work internally: you should know about concepts such as memory addresses, PCI BARs, memory-mapped I/O, and DMA.

To develop a new network card driver, you will need:

• Several sample models of the network card in question. The iPXE project is happy to purchase and provide network cards for anyone working on driver development in GSoC 2013.

• A development machine (or virtual machine) running an operating system (such as Linux) capable of building iPXE.

• A test machine (which must be a physical machine) for testing your code. This must not be the same as your development machine, since you will need to reboot the test machine frequently. Your test machine should have an onboard serial port for debugging.

• A null-modem cable to connect your test machine to your development machine for debugging. The iPXE project is happy to purchase and provide a null-modem cable if required.

Download and build iPXE, and use it to boot a real physical machine. Take a look at the iPXE source code for some existing network drivers, such as realtek.c and intel.c. Take a look at a network card datasheet, such as http://download.intel.com/design/network/datashts/82547gi_ei_ds.pdf. Identify a network card that isn't currently supported by iPXE, or an existing driver that needs improvement.

Many users would prefer to be able to download prebuilt binary versions of iPXE, rather than building it from source. At present, only a few prebuilt binaries (e.g. http://boot.ipxe.org/ipxe.iso) are provided, and there is no way to customise these binaries to include additional build options or an embedded script.

There is an unfinished-but-mostly-working automatic build server script, build.fcgi, which is intended to provide on-demand binaries using URLs such as

  http://build.ipxe.org/undionly.kpxe
  http://build.ipxe.org/bin-x86_64-efi/ipxe.efi
  http://build.ipxe.org/undionly.kpxe?DEBUG=iscsi

The idea is that a web-based user interface should provide a way for the user to select any relevant build options, specify any embedded script, etc, and then construct and download the appropriate http://build.ipxe.org/ URL.

You will be designing the user interface, and implementing it using HTML, CSS and a suitable server-side language (such as Perl). The build.fcgi script is written in Perl, so you will need to be able to understand and debug Perl code even if you choose to write your own server-side code in a different language.

To develop the prebuilt binary web interface, you will need:

• A development machine (or virtual machine) running an operating system (such as Linux) that is capable of building iPXE and running the Apache web server.

Download and build iPXE. Read about and experiment with embedded scripts and debugging options. Take at look at the build options available in config/general.h (some of which are documented), and try building with some of these options enabled.

Take a quick look at the Rom-o-matic web site, a legacy site which provides a primitive user interface for building old versions of gPXE.

Think about what would make a good user interface. Consider how to expose all the various build options without overwhelming the user with complexity, and how to make it simple to do the most common types of build.

PXE clients such as iPXE require configuration options such as the boot filename. This information is typically provided by a DHCP server.

In some networks, it may not be possible for users to change the DHCP server configuration in order to supply the necessary options. For example, on a large corporate network, the DHCP server may be subject to strict change control measures. On a small home network, the DHCP server may be embedded within an ADSL router, and there may be no way to adjust its configuration. In these networks, the DHCP server may be used to obtain an IP address, but cannot be used to provide configuration options.

To work around this problem the PXE specification allows for an extension to the DHCP protocol, known as ProxyDHCP, which allows a ProxyDHCP server to provide configuration options without having to provide an IP address. The “real” DHCP server provides the IP address, and the ProxyDHCP server provides the configuration options.

The open source dnsmasq server is capable of acting as a ProxyDHCP server, and currently uses a static text file for configuration.

ProxyDHCP is a stateless protocol and all requests are idempotent. One fairly neat solution would be to extend dnsmasq to allow configuration to be sourced dynamically via HTTP: dnsmasq would convert the ProxyDHCPDISCOVER into an HTTP GET request, allowing the response to be effectively constructed by a script running on a web server. This allows the policy of deciding upon the client's DHCP options to be separated from the mechanism of responding to a DHCP request, giving great deal of flexibility while also allowing for desirable features such as redundancy and failover.

You would modify the dnsmasq source code to allow it to translate a ProxyDHCP request into an HTTP GET request. You would also implement a sample web server script to respond to these translated ProxyDHCP requests. You would work with the iPXE developers to ensure that the ProxyDHCP functionality that you develop is sufficient for iPXE's needs, and you would work with the dnsmasq developers to get your changes merged upstream into the dnsmasq source code.

To develop the ProxyDHCP server for Linux, you will need:

• A development machine (or virtual machine) running an operating system (such as Linux) capable of building dnsmasq and iPXE.

• A couple of testing machines (or virtual machines) for running iPXE and your modified dnsmasq.

Download and build the dnsmasq source code from http://www.thekelleys.org.uk/dnsmasq/. Make sure that you can boot iPXE using your home-built version of dnsmasq. Capture some DHCP packets and look inside to see how DHCP options work in practice. Take a look at the dnsmasq source code to see how it works.

Your first task should be to download and build iPXE, and test out booting inside a virtual machine. For example:

  cd src
  make bin/ipxe.iso
  qemu -boot d -cdrom bin/ipxe.iso

You should be able to see iPXE start running. It won't be able to boot anything until you configure your network and set up some servers, but you can at least try interacting with the iPXE command line.

Try making a small change to the iPXE code, such as editing core/main.c and changing the startup messages. Rebuild and check that your change is visible.

You will submit an application via the GSoC web application. Your application should include, at a minimum:

• Your name and as many contact routes as possible (e-mail address, phone number, IRC nickname, etc.)
• A brief outline of what you would like to implement, including some realistic goals for each week of the project. Try to think in terms of measurable milestones. For example, if you are implementing a new network driver, then some sensible milestones might be:
  • Week 1: ability to read MAC address from the NIC, verified by displaying the MAC address using the ifstat command
  • Week 2: ability to transmit a packet, verified by using the dhcp command, capturing the transmitted packet, and using Wireshark to observe the transmitted DHCP packet
  • …
  • Week 4: ability to correctly download a 512MB test file containing pseudo-random data in 4.6s (i.e. 1Gbps line rate), verified using the md5sum and time commands
  • …
• Some indication that you are familiar with the iPXE codebase. If you have already contributed code to the project, then please list some of your previous commits.

The application process will involve an interview in which you will be asked to solve some short programming exercises in C. These exercises have been used in previous years:

  /**
   * Copy memory region and calculate byte checksum
   *
   * @v dst		Destination address
   * @v src		Source address
   * @v len		Length of region
   * @ret sum		Byte checksum
   *
   * This function copies a region of memory of length "len" from "src"
   * to "dst", as per the standard C function "memcpy()".  It also
   * calculates the byte checksum of the region.
   *
   * For example, suppose that we have:
   *
   *   uint8_t src[4] = { 0x47, 0x53, 0x6f, 0x43 };
   *   uint8_t dst[4];
   *   uint8_t sum;
   *
   *   sum = memcpy_and_sum ( dst, src, 4 );
   *
   * then we should end up with dst[] containing the bytes { 0x47, 0x53,
   * 0x6f, 0x43 }, and sum having the value 0x47+0x53+0x6f+0x43=0x4c.
   */
  uint8_t memcpy_and_sum ( void *dst, const void *src, size_t len ) {
          // Your code goes here
  }

  /**
   * Reverse the order of an array of 32-bit integers
   *
   * @v array		Array of integers
   * @v count		Number of elements in the array
   *
   * This function simply reverses the order of the elements in an array
   * of 32-bit integers.  For example, suppose that we have:
   *
   *   uint32_t array[3] = { 0x12345678, 0xdeadbeef, 0xf00df00d };
   *
   *   reverse_array ( array, 3 );
   *
   * then array[] should contain { 0xf00df00d, 0xdeadbeef, 0x12345678 }.
   */
  void reverse_array ( uint32_t *array, unsigned int count ) {
          // Your code goes here
  }

You should expect to work full-time on your GSoC project during the summer. There's no need to work fixed hours each day, but you should allow around 40 hours per week in order to do justice to the project.

We like to maintain constant communication with our students. You should expect to hang out in the #ipxe IRC channel pretty much all the time, and communicate at least once each working day.

From past experience, we often find that students try to complete work without asking for help. From the background of academia, this is understandable; in your degree course it's important to be able to show that you can work unaided. However, GSoC is not academic in nature. We want you to ask for help. If you don't need to ask questions, then it probably means that your project isn't sufficiently challenging.

• ipxe-devel@lists.ipxe.org - the project mailing list

• #ipxe on Freenode - the project IRC channel

• Apply for GSoC 2013

• Frequently Asked Questions

• Timeline

• Google Summer of Code 2012