✎ soc:2008:mdeck:project_plan:start

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Michael Decker: Driver Development ======

===== Overview =====

My goals for the summer are:
  - To update a legacy Etherboot driver to the gPXE API
  - To port a Linux driver to gPXE

==== Outline ====
First, I will update a legacy etherboot driver to the gPXE API.  I anticipate this process will develop my knowledge of network driver architecture. This will also provide familiarity with legacy and gPXE APIs.  Next, I will perform a full port of a Linux driver.  This will give me exposure to the linux driver API, and will show how it compares with the gPXE API.

By the end of the summer, I expect to have a firm grasp of general network driver architecture, and the ability to translate legacy and linux drivers to gPXE architecture.  Depending on my pace, more drivers will be translated.  The driver first selected will depend on what NICs I have available to me, and what is needed by gPXE.


As for methodology, I plan to begin by reviewing general network driver architecture.  What functions specifically does a typical driver perform, and what kind of interface do the NICs provide to do this.  I expect this to be similar for most cards, though if it varies, I will focus on the architecture of the card I will be working on.

Next, I will determine the sequence of functions I will be developing.  That is, starting with initialization, basic functions, then more advanced functions.  From here, I will look at both the legacy etherboot API and the new gPXE API, and determine how these initial functions are implemented.  I will then begin conversion of these necessary functions, and then test the code, however possible.  This process will continue until full conversion is complete.

As for testing, unless there is a PC emulation environment that can accurately emulate the NIC, it will need to be tested on actual hardware.  If any debugging facilities are available, for instance via serial or usb link, then they will be utilized to ensure proper operation, and debug any problems that may occur.  Otherwise, some special output routines may be implemented to provide debugging information to the screen, when possible.

It appears http://www.etherboot.org/wiki/dev/devmanual provides excellent documentation concerning the implementation of drivers, and as such should serve as an invaluable resource during this process.  A similar procedure is expected to be followed when porting a Linux driver to gPXE.

==== Milestones and Timeline ====


  * **I.** Etherboot -> gPXE conversion
    - **Week 1** ✔ Review general network architecture
    - **Week 1** ✔ Enumerate functions of Etherboot __and__ gPXE APIs
    - **Week 1** ✔ Document [[:soc:2008:mdeck:notes:gpxe_driver_api|gPXE Network Driver API]]
    - **Week 2** ☛ Conversion of eepro100.c
    - **Week 3** ☛ Testing & modification begins
    - **Week 5** ☛ Driver complete
  * **II.** Linux -> gPXE conversion
    - **Week 6** ☛ Review Linux network architecture
    - **Week 6** ☛ Enumerate Linux API functions and how they map to gPXE API
    - **Week 6** ☛ Conversion & testing
    - **Week 12** ☛ Driver complete

//Note: Timeline subject to change.//
Trace: • week5 • realtek8139roms • week3 • week9
Navigation

Search

Toolbox

QR Code
