✎ soc:2008:stefanha:journal:week8

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Stefan Hajnoczi: GDB Remote Debugging ======

===== Week 6 =====

**Milestones:**
  * [b44] Tested and clean for mainline review.
  * [gpxelinux.0] Merge Award BIOS return-to-PXE workaround.

==== Mon Jul 14 ====
Git commit: [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=86d1342ffbb0dcfc6bb02da81af766f7a0e8f306|[init] Shutdown flags for fine-grained exit behavior]]

Time is passing quickly.  Today I worked on fine-grained ''shutdown()''.  There are two scenarios under which ''shutdown()'' is called:
  - Booting an image that does not use gPXE interfaces (like BIOS int 13h or PXE).  Here everything should be cleaned up and shut down.
  - Exiting gPXE to return control to firmware (usually to boot the next device if gPXE failed).  Here we may wish to leave some resources, like the underlying PXE stack, running.

There is currently no way to distinguish these two cases for ''shutdown()''.  Therefore, we are not able to clean up or leave resources as appropriate.

I have added a flag to ''shutdown()'' to indicate either ''SHUTDOWN_BOOT'' or ''SHUTDOWN_EXIT''.  As part of ''undionly.kpxe'', we need to unload the PXE base code if ''shutdown(SHUTDOWN_BOOT)'' is performed.  I still need to figure out how to do the unloading and freeing of base memory... ;-)

==== Tue Jul 15 ====
Git commit:
  * [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=b370b8791c1b99a143a8b915170fac0b184f35b3|[prefix] kkpxe prefix for keep UNDI, return-to-PXE images]]

Sent the ''e820mangler.S'' patch for full clipping into fragments for review today.

**Created ''.kkpxe'' image type** for PXE images that keep PXE+UNDI loaded and return to PXE (instead of int 18h).  [[http://etherboot.org/share/stefanha/gpxelinux.kkpxe|Here]] is a ''gpxelinux.0'' image built from ''undionly.kkpxe''.

==== Wed Jul 16 ====
**Sent gpxelinux merge patches for review**.  I spent some time this week working on fine-grained ''shutdown()'' so that gPXE can free resources appropriately.  However, I believe that this work is independent of the gpxelinux merge and our priority is to get gpxelinux merged.  Therefore, I have submitted the gpxelinux patches now, without fine-grained ''shutdown()''.

==== Thur Jul 17 ====
Git commit: [[http://git.etherboot.org/?p=people/stefanha/gpxe.git;a=commit;h=0d15b1612bb1258c2cdccc7a106f94a5bb02bd88|[image] Multiple embedded images and no hardcoded DHCP]]

Users who want a static IP address instead of DHCP find they need to edit
the source to remove hardcoded DHCP.  They can then use the ''EMBEDDED_IMAGE''
build option to include a gPXE script that configures their static network
settings inside the gPXE binary.

Since editing the source is inflexible, there is a discussion to change gPXE's
behavior to something more general than hardcoded DHCP.  The new policy would
skip DHCP for embedded images since they likely want to set up network settings
themselves.

While this solves the problem for embedded gPXE scripts which do their own
network configuration, it breaks when ''pxelinux.0'' is embedded inside gPXE.
PXELINUX expects the network interface to be (auto-)configured.

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
script** is built in.  The default script simply boots from DHCP:
<code>
#!gpxe
autoboot
</code>

**Static network configuration** works just like you'd expect: you build with
''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
ifopen net0
set net0/ip 10.0.2.15
set net0/netmask 255.255.255.0
set net0/gateway 10.0.2.2
set net0/dns 10.0.2.3
kernel http://etherboot.org/gtest/gtest.gpxe
boot
</code>

**Embedding PXELINUX** is also pretty easy, this time by using the multiple
embedded image feature.  We embed ''pxelinux.0'' //and// a little script to do
DHCP.  Once DHCP is complete, the little script boots ''pxelinux.0'':
<code>
#!gpxe
dhcp net0
boot
</code>

Multiple embedded images theoretically allow embedding a ''vmlinuz'' and
''initrd'' inside gPXE.  This isn't practical for space-constrained image types
like floppy disk or ROM images.

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.

**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 patch still needs polishing (error handling and ''mpopulate()'' to reclaim embedded image memory).

Next steps:
  * [shutdown] Fine-grained shutdown including removing gPXE allocated memory and freeing up PXE+UNDI, if necessary.
  * [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: • week11 • week1 • project_plan • indolent_playground • week1 • rpcbind_-_build_instructions • journal • week0 • project_plan • pxeknifedsl • week11 • week5 • project_plan