Re: network booting

[ol.sc@web.de (Oliver Schmidt)]

Hi,

>As far as I can work out, the only thing PXE adds over what
>I've got is a standard API on the client side that can be used by the
>downloaded code to talk to the network card. so one bootstrap image
>can be sent by the server to machines of all different hardware types
>irrespective of the type of NIC in the PC's being bootsrapped.

I've been responsible for a commercial network boot solution some
years ago and from that perspective I can tell that your description
above is absolutely correct.

>I don't expect to have to support multiple NICs but it would be nice
>to have an IP stack with some published  stable entry points in
>firmware.

Indeed. Given the fact that both on the C64 and the Apple2 the
currently popular Ethernet solution don't use interrupts but just
heavy polling the API is conceptually very straight forward. However
it could be hard to decide on the API level:

- Low level raw ethernet packet I/O
  - With or without implicit ARP handling
- Mid level IPv4 packet I/O
  - With or without implit ICMP handling
- High level TCP I/O
  - TCP not supported by IP65 afaik

>but I do plan to make a standalone server
>(probably in ruby so it's OS neutral) that combines serving boot
>images via TFTP (and also handles DHCP if people don't already have a
>DHCP server on their network, although most people do have something
>like  a broadband router) along

Unfortunately things aren't that rosy: Typical DHCP servers,
especially the ones in broadband routers, don't allow you to specify a
boot file name to be downloaded via TFTP. So you need your own DHCP
server to do so, but that server interferes with the almost already
existing one :-(

In the commercial product I worked on we therefore had a workaround:
If the DHCP server didn't supply a boot file name then the client used
the IP config given from the DHCP server but sent a second DHCP
request on a non-standard port to get the boot file name. So our DHCP
server was simply configured either on the standard port for
up-to-now-no-DHCP scenarios or on the alternative port for
DHCP-already-in-use scenarios.

Best, Oliver