Differences

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

--- soc:2008:stefanha:journal:week8 [2008/07/17 05:49]
stefanha
+++ soc:2008:stefanha:journal:week8 [2009/03/07 09:20] (current)
stefanha
@@ Line 1: / Line 1: @@
 ====== Stefan Hajnoczi: GDB Remote Debugging ======
-===== Week 6 =====
+===== Week 8 =====
 **Milestones:**
@@ Line 48: / Line 48: @@
 I think the most general way to solve this dilemma is by allowing multiple
 embedded images and making gPXE //always// boot from an embedded image.  Even
-when you build without explicit ''EMBEDDED_IMAGE'' settings, a **default gPXE
+when you build without explicit ''EMBEDDED_IMAGE'' settings, a default gPXE
-script** is built in.  The default script simply boots from DHCP:
+script is built in.
+Anyway, I have created a ''multiembed'' branch with these features implemented.
+I think most of this solution has already been thought about by hpa, mcb30, and
+mdc.  I just wanted to code something last night; hope this is a step in the
+right direction.
+//Update: removed detailed description since the reworked patch changes things
+slightly//.  See [[.:week8#sat_19_2008|newer entry]].
+==== Fri 18 2008 ====
+**Back to the b44 driver**, I have removed uhmalloc and am using malloc's allocator instead.  Once this reworking is complete, I can move up to the DMA mapping API to support DMA pools.  Then I will send these patches for review and merge before sending the actual b44 driver.
+**Sent cleaned up gpxelinux merge patch** for mainline review.
+==== Sat 19 2008 ====
+Git commits:
+  * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=26b0197cb63725a58f596bf279d4e37e6862b5c2|[image] Make dependencies for EMBEDDED_IMAGE]]
+  * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=16dc7dddc05ef292dcda3f4c67632ef911eb984c|[image] Clean up embedded image support]]
+**Reworked multiembed patch**.  The following text documents the user-visible changes:
+=== Embedded images ===
+gPXE normally fetches images over the network using TFTP, HTTP, iSCSI, or other network protocols.  It is also possible to //embed// an image file inside gPXE and make it available without fetching over the network.
+By embedding gPXE scripts, you can customize gPXE's behavior before its first network access.  For example, static network configuration can be done by embedding a gPXE script.
+Images are embedded when building gPXE with ''make'':
 <code>
-#!gpxe
+$ make EMBEDDED_IMAGE=../contrib/scripts/static.gpxe
-autoboot
 </code>
-**Static network configuration** works just like you'd expect: you build with
+This builds a gPXE image which executes the ''static.gpxe'' script on startup.  The ''static.gpxe'' sample script works with QEMU's user network stack:
-''EMBEDDED_IMAGE=mystatic.gpxe''.  This replaces the default script with our
-custom script.  Here is a sample script that works with QEMU's user network
-stack:
 <code>
 #!gpxe
@@ Line 70: / Line 93: @@
 </code>
-**Embedding PXELINUX** is also pretty easy, this time by using the multiple
+Multiple images can be embedded:
-embedded image feature.  We embed ''pxelinux.0'' //and// a little script to do
+<code>
-DHCP.  Once DHCP is complete, the little script boots ''pxelinux.0'':
+$ make EMBEDDED_IMAGE=../contrib/scripts/gpxelinux.gpxe,/usr/lib/syslinux/pxelinux.0
+</code>
+This builds a gPXE image which executes the ''gpxelinux.gpxe'' script on startup.  The ''gpxelinux.gpxe'' script performs DHCP before loading the embedded ''pxelinux.0'' image and executing it:
 <code>
 #!gpxe
 dhcp net0
+imgload img1
 boot
 </code>
-Multiple embedded images theoretically allow embedding a ''vmlinuz'' and
+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:
-''initrd'' inside gPXE.  This isn't practical for space-constrained image types
+<code>
-like floppy disk or ROM images.
+$ make EMBEDDED_IMAGE=first.gpxe,second.gpxe,third.gpxe
+                      ^ img0     ^ img1      ^ img2
+</code>
-Anyway, I have created a ''multiembed'' branch with these features implemented.
+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''.
-I think most of this solution has already been thought about by hpa, mcb30, and
-mdc.  I just wanted to code something last night; hope this is a step in the
+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.
-right direction.
+**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>
+#!gpxe
+autoboot
+</code>
 **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 are 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.
-  * The patch still needs polishing (error handling and ''mpopulate()'' to reclaim embedded image memory).
-Next steps:
+===== Next week =====
-  * [shutdown] Fine-grained shutdown including removing gPXE allocated memory and freeing up PXE+UNDI, if necessary.
+On to [[.:week9|Week 9]].
-  * [uhmalloc] Kill this patch, use ''malloc'' allocator instead for DMA buffers.
-  * [DMA] DMA pool API so drivers can reserve DMA buffers on ''open()''.
-  * [b44] Cleanup, testing, performance.
-  * [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.

Trace:

Differences

Navigation

Search

Toolbox

QR Code