Michael Brown wrote:
...It would definitely be useful to be able to modify the gPXE DHCP request...
I sometimes forget that something that seems obvious in my head is not communicated by magic to others. You've given a crystal-clear description of what I had in mind, down to the last detail. Thanks very much for the detailed expansion, Michael.
Before finding the resolution to a particular Nortel DHCP relay issue, I really could have used such functionality to quickly determine the cause of the failure.
In regards to your emphasis on linker tables versus #ifdef, if we ever get around to supporting modularization of some sort, we could offer various hook-/filter-points to modules... An example would be a module that gets a chance to scrutinize and possibly modify a DHCP request packet before transmission ("Do I have anything I'd like to say to the DHCP server?").
It seems to me that where we currently find linker tables in the code, those might be good spots for runtime modules to "attach" themselves. It seems very natural to me, somehow. Even a single "extension" entry on each table might be useful, if tables were all tables of functions returning data, rather than data.
But I often get stuck in "analysis paralysis" during thought processes regarding abstraction of code... Where is the balance between gPXE being a network boot-loader and being an OS kernel itself? Since not 100% of users' needs can be met within the constraint space, whose needs get left out? If it's going to be a kernel of sorts for features to plug in to, it will have to be small and fast, where usually you "pick one". If it's going to be a highly optimized atomic package of features, it'll be an assembly...? Ha!
Anyway, have a nice day. - Shao Miller
_______________________________________________ gPXE mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe
