Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
soc:2008:stefanha:journal:week8 [2008/07/19 10:49] stefanha |
soc:2008:stefanha:journal:week8 [2009/03/07 09:20] (current) stefanha |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Stefan Hajnoczi: GDB Remote Debugging ====== | ====== Stefan Hajnoczi: GDB Remote Debugging ====== | ||
| - | ===== Week 6 ===== | + | ===== Week 8 ===== |
| **Milestones:** | **Milestones:** | ||
| Line 106: | Line 106: | ||
| </code> | </code> | ||
| - | Why was ''img1'' used an not ''pxelinux.0''? Embedded images are automatically named ''img#'' starting from ''img0''. They do not retain their original filename. For example: | + | Why did we write ''imgload img1'' and not ''imgload pxelinux.0''? Embedded images are automatically named ''img#'' starting from ''img0''. They do not retain their original filenames. For example: |
| <code> | <code> | ||
| $ make EMBEDDED_IMAGE=first.gpxe,second.gpxe,third.gpxe | $ make EMBEDDED_IMAGE=first.gpxe,second.gpxe,third.gpxe | ||
| Line 114: | Line 114: | ||
| Also, notice that we had to use ''imgload'' before doing ''boot''. This is because embedded images are not automatically loaded for booting. They are simply available as if they had been fetched using ''imgfetch''. | Also, notice that we had to use ''imgload'' before doing ''boot''. This is because embedded images are not automatically loaded for booting. They are simply available as if they had been fetched using ''imgfetch''. | ||
| - | The full behavior is described as follows. When gPXE starts, it does the equivalent of ''imgfetch'' for every embedded image and assigns them names starting with ''img0'' for the first image. Then it loads and boots the first image (''img0''). If booting ''img0'' fails, it removes all embedded images and gives up. | + | The full behavior is described as follows. When gPXE starts, it does the equivalent of ''imgfetch'' for every embedded image and assigns them names starting with ''img0'' for the first image. Then it loads and boots the first image (''img0''). If booting ''img0'' fails, it <del>removes all embedded images and</del> gives up. |
| - | It's interesting to note that gPXE //always// embeds an image, even if you do not give it one. By specifying an embedded image, you are overriding the default embedded image. The default embedded image is a script that tries DHCP booting from each network interface in turn: | + | **This paragraph does not apply to the multiembed code in gPXE mainline**. It's interesting to note that gPXE //always// embeds an image, even if you do not give it one. By specifying an embedded image, you are overriding the default embedded image. The default embedded image is a script that tries DHCP booting from each network interface in turn: |
| <code> | <code> | ||
| #!gpxe | #!gpxe | ||
| Line 123: | Line 123: | ||
| **Limitations of my patch**: | **Limitations of my patch**: | ||
| - | * The semantics of replacing ''autoboot()'' with embedded images are not 100% correct. The autoboot process will bring up each network interface in turn using DHCP and attempt to run the embedded image or fetch a file from the network. Now, embedded images run only once and without any network interface being up or configured. | + | * The semantics of replacing ''autoboot()'' with embedded images are not 100% compatible with past gPXE behavior. The autoboot process will bring up each network interface in turn using DHCP and attempt to run the embedded image or fetch a file from the network. Now, embedded images run only once and without any network interface being up or configured. |
| - | Next steps: | + | ===== Next week ===== |
| - | * [uhmalloc] Kill this patch, use ''malloc'' allocator instead for DMA buffers. | + | On to [[.:week9|Week 9]]. |
| - | * [DMA] DMA pool API so drivers can reserve DMA buffers on ''open()''. | + | |
| - | * [b44] Cleanup, testing, performance. | + | |
| - | * [shutdown] Remove gPXE allocated memory and free up PXE+UNDI, if necessary. | + | |
| - | * [bzImage] Expand the heap size to the full 64K segment when loading a bzImage kernel with version 2.02 or higher. | + | |
| - | * [GDB] Real-mode remote debugging. | + | |
