Re: [Etherboot-developers] Re: Etherboot and FreeBSD

[<ebi...@ln...>]

Michael Sinz <ms...@wg...> writes:

> Ken Yap wrote:
> > 
> > |FreeBSD has a rather nasty design flaw that made me dig into
> > |Etherboot.  I tried to disturb as little as possible in the
> > |patch I submitted (here on this site)
> > |
> > |BTW - This is the first time I have submitted a patch to a
> > |sourceforge run project.  I hope this was the correct way to
> > |do so.
> > 
> > Yes, that's fine, except there are special circumstances for FreeBSD.
> > 
> > |If you have any questions, please feel free to contact me at
> > |the above address and/or mic...@si...
> > 
> > Could you please resubmit to eth...@li....
> > Reason is the main FreeBSD maintainer is on that list. I don't have
> > FreeBSD myself and can't verify your patch. He can tell you if your
> > concerns are valid and if you have fixed it the right way.
> 
> I have tried to submit it on the site and even though I include it
> in the HTTP post, it does not show up on the web site.  Something may
> be wrong (or maybe it does not like what I sent?)
> 
> Anyway, the patch is attached here (and this is going to the
> etherboot-developers list.
> 
> The problem (or not so much problem but design quirk) with FreeBSD
> is that it needs the debugging symbols (if you strip the kernel it
> will not work) to be loaded when the kernel is loaded.  Plus, these
> symbols must be set up in a special way and pointed to via a metadata
> structure that is pointed to by the bootinfo structure that is passed
> as part of the boot process.
> 
> I have made changes to the osloader.c code to support this behavior.
> This lets FreeBSD be loaded via Etherboot for a diskless system
> (such as via DHCPD/BOOTP setups) and work.  This affects only the Elf
> (FreeBSD 3.x/4.x) versions due to the way symbols are handled.
> 
> All of the changes are within the #ifdef IMAGE_FREEBSD sections
> and have been verified in our lab to not interfere with other booting
> processes (and other builds that are not FREEBSD based)

Have you considered something like mkelf-freebsd.  That will take
a free BSD kernel and build an appropriate PT_LOAD section for the
debugging information?

Just skimming your patch I could imagine half a dozen ways it could
fail if something in the freebsd build process  changed in the future.

Eric