Doug Ambrisko wrote:
>
> Eric W. Biederman writes:
> | least would put the complexity in mknbi. I hate to see etherboot
> | clutered up with OS specific code, when it has size constraints.
> |
> | If we could download that code etherboot get to stay smaller.
>
> Note that it is all hidden under #define for FreeBSD so if you don't have
> FreeBSD defined then there is no impact. The size if the same.
>
> Well we sort-of have that type of thing. It's called the third stage loader
> and is PXE compliant. If EtherBoot or Nilo or whatever exposed a PXE
> compliant environment then this would be done. I don't see how mknbi
> is going to help since it at best passes static info to whatever it loads
> and they is no network API exposed to it to send and receive packets.
There is a third stage bootloader program that is included in a
tagged image by mk{nbi,elf}-linux. That is where the option processing
currently happens, I believe. The size restrictions are more relaxed
on this than on Etherboot (with a little effort, you can easily get
64KB to run it in.)
I would suggest modifying first32.c or adding a new implementation that
does what you need.
-Don
--
Don Christensen Senior Software Development Engineer
dj...@ci... MMABU - Mid-Market Access Business Unit
Cisco Systems ComLOB - Commercial Line of Business
San Jose, CA "So much relies on the course that you take
The fool and the wise man both burn at the stake"
|