nsh_fileapps and usage of sched_lock()
Hi all, I noticed that when spawning a new task/process from a file in nsh_fileapps, the scheduler is locked prior to calling posix_spawn(), which does the file loading into memory etc. I noticed one issue with this; when the file size is large (in the order of MB) the scheduler is locked for very long periods at a time, in the order of hundreds of milliseconds. So my question is, is the scheduler lock strictly necessary in this case ? The only reason I could surmise from the comment below is that waitpid is not performed on a stale pid (or even a possibly re-taken pid ?): /* Lock the scheduler in an attempt to prevent the application from * running until waitpid() has been called. */ sched_lock(); A follow-up question obviously is, what happens if the scheduler lock is removed ? Will something bad happen and if so, is there a way to mitigate this (other than the sched_lock())? My reason for removing the scheduler lock is obviously that I lose all real-time assurances of the OS when I'm starting a process, e.g. I start losing sensor data during the process load time. Any and all help on this is greatly appreciated. BR, Ville Juven / pussuw on github
Re: nsh_fileapps and usage of sched_lock()
On Wed, Oct 25, 2023 at 5:16 AM Ville Juven wrote: > Hi all, > > I noticed that when spawning a new task/process from a file in > nsh_fileapps, the scheduler is locked prior to calling posix_spawn(), which > does the file loading into memory etc. > > I noticed one issue with this; when the file size is large (in the order of > MB) the scheduler is locked for very long periods at a time, in the order > of hundreds of milliseconds. This sounds like a bug. The scheduler should not be locked during IO-bound operations, since there is no way to know how long they will take. Loading from flash could take hundreds of milliseconds (which is already terrible) but imagine a different scenario where loading from a network with connection problems outside of the device could lock the device for many seconds! More below... So my question is, is the scheduler lock strictly necessary in this case ? > The only reason I could surmise from the comment below is that waitpid is > not performed on a stale pid (or even a possibly re-taken pid ?): > > /* Lock the scheduler in an attempt to prevent the application from >* running until waitpid() has been called. >*/ > > sched_lock(); > > A follow-up question obviously is, what happens if the scheduler lock is > removed ? Will something bad happen and if so, is there a way to mitigate > this (other than the sched_lock())? I have not studied the code but conceptually the file should be loaded (or other IO operations) and only when ready to perform scheduler operation the scheduler should be locked for the minimal length of time. More below... My reason for removing the scheduler lock is obviously that I lose all > real-time assurances of the OS when I'm starting a process, e.g. I start > losing sensor data during the process load time. This is exactly why the scheduler should not be locked for extended lengths of time. Nathan
Re: nsh_fileapps and usage of sched_lock()
On 10/25/23, Nathan Hartman wrote: > On Wed, Oct 25, 2023 at 5:16 AM Ville Juven wrote: > >> Hi all, >> >> I noticed that when spawning a new task/process from a file in >> nsh_fileapps, the scheduler is locked prior to calling posix_spawn(), >> which >> does the file loading into memory etc. >> >> I noticed one issue with this; when the file size is large (in the order >> of >> MB) the scheduler is locked for very long periods at a time, in the order >> of hundreds of milliseconds. > > > > This sounds like a bug. The scheduler should not be locked during IO-bound > operations, since there is no way to know how long they will take. Loading > from flash could take hundreds of milliseconds (which is already terrible) > but imagine a different scenario where loading from a network with > connection problems outside of the device could lock the device for many > seconds! > If I understood this comment correctly: /* Lock the scheduler in an attempt to prevent the application from * running until waitpid() has been called. */ then maybe instead of forcing a sched_lock() we could change the task_state to TSTATE_TASK_INACTIVE or some other that prevent the task to be scheduled again before the posix_spawnp() get finished. BR, Alan
Re: nsh_fileapps and usage of sched_lock()
On 10/25/2023 8:18 AM, Alan C. Assis wrote:
On 10/25/23, Nathan Hartman wrote:
On Wed, Oct 25, 2023 at 5:16 AM Ville Juven wrote:
Hi all,
I noticed that when spawning a new task/process from a file in
nsh_fileapps, the scheduler is locked prior to calling posix_spawn(),
which
does the file loading into memory etc.
I noticed one issue with this; when the file size is large (in the order
of
MB) the scheduler is locked for very long periods at a time, in the order
of hundreds of milliseconds.
This sounds like a bug. The scheduler should not be locked during IO-bound
operations, since there is no way to know how long they will take. Loading
from flash could take hundreds of milliseconds (which is already terrible)
but imagine a different scenario where loading from a network with
connection problems outside of the device could lock the device for many
seconds!
If I understood this comment correctly:
/* Lock the scheduler in an attempt to prevent the application from
* running until waitpid() has been called.
*/
then maybe instead of forcing a sched_lock() we could change the
task_state to TSTATE_TASK_INACTIVE or some other that prevent the task
to be scheduled again before the posix_spawnp() get finished.
BR,
Alan
I think that the sched_lock() is not necessary. Notice that the this
is only "an attempt" to keep the application from running and
executing. Without the sched_lock(), the task may run and exit before
there is a change to call waitpid() which should effect only the user
experience.
A good test to make sure that still works would be remove the
sched_lock/unlock and add a test case like:
int main(int argc, char **argv)
{
return 0;
}
That is the case that the logic is trying to avoid, but it seems like it
should work fine. Subsequent logic handles this case (but provides no
use feedback). See comments:
/* Wait for the application to exit. We did lock the scheduler
* above, but that does not guarantee that the application
did not
* already run to completion in the case where I/O was
redirected.
* Here the scheduler will be unlocked while waitpid is waiting
* and if the application has not yet run, it will now be able to
* do so.
*
* NOTE: WUNTRACED does nothing in the default case, but in the
* case the where CONFIG_SIG_SIGSTOP_ACTION=y, the file app
* may also be stopped. In that case WUNTRACED will force
* waitpid() to return with ECHILD.
*/
And
/* If the child thread doesn't exist, waitpid() will
return the
* error ECHLD. Since we know that the task was successfully
* started, this must be one of the cases described above; we
* have to assume that the task already exit'ed. In this
case,
* we have no idea if the application ran successfully or not
* (because NuttX does not retain exit status of child
tasks).
* Let's assume that is did run successfully.
*/
So it looks to me like the case where the program exits is already handled.
Re: nsh_fileapps and usage of sched_lock()
On 10/25/2023 8:48 AM, Gregory Nutt wrote: On 10/25/2023 8:18 AM, Alan C. Assis wrote: On 10/25/23, Nathan Hartman wrote: On Wed, Oct 25, 2023 at 5:16 AM Ville Juven wrote: Hi all, I noticed that when spawning a new task/process from a file in nsh_fileapps, the scheduler is locked prior to calling posix_spawn(), which does the file loading into memory etc. I noticed one issue with this; when the file size is large (in the order of MB) the scheduler is locked for very long periods at a time, in the order of hundreds of milliseconds. The same logic exists in apps/nshlib/nsh_builtin.c. In fact, it looks like one was just cloned from the other. Both should behave the same way.
Re: nsh_fileapps and usage of sched_lock()
Hi, Thanks for the responses, they are very much appreciated. I suspected that the scheduler lock can be removed without too severe side effects (I made a PR of it already). I made a PR of removing it from nsh_fileapps already since I think that is potentially a more critical place to fix due to the file I/O. Loading the process into memory can take a relatively long time. I did notice that the builtin apps do the same but deemed that as not-so-critical because the builtins are already in memory. I did not immediately fix it due to regression mitigation but I can fix the builtin apps as well if you wish. Br, Ville Juven On Wed, Oct 25, 2023 at 5:55 PM Gregory Nutt wrote: > On 10/25/2023 8:48 AM, Gregory Nutt wrote: > > On 10/25/2023 8:18 AM, Alan C. Assis wrote: > >> On 10/25/23, Nathan Hartman wrote: > >>> On Wed, Oct 25, 2023 at 5:16 AM Ville Juven > wrote: > >>> > Hi all, > > I noticed that when spawning a new task/process from a file in > nsh_fileapps, the scheduler is locked prior to calling posix_spawn(), > which > does the file loading into memory etc. > > I noticed one issue with this; when the file size is large (in the > order > of > MB) the scheduler is locked for very long periods at a time, in the > order > of hundreds of milliseconds. > The same logic exists in apps/nshlib/nsh_builtin.c. In fact, it looks > like one was just cloned from the other. Both should behave the same way. >
Multiple IP addresses with a single GMAC (RMII PHY)
Hi all, forgive my ignorance, I’ve just started diving into networking topics (including handling connections via Berkeley sockets). My final goal is to make my device reachable via two separate IP addresses with a single PHY. Once there are two IP addresses set up I'd bind to each specific address to get two socket handles with which my application could work - does that make sense (the use case would be in connection with an integrated switch, e.g. a KSZ8463)? In linux systems I think this can be achieved via ifconfig eth0:0 [newAddress] netmask [mask] up or by persisting the configuration in /etc/network/interfaces (i.e. in my understanding by creating an alias network interface). Now in Nuttx ifconfig does not allow this and there is no persistent configuration. I can't imaging calling netlib_set_ipv4addr() / netlib_set_dripv4addr () / netlib_set_ipv4netmask() twice with the same ifname will work so the question remains: how do I get a second interface I can work with? Do I even need to integrate more potent hardware such as a KSZ9477S that has multiple physical GMACS? Any insights or tipps in which direction to look are welcome! Thanks and best regards -Matthias
Re: Multiple IP addresses with a single GMAC (RMII PHY)
On 10/25/2023 9:27 AM, Matthias Roosz wrote: Hi all, forgive my ignorance, I’ve just started diving into networking topics (including handling connections via Berkeley sockets). My final goal is to make my device reachable via two separate IP addresses with a single PHY. Once there are two IP addresses set up I'd bind to each specific address to get two socket handles with which my application could work - does that make sense (the use case would be in connection with an integrated switch, e.g. a KSZ8463)? In linux systems I think this can be achieved via ifconfig eth0:0 [newAddress] netmask [mask] up or by persisting the configuration in /etc/network/interfaces (i.e. in my understanding by creating an alias network interface). I think you would need to implement something like this in NuttX too. Now in Nuttx ifconfig does not allow this and there is no persistent configuration. I can't imaging calling netlib_set_ipv4addr() / netlib_set_dripv4addr () / netlib_set_ipv4netmask() twice with the same ifname will work so the question remains: how do I get a second interface I can work with? Do I even need to integrate more potent hardware such as a KSZ9477S that has multiple physical GMACS? The network interface is controlled by the network MAC driver. Its device structure carries the IP address and netmask that are associated with the MAC via IOCTLs, but I don't think that the driver itself knows anything about IP (it shouldn't!) The IP address and netmask normally defines a subnet and, hence, the network. Normally two IP addresses would reside on the same network. In this case do you want to support two different IP address from different networks? I hope not (only because I don't understand that model, perhaps it doesn't matter to the software). The IP routing is purely based on the IP address stored in the device structure. If you want routing to two different address on the subnet, then you would need two IP address in the device structure. Again, these should have nothing to do with the MAC driver. You would need (1) a network IOCTL and NSH ifconfig extension to set the second IP address (following the Linux convention), and (2) logic throughout the network code to handle the second address. The IP routing is one place, but there are lots of others. In most of these, where the first IP address is referenced, you would need to add logic to use the first IP address OR the second IP address. This would mean both IPv4 and IPv6. Supporting the second address has size/performance implications and probably should be a Kconfig option. That would be a significant effort, but not overwhelmingly impossible.
Multiple IP addresses with a single GMAC (RMII PHY)
Hi all, forgive my ignorance, I've just started diving into networking topics (including handling connections via Berkley sockets). My final goal is to make my device reachable via two separate IP addresses with a single PHY. Once there are two IPs set up I'd bind to each specific address to get two socket handles with which my application could work - does that make sense (the use case would be in connection with an integrated switch, e.g. a KSZ8463)? In linux systems I think this can be achieved via ifconfig eth0:0 [newAddress] netmask [mask] up or by persisting the configuration in /etc/network/interfaces (i.e. in my understanding by creating an alias network interface). Now in Nuttx ifconfig does not allow this and there is no persistent configuration. I can't imaging calling netlib_set_ipv4addr() / netlib_set_dripv4addr () / netlib_set_ipv4netmask() twice with the same ifname will work so the question remains: how do I get a second interface I can work with? Do I even need to integrate more potent hardware such as a KSZ9477S that hase multiple physical GMACS? Any insights or tipps in which direction to look are welcome! Thanks and best regards -Matthias *** E-Mail wurde verschlüsselt übertragen
Re: ws2812 on sam
Hello,
Actually, looking closer at the samd21 datasheet, my led pin can be
configured in SPI MOSI.
In board/samd2l2/arduino-m0/src/ I added sam_ws2812.c, sam_ws2812.h which
are a adapted copy of the stm32 version.
Everything compiles but on "nsh> ls /dev", I can see that the led device
(/dev/leds0) is not here.
I would like to debug with Syslog but I can't get any error messages in the
console.
I am expecting to get error messages in the console but I get only 'nsh> ABD
Now my bringup.c is looking like:
#ifdef CONFIG_WS2812
/* Configure and initialize the WS2812 LEDs. */
#pragma message ("Configure and initialize the WS2812 LEDs with spi driver")
ret = board_ws2812_initialize(0, 2, CONFIG_WS2812_LED_COUNT);
if (ret < 0)
{
syslog(LOG_ERR, "ERROR: board_ws2812_initialize() failed: %d\n", ret);
}
#endif
I setup the board.h with sercom2 to be SPI:
/* SERCOM2 SPI is available on EXT2
*
* PIN PORT SERCOM FUNCTION
* --- -- ---
* ** PA17 SERCOM2 PAD2 SPI SS
* ** PA15 SERCOM2 PAD3 SPI MOSI
* ** PA8 SERCOM2 PAD0 SPI MISO
* ** PA9 SERCOM2 PAD1 SPI SCK
*/
#define BOARD_SERCOM2_GCLKGEN 0
#define BOARD_SERCOM2_SLOW_GCLKGEN BOARD_SERCOM05_SLOW_GCLKGEN
#define BOARD_SERCOM2_MUXCONFIG (SPI_CTRLA_DOPO_DOPAD231 | SPI_CTRLA_DIPAD0)
#define BOARD_SERCOM2_PINMAP_PAD0 PORT_SERCOM2_PAD0_2 /* SPI_MISO */
#define BOARD_SERCOM2_PINMAP_PAD2 0 /* microSD_SS */
#define BOARD_SERCOM2_PINMAP_PAD3 PORT_SERCOM2_PAD3_1 /* SPI_MOSI */
#define BOARD_SERCOM2_PINMAP_PAD1 PORT_SERCOM2_PAD1_2 /* SPI_SCK */
#define BOARD_SERCOM2_FREQUENCY BOARD_GCLK0_FREQUENCY
In menuconfig, I activated debug Syslog in
Build Setup->Debug Option:
(0) Fortify Source
[*] Define NDEBUG globally
[*] Enable Debug Features
*** Debug SYSLOG Output Controls ***
[*] Enable Error Output
[*] Enable Warnings Output
[*] Enable Informational Debug Output
[ ] Enable Debug Assertions
*** Subsystem Debug Options ***
[ ] File System Debug Features
[ ] Graphics Debug Features
[ ] C Library Debug Features
[ ] Memory Manager Debug Features
[ ] Power-related Debug Features
[ ] Battery-related Debug Features
[ ] Scheduler Debug Features
*** OS Function Debug Options ***
[ ] Interrupt Controller Debug Features
*** Driver Debug Options ***
[*] Low-level LED Debug Features
[*] LED Driver Error Output
[*] LED Driver Warnings Output
[*] LED Driver Informational Output
[*] GPIO Debug Features
[*] GPIO Error Output
[*] GPIO Warnings Output
[*] GPIO Informational Output
[*] SPI Debug Features
[*] SPI Error Output
[*] SPI Warnings Output
[*] SPI Informational Output
[ ] Timer Debug Features
[ ] IPC (Interprocessor communication) Debug Features
[ ] Stack coloration
[ ] Compiler stack canaries
[ ] Generate stack usage information
(0) Detect use of large stack variables
[*] Generate Debug Symbols
Device Driver -> System logging option:
*** SYSLOG options ***
(1) Maximum SYSLOG channels
[ ] RAM log device support
[ ] Use buffered output
[ ] Use interrupt buffer
*** Formatting options ***
[ ] Prepend timestamp to syslog message
[ ] Prepend priority to syslog message
[ ] Prepend process name to syslog message
[ ] Prepend process ID to syslog message
[ ] Prepend prefix to syslog message
[ ] Colored syslog output
*** SYSLOG channels ***
(/dev/ttyS0) System log device
[ ] Log to a character device
[ ] Log to stream
[*] Log to /dev/console
[*] Default SYSLOG device
[ ] SYSLOG rpmsg server character device
[ ] Syslog file output
[*] SYSLOG character device
[ ] SYSLOG IOCTL support
Regards,
Bertrand.
Re: ws2812 on sam
Hi Bert,
Please look your System.map and confirm it is generating the function
board_ws2812_initialize(). Something it is not even included because
some missing configuration.
You enabled DEBUG LED INFO, show you should see some messages in the
console if it was called, see: drivers/leds/ws2812.c
BR,
Alan
On 10/25/23, Bert Voldenuit wrote:
> Hello,
>
> Actually, looking closer at the samd21 datasheet, my led pin can be
> configured in SPI MOSI.
>
> In board/samd2l2/arduino-m0/src/ I added sam_ws2812.c, sam_ws2812.h which
> are a adapted copy of the stm32 version.
> Everything compiles but on "nsh> ls /dev", I can see that the led device
> (/dev/leds0) is not here.
>
> I would like to debug with Syslog but I can't get any error messages in the
> console.
> I am expecting to get error messages in the console but I get only 'nsh>
> ABD
>
> Now my bringup.c is looking like:
>
> #ifdef CONFIG_WS2812
> /* Configure and initialize the WS2812 LEDs. */
> #pragma message ("Configure and initialize the WS2812 LEDs with spi
> driver")
>
> ret = board_ws2812_initialize(0, 2, CONFIG_WS2812_LED_COUNT);
> if (ret < 0)
> {
> syslog(LOG_ERR, "ERROR: board_ws2812_initialize() failed: %d\n", ret);
> }
> #endif
>
> I setup the board.h with sercom2 to be SPI:
>
> /* SERCOM2 SPI is available on EXT2
> *
> * PIN PORT SERCOM FUNCTION
> * --- -- ---
> * ** PA17 SERCOM2 PAD2 SPI SS
> * ** PA15 SERCOM2 PAD3 SPI MOSI
> * ** PA8 SERCOM2 PAD0 SPI MISO
> * ** PA9 SERCOM2 PAD1 SPI SCK
> */
>
> #define BOARD_SERCOM2_GCLKGEN 0
> #define BOARD_SERCOM2_SLOW_GCLKGEN BOARD_SERCOM05_SLOW_GCLKGEN
> #define BOARD_SERCOM2_MUXCONFIG (SPI_CTRLA_DOPO_DOPAD231 |
> SPI_CTRLA_DIPAD0)
> #define BOARD_SERCOM2_PINMAP_PAD0 PORT_SERCOM2_PAD0_2 /* SPI_MISO */
> #define BOARD_SERCOM2_PINMAP_PAD2 0 /* microSD_SS */
> #define BOARD_SERCOM2_PINMAP_PAD3 PORT_SERCOM2_PAD3_1 /* SPI_MOSI */
> #define BOARD_SERCOM2_PINMAP_PAD1 PORT_SERCOM2_PAD1_2 /* SPI_SCK */
>
> #define BOARD_SERCOM2_FREQUENCY BOARD_GCLK0_FREQUENCY
>
>
> In menuconfig, I activated debug Syslog in
>
> Build Setup->Debug Option:
> (0) Fortify Source
> [*] Define NDEBUG globally
> [*] Enable Debug Features
> *** Debug SYSLOG Output Controls ***
> [*] Enable Error Output
> [*] Enable Warnings Output
> [*] Enable Informational Debug Output
> [ ] Enable Debug Assertions
> *** Subsystem Debug Options ***
> [ ] File System Debug Features
> [ ] Graphics Debug Features
> [ ] C Library Debug Features
> [ ] Memory Manager Debug Features
> [ ] Power-related Debug Features
> [ ] Battery-related Debug Features
> [ ] Scheduler Debug Features
> *** OS Function Debug Options ***
> [ ] Interrupt Controller Debug Features
> *** Driver Debug Options ***
> [*] Low-level LED Debug Features
> [*] LED Driver Error Output
> [*] LED Driver Warnings Output
> [*] LED Driver Informational Output
> [*] GPIO Debug Features
> [*] GPIO Error Output
> [*] GPIO Warnings Output
> [*] GPIO Informational Output
> [*] SPI Debug Features
> [*] SPI Error Output
> [*] SPI Warnings Output
> [*] SPI Informational Output
> [ ] Timer Debug Features
> [ ] IPC (Interprocessor communication) Debug Features
> [ ] Stack coloration
> [ ] Compiler stack canaries
> [ ] Generate stack usage information
> (0) Detect use of large stack variables
> [*] Generate Debug Symbols
>
> Device Driver -> System logging option:
> *** SYSLOG options ***
> (1) Maximum SYSLOG channels
> [ ] RAM log device support
> [ ] Use buffered output
> [ ] Use interrupt buffer
> *** Formatting options ***
> [ ] Prepend timestamp to syslog message
> [ ] Prepend priority to syslog message
> [ ] Prepend process name to syslog message
> [ ] Prepend process ID to syslog message
> [ ] Prepend prefix to syslog message
> [ ] Colored syslog output
> *** SYSLOG channels ***
> (/dev/ttyS0) System log device
> [ ] Log to a character device
> [ ] Log to stream
> [*] Log to /dev/console
> [*] Default SYSLOG device
> [ ] SYSLOG rpmsg server character device
> [ ] Syslog file output
> [*] SYSLOG character device
> [ ] SYSLOG IOCTL support
>
>
> Regards,
> Bertrand.
>
Re: Multiple IP addresses with a single GMAC (RMII PHY)
Hi Matthias, I agree with Gregory's opinion, if you want to do the same thing on NuttX as you do on Linux, you'll need both: 1. Support multiple IP addresses in the device structure 2. Support the alias like 'eth0:0' because the ioctl of IPv4 address is designed to set one address per interface, so only with aliases we can set more addresses into one device by ioctl (or use netlink instead of ioctl) But I do have another idea: Maybe you can try to register two network devices even if you only have a single GMAC, just dup all the rx packets to both interfaces, and let all tx packets go out. Since the IP addresses are different on each interface, the stack may drop packets on the incorrect interface and accept the correct one. It may have some problems in some situations like broadcast I guess, but I think it may have a chance to work. Another note: I'm working on supporting multiple IPv6 addresses per device structure these days, but not yet finished (and not planning for IPv4). I posted it as a draft: https://github.com/apache/nuttx/pull/11054 in case you really want to implement the IPv4 one. Best Regards, Zhe Gregory Nutt wrote: > On 10/25/2023 9:27 AM, Matthias Roosz wrote: > > Hi all, > > > > > > > > forgive my ignorance, I’ve just started diving into networking topics > > (including handling connections via Berkeley sockets). My final goal is to > > make my device reachable via two separate IP addresses with a single PHY. > > Once there are two IP addresses set up I'd bind to each specific address to > > get two socket handles with which my application could work - does that > > make sense (the use case would be in connection with an integrated switch, > > e.g. a KSZ8463)? > > > > In linux systems I think this can be achieved via ifconfig eth0:0 > > [newAddress] netmask [mask] up or by persisting the configuration in > > /etc/network/interfaces (i.e. in my understanding by creating an alias > > network interface). > I think you would need to implement something like this in NuttX too. > > Now in Nuttx ifconfig does not allow this and there is no persistent > > configuration. I can't imaging calling netlib_set_ipv4addr() / > > netlib_set_dripv4addr () / netlib_set_ipv4netmask() twice with the same > > ifname will work so the question remains: how do I get a second interface I > > can work with? Do I even need to integrate more potent hardware such as a > > KSZ9477S that has multiple physical GMACS? > > The network interface is controlled by the network MAC driver. Its > device structure carries the IP address and netmask that are associated > with the MAC via IOCTLs, but I don't think that the driver itself knows > anything about IP (it shouldn't!) > > The IP address and netmask normally defines a subnet and, hence, the > network. Normally two IP addresses would reside on the same network. > In this case do you want to support two different IP address from > different networks? I hope not (only because I don't understand that > model, perhaps it doesn't matter to the software). > > The IP routing is purely based on the IP address stored in the device > structure. If you want routing to two different address on the subnet, > then you would need two IP address in the device structure. Again, > these should have nothing to do with the MAC driver. You would need (1) > a network IOCTL and NSH ifconfig extension to set the second IP address > (following the Linux convention), and (2) logic throughout the network > code to handle the second address. The IP routing is one place, but > there are lots of others. In most of these, where the first IP address > is referenced, you would need to add logic to use the first IP address > OR the second IP address. This would mean both IPv4 and IPv6. > > Supporting the second address has size/performance implications and > probably should be a Kconfig option. > > That would be a significant effort, but not overwhelmingly impossible. > #/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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!**/#
