[NILO-discuss] Architecture

[Michael B. <mb...@fe...>]

Just a brief message to outline how I'm currently visualising the 
architecture, and where the real-mode code and the ELF loader fit into all 
this:

  The core code will be the code that is compiled into ROM.

  The core code will include all the functionality necessary to implement 
  the PXE spec, or as close as is logically feasible given the internal 
  inconsistencies in the spec.

  In particular, this means that the core code will include a network
  driver, code to handle DHCP exchanges (including ProxyDHCP, boot server
  discovery et al), code to handle TFTP transfers and (hopefully) code to 
  handle MTFTP transfers. [1]

  The core code will include a PXE API interface, at least on i386. [2]

  The core code will include an ELF loader capable of loading ELF 
  relocatable shared object (.so) files, and a runtime linker capable of 
  linking undefined symbols in the .so files.

  The core code will include a symbol table for a few well-defined
  functions in the core code.  By this means, .so files can use these core
  API functions, as well as functions in other .so files.

  The ABI for the .so files will be the default C ABI used by gcc (cdecl).

  All non-core code (i.e. code not required for the core functionality) 
  will be moved to a "modules" directory, tweaked to use the ELF API and 
  compiled as .so files.

  For i386, there will be a compilation option -DKEEP_IT_REAL.  If set,
  the resulting code will restrain itself to living in base memory and
  will not attempt mode transitions etc.  The ELF loader and API will not
  be compiled in when this option is set; only the PXE API will be
  available.

[1] MTFTP seems to have been designed to mimic TFTP as closely as 
possible; we may be able to use the same code for both.

[2] Yes, I'd like to keep multiple architectures, though I'm quite happy 
to break support for all of them at present and add them back in as 
needed.  The PXE API is defined only for i386 and the specification 
is very i386-specific.  Etherboot currently makes it easy for other 
architectures to implement a PXE API if they choose to do so, but there 
are certain choices that need to be made (such as deciding what to use for 
the SEGOFF16 datatype) that mean that the end result is, effectively, an 
Etherboot-specific API anyway.  Since there's no standard API on non-i386 
platforms, we may as well just say "hey, use the ELF API, since you can 
just write platform-independent C code and compile it into .so files".

Michael