> I think my biggest concern with the solution is that it > effectively makes > it impossible to received any out-of-band data: Any > encoded, > context-dependent, escaped data will be echoed back to the > host > unconditionally making it impossible to receive cleanly.
But this behavior can be disabled by termios if needed, and it only affect console port by default. And cr/lf convertion also break this. > We have already seen this in escape sequences sent from the > host appearing > appearing on the user console. An awful solution > was adopted: Just remove > the escape sequence. That is called > "sweeping the problem under the rug." > This will be a serious > limitation that will effect our capability to > implement many serial > protocols and bad thing to happen to the OS. The current approach could be improved, such as let readline/cle to erase the escape sequence on console, what's your suggestion ? In general, I think it's a step forward, why we submit such a patch? 1.Telnet before this patch always echo input twice since telnet echo character itself by default. 2.Many application must do echo itself, such as readline/cle/bas. But the bigge problem is, for some software ported from other posix compatible system, they don't do echo by themself, for these applications like WAMR's repl (respacially with REPL) you can't see the input unless you modify the source to adapt it to NuttX. ________________________________ 发件人: Qi3 Huang 黄齐 发送时间: 2023年3月11日 0:05:41 收件人: dev@nuttx.apache.org 主题: 答复: 答复: 答复: [External Mail]Re: [Breaking change] Echo character by serial driver Thanks for point that, so my change will affect them by serial.c since it's in common logic (excatly, is in uart_read()). ________________________________ 发件人: Gregory Nutt <spudan...@gmail.com> 发送时间: 2023年3月10日 23:58:29 收件人: dev@nuttx.apache.org 主题: Re: 答复: 答复: [External Mail]Re: [Breaking change] Echo character by serial driver [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给mi...@xiaomi.com进行反馈 > Emm, I confirmed that one of my test platform (esp32c3), its cdcacm driver > implement the uart_ops, but rp2040 seems not. > > > CLE should works since it will override the content from driver ECHO if over > serial driver, but readline shouldn't echo input. > > > I'll test more to confirm it. cdcacm.c is the part that is similar to serial.c. It implements the serial driver interface and also interfaces with the lower level USB device driver. cdcacm.c resides at drivers/usbdev/cdcacm.c and it common for all MCUs. The MCU-specif logic has no idea that there is a cdcacm "gadget" attached to it. cdcacm.c implements the common uart_ops that are used by all MCUs to support CDC/ACM serial. pl2303.c is another USB serial device. It also implements uart_ops and has its own TERMIOS implementation. #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
