On 1/29/26 11:04 AM, Jerome Forissier wrote:

Hello Jerome,

On 29/01/2026 00:43, Marek Vasut wrote:
The TFTP server can report the size of the entire file that is about to
be received in the Transfer Size Option, this is described in RFC 2349.
This functionality is optional and the server may not report tsize in
case it is not supported.

Always send tsize request to the server to query the transfer size,
and in case the server does respond, cache that information locally
in tftp_state.tsize, otherwise cache size 0. Introduce new function
tftp_client_get_tsize() which returns the cached tftp_state.tsize so
clients can determine the transfer size and use it.

Update net/lwip/tftp.c to make use of tftp_client_get_tsize() and
avoid excessive printing of '#' during TFTP transfers in case the
transfer size is reported by the server.

Submitted upstream: https://savannah.nongnu.org/patch/index.php?item_id=10557

Signed-off-by: Marek Vasut <[email protected]>

Nice feature! One minor comment below.

Acked-by: Jerome Forissier <[email protected]>

Good to have you back

[...]

-       if (ctx->block_count % 10 == 0) {
-               putc('#');
-               if (ctx->block_count % (65 * 10) == 0)
-                       puts("\n\t ");
+
+       tftp_tsize = tftp_client_get_tsize();
+       if (tftp_tsize) {
+               pos = clamp(ctx->size, 0UL, tftp_tsize);
+
+               while (ctx->hash_count < pos * 50 / tftp_tsize) {
+                       putc('#');
+                       ctx->hash_count++;
+               }

Nit: with this format being the same as the non-tsize one, the user has no
way to know how many hashes to expect. How about printing percentages instead?

  0%....10%....20%.... etc.

(functional tests may need adjusting though)
Do we already have such a pretty printing function ?

Reply via email to