|
From: Doug A. <amb...@am...> - 2001-06-12 02:35:54
|
Donald J Christensen writes:
| 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.
So you are saying that the third stage loader can access the network to
send and receive packets? Before when I looked at it I don't recall
it doing that.
Doug A.
|
