u-boot.lists.denx.de archive mirror
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Wolfgang Denk <wd@denx.de>
Cc: Simon Glass <sjg@chromium.org>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>,
	u-boot@lists.denx.de
Subject: Re: [PATCH 1/2] xyz-modem: Wait infinitely for initial y-modem packet
Date: Mon, 13 Sep 2021 13:08:06 +0200	[thread overview]
Message-ID: <20210913110806.27hc36n6gmhw6uq4@pali> (raw)
In-Reply-To: <1325940.1631529762@gemini.denx.de>

On Monday 13 September 2021 12:42:42 Wolfgang Denk wrote:
> Dear Pali Rohár,
> 
> In message <20210910204653.3066-1-pali@kernel.org> you wrote:
> > Now when command loady can be aborted / cancelled by CTRL+C, change wait
> > timeout for initial packet to infinite. This would allow user to not be
> > hurry when locating file which want to send. Commands loadb and loads
> > already waits infinitely too.
> 
> I'm not sure if this is a good idea.
> 
> If you use loady in any kind of scripts, this would now hard hang
> the system, while until now it was possible to recover from the
> error.

Yes, this is a good point. But on the other hand, 'loadb' and 'loads'
commands already have this behavior. So question is if it is better to
have same behavior in all 'load?' commands or each 'load?' would behave
differently... Because for software which transmit files and supports
more protocols (e.g. both x-modem and kermit) it may be a nightmare if
receiver behaves differently...

> This is a change to the user interface that is not really necessary,
> so I recommend NOT to change the behaviour here, especially as it
> does not hurt.

Well... there is an issue if you do not start file transfer in the
timeout which current 'loady' command expects.

If you do not have integrated y-modem support in your terminal you have
to do:

1) open terminal and write 'loady' into U-Boot console
2) disconnect terminal
3) start y-modem software
4) choose file to transmit
5) instruct y-modem software to start transfer

And if 'loady' timeouts between 2) - 5) then it returns back to the
U-Boot console. So y-modem software in step 5) starts interaction with
U-Boot console instead of 'loady' and try to interpret U-Boot prompt as
y-modem sequence... which is detected as garbage and y-modem software
would either wait or try retransmit... which sends some garbage to
U-Boot console and something may be executed.

'loadb' commands does not have this issue as it waits either for CTRL+C
or for successful kermit transfer.


So... I do not know what is better if current behavior or this new which
changes UI interaction.

> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> "I've finally learned what `upward compatible' means. It means we get
> to keep all our old mistakes." - Dennie van Tassel

  reply	other threads:[~2021-09-13 11:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10 20:46 [PATCH 1/2] xyz-modem: Wait infinitely for initial y-modem packet Pali Rohár
2021-09-10 20:46 ` [PATCH 2/2] xyz-modem: Wait infinitely for initial x-modem packet Pali Rohár
2021-09-13 10:43   ` Wolfgang Denk
2021-09-13 10:42 ` [PATCH 1/2] xyz-modem: Wait infinitely for initial y-modem packet Wolfgang Denk
2021-09-13 11:08   ` Pali Rohár [this message]
2021-09-13 12:12     ` Wolfgang Denk
2021-09-13 12:22       ` Pali Rohár
2021-09-13 13:02         ` Wolfgang Denk
2022-08-27 11:50           ` Pali Rohár
2021-09-13 14:32     ` Tom Rini
2022-08-27 11:48 ` [PATCH v2] xyz-modem: Allow to configure initial timeout for loadx and loady Pali Rohár
2022-08-27 12:53   ` Tom Rini
2022-08-27 12:56     ` Pali Rohár
2022-08-27 14:30       ` Tom Rini
2022-08-27 14:32         ` Pali Rohár
2022-08-27 14:41           ` Tom Rini
2022-08-27 14:47             ` Pali Rohár
2022-08-29 14:54   ` Heinrich Schuchardt
2022-08-27 14:37 ` [PATCH v3] " Pali Rohár

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210913110806.27hc36n6gmhw6uq4@pali \
    --to=pali@kernel.org \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=wd@denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).