Re: [Etherboot-developers] [RFC] Relocation techniques...

[<ke...@us...>]

>I agree but I am unlikely to be one of those working on callbacks.  I do
>not believe callbacks are generally viable.  Or at the very least callbacks
>can easily lead to code being executed in ways it was not tested in,
>and breaking at inoportune moments.
>
>Plus there is some amount of bloat in just forwarding the callbacks to
>the appropriate location.

I'm not a big fan of callbacks either, it means designing another
interface which is slightly architecture dependent.

It's the age old problem of how to communicate load locations to the
loader. Etherboot does it by prepending a directory in front, but this
annoys people who want to boot kernel images fresh from the build.
Personally I don't see an extra tagging step is a big hassle. Maybe one
day all kernel images will be netloader friendly out of the build.
Another way might be a smart TFTP daemon that can assemble virtual
tagged images on the fly. Yet another way might be a special tagged flag
that says: this is just the header, keep the header around then append
or subtract something from the filename to get the body of the image to
fetch. I.e. the TFTP directory would contain:

	vmlinuz.nb.dir	512 bytes, just the header
	vmlinux.nb	the real image

But then you'd need a utility to generate the headers, you can't just
dump the image in the directory hot from the build, so why not just tag
the thing in the first place?