|
From: <ebi...@ln...> - 2001-06-12 03:15:48
|
Doug Ambrisko <amb...@am...> writes:
> 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.
The third stage has access to the DHCP results so it shouldn't need
to do any send/receive. Just parse out the DHCP options.
Eric
|
