7/28/2014

PXE, iPXE macro problems

So porting of the code over to the iPXE code base was going really fast until I found the src/includes/ipxe/tables.h "Macro" library for defining __tables was redefined, and no longer accepted three parameters.

I'm still trying to grasp the significance of this while studying up on all the different ways a Macro can be used.

Macros

A macro is a fragment of code which has been given a name.
Whenever the name is used, it is replaced by the contents of the macro.
There are two kinds of macros. They differ mostly in what they look
like when they are used. Object-like macros resemble data objects
when used, function-like macros resemble function calls.

Study the code in gpxe/src/drivers/net. The rtl8139 and r8169 drivers are good examples. Note that some drivers are not written for the gPXE API but use a wrapper for the legacy Etherboot API instead. New drivers should use the gPXE API.

Linux Device Drivers is a good reference for understanding Linux drivers and learning general driver development concepts.

As far as I can tell the old Etherboot criteria for a minimum of four or five functions stands, at least as legacy.c wrappered -- it looks like as time went on they kept adding requirements

The src/core/main.c file calls some init.c/h functions and starts up performs housekeeping and runs a "probe" function for each "linked in" driver to see if it detects its hardware. If it does it returns a structure with the mac address and other info and leaves the device in "ready to transmit" mode.

This is probably the opportunity to setup and start the USB bus, like the PCI bus, ect.. the latest iPXE seems to have a USB bus for storage devices.. I wonder if it will conflict, or be preferred since it must share the bus with storage and ethernet devices.

If they should share then it would make sense to adopt that USB communications provided for the EDD or storage bus and adapt the NIC-ish functions to that method. Otherwise two USB drivers for the same bus would not be good. This tells me ipxe/src/drivers/net/rtl8139 and r8169 drivers might be good prototypes to study.. unless some legacy wrapping is going on to the new ipxe standard api.. whatever that might be.

The main loop then performs its other tasks and calls dhcp function which uses some tcp and network functions to "use" the netdevice to perform the communications.

I'm not entirely convinced the tables.h definition needs to be used by the driver code, it appears to be utility code to simplify things. Might be just as well to create second macro definition and use that, or embed what its trying to provide directly in the driver code.

Its really tough luck the two functions that won't compile are the "probe" functions for the detected hardware. They fillout or "sketch out" how to use the netdevice for the main routine.

Lots of confusion on my part, but in a vacuum it probably more efficient than doing nothing.