The specific rollover value is unspecified, but we assume that the other
side is U-Boot which rolls over to 0.
https://github.com/u-boot/u-boot/blob/bb0f3eebb3c196d9b6efbbd1e5aa9b16abbb9ad6/net/tftp.c#L275
This allows for very large images to be transferred, which is sometimes
necessary for running debugging or profiling tools designed for normal
Linux distributions such as perf.
There is nothing in this commit except for the changes made by
nix-shell -p nixfmt-rfc-style --run "nixfmt ."
If this has mucked up your open branches then sorry about that. You
can probably nixfmt them to match before merging
* [] is now [ ]
* {} is now { }
* commas in arglists go at end of line not beginning
In short, I ran the whole thing through nixfmt-rfc-style but only
accepted about 30% of its changes. I might grow accustomed to more
of it over time
1) "Unknown transfer id" message was because the local variable "tid"
is not a transfer id, it is a sequence number - so the check was
actually comparing expected vs actual acknowledged sequence number,
not TID. It's still a problem if we get the wrong one, but it
indicates a lost packet (so we should resend) not a packet that was
sent from somewhere else.
2) if the ACK packet has not been received, our retry should involve
_resending_ it, not just trying to wait for it again.
3) I have removed the timeout condition for terminating the resend
loop, because in practice (assuming both ends have the same timeout
setting) all it did was ensure that the loop only ran once. The
timeout is supposed to regulate how long we wait for before retrying
(it doesn't do this, we wait indefinitely), not how long we wait for
before giving up.
this is due to a rather odd (imo) decision in luasocket which
says that the underlying socket (and therefore its file
descriptor) isn't actually created until we call something
that lets it work out whether ipv4 or ipv6
Peter Collingbourne
dan