[gPXE] Setting delay time to boot

[Jonathan Andrews]

On Sun, 2010-03-28 at 03:42 -0400, Miller, Shao wrote:
> Good day Jon,
> 
> In regards to a gPXE 'waitfor <ip> <port> <timeout>' command, I have a
> few thoughts:
> 
> If gPXE were to someday support IPv6 or some other network protocol,
> would this command be as applicable/relevant?
I should think so, just six digits instead of 4 ? 

> 
> It would seem that the <port> option implies that we have some way of
> knowing that the <port> is available.  Would it make sense to tie <port>
> to something that gPXE knows how to use, such as a download protocol or
> SAN-boot protocol?
Kinda missing the point a bit, "keep it simple stupid". By simply
waiting for an valid socket connection it keeps the code very simple.
The correct (fat) way is it implement UDP and TCP, do a full challenge
response.... but I would have thought the idea is simply to see if the
host is up. It could be a ping (ICMP echo) - but as an admin I know it
can be a long time between the interface coming up (valid ping replies)
and the services being ready. By looking for just a valid socket connect
(tcp only) on a port you can either check for a network protocol server
or simply look for any old response from the machine.  Its also equally
valid for any server, windows/linux/any old thing ....

> Given that gPXE has a strong focus on small code size for ROM build
> targets, could 'waitfor' or other similar use cases be better
> implemented in a more generic fashion?
Hmmmm I would have thought it was very minimal, I dont know the gpxe
code base but I can assume some sort of tcp session code exists, not
that a full session is required as the simply the "connect" (accept) is
all thats needed, the content would be ignored.

> 
> If the check can be accomplished by repeated download attempts in a
> loop, the scripting discussion in the gPXE developers' mailing-list
> could potentially come to fruition and accomplish this same behaviour in
> a more programmatically generic way, with 'if' and loops, for example.
Valid point, maybe a bit less user friendly as more code is required.
All OK if the documentation for gpxe scripting is first rate, i've not
seen it :-)  I would argue 80/20 rule. 80% of people would want the
"waitfor" type behaviour, but maybe a little tough on the other 20% ?

> As it stands, there are patches not yet committed to the gPXE official
> code-base which can accomplish the behaviour of the suggested 'waitfor'
> command, if the assumption is that a download trial is roughly the same
> as testing for <port>.
> 
> #!gpxe
> clear script_errors
> dhcp net0
> : test_download
> chain http://ip:8080/some_boot_file
> sleep 10
> goto test_download
> 
> In the above, 'chain' should not return, but if it does, we wait ten
> seconds and retry.  The above does not work in current gPXE, but does
> work with some of the patches under discussion.
In that case could not waitfor simply be a macro within gpxe as all the
underlying functions would be in the codebase ? :-D  

I prefer readable simple functions, the "chain" in the above code does
not seem obvious or friendly, also I cant even see how that loop escapes
- to me it reads as stuck as "goto" is not conditional?

Cheers,
Jon