Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
soc:2008:mdeck:project_plan:start [2008/05/19 17:26]
mdc created
soc:2008:mdeck:project_plan:start [2008/08/18 18:43] (current)
mdeck
Line 8: Line 8:
  
 ==== Outline ==== ==== 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 ==== ==== 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** ✔ Debug until proper operation achieved
 +    - **Week 3** ✔ Revamp formatting, naming, etc to improve future code rework
 +    - **Week 4** ✔ Expand tx operation to utilize multiple TxFDs
 +    - **Week 5** ✔ Debug
 +    - **Week 8** ✔ 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** ✔✔½ (2.5) Drivers complete!!
  
 +//Note: Timeline subject to change.//

QR Code
QR Code soc:2008:mdeck:project_plan:start (generated for current page)