This happened frequently for me with Docker Desktop's
/var/run/docker.sock on macOS.
But I believe it can happen on other environments, even with TCP.
Alternatively, this case can be handled by the callback
implementations. But it's simpler to handle the corner case here.
and remove 0001-feat-Switch-to-FreeBSD-getopt-library.patch
since it is already included in the new official release
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Summary:
- This commit fixes compile warnings with Arm GCC 9.3.1
Impact:
- None
Testing:
- Tested with lm3s6965-ek:discover
- NOTE: need to add the following configs
+CONFIG_EXAMPLES_IPERF=y
+CONFIG_EXAMPLES_IPERFTEST_DEVNAME="eth0"
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
should be CONFIG_EXAMPLES_PTYTEST_SERIALDEV, regression in commit:
commit 6ddbffd200
Author: Xiang Xiao <xiaoxiang@xiaomi.com>
Date: Sun Jan 3 23:50:50 2021 -0800
examples/pty_test: Remove O_NONBLOCK from open
to avoid the log storm:
ERROR Failed to read from serial: 11
ERROR Failed to read from serial: 11
ERROR Failed to read from serial: 11
ERROR Failed to read from serial: 11
ERROR Failed to read from serial: 11
...
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
to avoid the log storm:
ERROR Failed to read from serial: 11
ERROR Failed to read from serial: 11
ERROR Failed to read from serial: 11
ERROR Failed to read from serial: 11
ERROR Failed to read from serial: 11
...
Change-Id: I821743411c33b5412165f1e9020b6c9ce6c24660
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
The examples/webserver app can be built in two modes:
(1) in standalone mode, or
(2) as a NSH built-in app.
When run in standalone mode, the webserver program is responsible for
bringing up the network (including DHCP if configured). Also, the
webserver program must never exit, so if httpd fails (i.e., if
httpd_listen() returns), webserver_main() goes into an endless loop.
When run as a NSH built-in app, network bring-up is the responsibility
of other processes and the webserver program assumes the network is
already properly configured when it starts. Also, if httpd_listen()
returns, the webserver program should terminate.
Prior to this change, the webserver program would *not* terminate,
even when running as a NSH built-in app. For example:
nsh> webserver &
webserver [6:100]
nsh> Starting webserver
nsh> kill -9 6
nsh> webserver_main: Still running
nsh> webserver_main: Still running
nsh> webserver_main: Still running
nsh> webserver_main: Still running
The line "webserver_main: Still running" would be forever printed
every 3 seconds, however httpd_listen() is no longer running and the
webserver is not functional.
This change makes the webserver play nicely when running as a NSH
built-in app. With this change applied:
nsh> webserver &
webserver [6:100]
nsh> Starting webserver
nsh> kill -9 6
nsh> webserver_main: Exiting
apps/examples/webserver/webserver_main.c:
* main(): Infer from CONFIG_NSH_BUILTIN_APPS if this is a
standalone program or a NSH built-in app. (See [1], where
similar logic was added to decide whether to do network bring-up
or not.) If standalone, run forever as before. If built-in
app, exit when httpd terminates.
References:
[1] Commit 3a21b0b222
N/A
which record and play raw data using audio subsystem
to verify audio record and playback function
Signed-off-by: danguanghua <danguanghua@xiaomi.com>
Change-Id: I2c768b8e8234a31f9622cb9955f785329cf402a5
Signed-off-by: danguanghua <danguanghua@xiaomi.com>
* It doesn't make much sense to have the default values for
these highly environment-dependent settings.
* netutils/netinit/netinit_associate.c calls wpa_driver_wext_associate
if the SSID is not empty. Depending on the environment, it can take
long to fail. It slows down the boot of some configurations
considerably. eg. esp32-devkitc:wapi
wget is missing from some system (like macOS and Windows native),
it's better to use curl to simplify build environment.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
N/A
to avoid multiple open operations of audio_open
Change-Id: Id283def4811c71f3c0bd38dc1a480afce303c4c3
Signed-off-by: danguanghua <danguanghua@xiaomi.com>
