This is an old revision of the document!
===== Week 4 [ Mon 14 Jun 2010 - Sun 20 Jun 2010 ] ===== ==== Day 1 [ Mon 14 Jun 2010 ] ==== Git commit: [[http://git.etherboot.org/?p=people/andreif/gpxe.git;a=commit;h=50c10591aaba4a808abd935df81df03cd0562e84|50c10591aaba4a808abd935df81df03cd0562e84]] I've started working on the forcedeth driver's .probe routine. After several lines of code I remembered stefanha's advice that I should start to familiarise myself with gPXE's core source code. And so I did. Since I was working on .probe I wanted to see where it was called from. The first hit I got was ''probe_devices()'' from ''core/device.c''. This goes through all root devices (which are system buses) and calls their .probe routine. In turn, this routine (''pcibus_probe()'' in PCI) scans the bus and registers all devices by calling their .probe routine. One such device is the NIC I am writing the driver for :). So this is the code path from ''probe_devices()'' to my driver. Naturally, the next question is, who calls ''probe_devices()''? Well, this routine is pointed to by the .startup field of a ''struct startup_fn'' structure. gPXE keeps a table of such structures, one for each "entity" that has to be started/shutdown at some point. These "entities" include the serial port, device drivers and UNDI. These .startup routines are called by the ''startup'' function from ''core/init.c''. Finally, ''startup'' is called from ''core/main.c'''s ''main()'' which is gPXE's entry point. I will do this with every exposed routine from the forcedeth driver, so I can get a better understanding on how gPXE works. This might make my driver writing slow some times but on the long run I will gain the ability to contribute with more diverse patches (not just drivers). I did spend several hours just browsing the code without realising how much time has passed and I didn't get to do as much work as I wanted to on the forcedeth driver. OTOH, the code browsing I did was a lot fun, and I don't feel like I have wasted any time.
