You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2022/04/21 12:28:00 UTC
[GitHub] [incubator-nuttx] xiaoxiang781216 opened a new pull request, #6120: Implement execle, execve, execvp, execlp and execvpe
xiaoxiang781216 opened a new pull request, #6120:
URL: https://github.com/apache/incubator-nuttx/pull/6120
## Summary
- sched/task: Implement execle and execve
- libc: Implement execvp, execlp and execvpe as macro
## Impact
New API
## Testing
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] pkarashchenko commented on a diff in pull request #6120: Implement execle, execve, execvp, execlp and execvpe
Posted by GitBox <gi...@apache.org>.
pkarashchenko commented on code in PR #6120:
URL: https://github.com/apache/incubator-nuttx/pull/6120#discussion_r855247055
##########
libs/libc/unistd/lib_execle.c:
##########
@@ -0,0 +1,183 @@
+/****************************************************************************
+ * libs/libc/unistd/lib_execle.c
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership. The
+ * ASF licenses this file to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
+ * License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
+ * under the License.
+ *
+ ****************************************************************************/
+
+/****************************************************************************
+ * Included Files
+ ****************************************************************************/
+
+#include <nuttx/config.h>
+
+#include <stdarg.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+
+#include "libc.h"
+
+#ifdef CONFIG_LIBC_EXECFUNCS
+
+/****************************************************************************
+ * Pre-processor Definitions
+ ****************************************************************************/
+
+/* This is an artificial limit to detect error conditions where an argv[]
+ * list is not properly terminated.
+ */
+
+#define MAX_EXECL_ARGS 256
+
+/****************************************************************************
+ * Public Data
+ ****************************************************************************/
+
+/****************************************************************************
+ * Private Data
+ ****************************************************************************/
+
+/****************************************************************************
+ * Public Functions
+ ****************************************************************************/
+
+/****************************************************************************
+ * Name: execle
+ *
+ * Description:
+ * The standard 'exec' family of functions will replace the current process
+ * image with a new process image. The new image will be constructed from a
+ * regular, executable file called the new process image file. There will
+ * be no return from a successful exec, because the calling process image
+ * is overlaid by the new process image.
+ *
+ * Simplified 'execl()' and 'execv()' functions are provided by NuttX for
+ * compatibility. NuttX is a tiny embedded RTOS that does not support
+ * processes and hence the concept of overlaying a tasks process image with
+ * a new process image does not make any sense. In NuttX, these functions
+ * are wrapper functions that:
+ *
+ * 1. Call the non-standard binfmt function 'exec', and then
+ * 2. exit(0).
+ *
+ * Note the inefficiency when 'exec[l|v]()' is called in the normal, two-
+ * step process: (1) first call vfork() to create a new thread, then (2)
+ * call 'exec[l|v]()' to replace the new thread with a program from the
+ * file system. Since the new thread will be terminated by the
+ * 'exec[l|v]()' call, it really served no purpose other than to support
+ * Unix compatility.
+ *
+ * The non-standard binfmt function 'exec()' needs to have (1) a symbol
+ * table that provides the list of symbols exported by the base code, and
+ * (2) the number of symbols in that table. This information is currently
+ * provided to 'exec()' from 'exec[l|v]()' via NuttX configuration setting:
+ *
+ * CONFIG_LIBC_EXECFUNCS : Enable exec[l|v] support
+ * CONFIG_EXECFUNCS_SYMTAB_ARRAY : Symbol table name used by exec[l|v]
+ * CONFIG_EXECFUNCS_NSYMBOLS_VAR : Variable holding number of symbols in
+ * the table
+ *
+ * As a result of the above, the current implementations of 'execl()' and
+ * 'execv()' suffer from some incompatibilities that may or may not be
+ * addressed in a future version of NuttX. Other than just being an
+ * inefficient use of MCU resource, the most serious of these is that
+ * the exec'ed task will not have the same task ID as the vfork'ed
+ * function. So the parent function cannot know the ID of the exec'ed
+ * task.
+ *
+ * Input Parameters:
+ * path - The path to the program to be executed. If CONFIG_LIBC_ENVPATH
+ * is defined in the configuration, then this may be a relative path
+ * from the current working directory. Otherwise, path must be the
+ * absolute path to the program.
+ * ... - A list of the string arguments to be recevied by the
+ * program. Zero indicates the end of the list.
+ *
+ * Returned Value:
+ * This function does not return on success. On failure, it will return
+ * -1 (ERROR) and will set the 'errno' value appropriately.
+ *
+ ****************************************************************************/
+
+int execle(FAR const char *path, FAR const char *arg0, ...)
+{
+ FAR char *arg = (FAR char *)arg0;
+ FAR char **argv;
+ FAR char **envp;
+ size_t nargs;
+ va_list ap;
+ int argc;
+ int ret;
+
+ /* Count the number of arguments */
+
+ va_start(ap, arg0);
+ nargs = 0;
+
+ while (arg != NULL)
+ {
+ /* Yes.. increment the number of arguments. Here is a sanity
+ * check to prevent running away with an unterminated argv[] list.
+ * MAX_EXECL_ARGS should be sufficiently large that this never
+ * happens in normal usage.
+ */
+
+ if (++nargs > MAX_EXECL_ARGS)
+ {
+ set_errno(E2BIG);
+ va_end(ap);
+ return ERROR;
+ }
+
+ arg = va_arg(ap, FAR char *);
+ }
+
+ envp = va_arg(ap, FAR char **);
+ va_end(ap);
+
+ /* Allocate a temporary argv[] array */
+
+ argv = (FAR char **)lib_malloc((nargs + 1) * sizeof(FAR char *));
+ if (argv == NULL)
+ {
+ set_errno(ENOMEM);
+ return ERROR;
+ }
+
+ argv[0] = (FAR char *)arg0;
+
+ /* Collect the arguments into the argv[] array */
+
+ va_start(ap, arg0);
+ for (argc = 1; argc <= nargs; argc++)
+ {
+ argv[argc] = va_arg(ap, FAR char *);
+ }
+
Review Comment:
```suggestion
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a diff in pull request #6120: Implement execle, execve, execvp, execlp and execvpe
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on code in PR #6120:
URL: https://github.com/apache/incubator-nuttx/pull/6120#discussion_r855277012
##########
libs/libc/unistd/lib_execle.c:
##########
@@ -0,0 +1,183 @@
+/****************************************************************************
+ * libs/libc/unistd/lib_execle.c
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership. The
+ * ASF licenses this file to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
+ * License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
+ * under the License.
+ *
+ ****************************************************************************/
+
+/****************************************************************************
+ * Included Files
+ ****************************************************************************/
+
+#include <nuttx/config.h>
+
+#include <stdarg.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+
+#include "libc.h"
+
+#ifdef CONFIG_LIBC_EXECFUNCS
+
+/****************************************************************************
+ * Pre-processor Definitions
+ ****************************************************************************/
+
+/* This is an artificial limit to detect error conditions where an argv[]
+ * list is not properly terminated.
+ */
+
+#define MAX_EXECL_ARGS 256
+
+/****************************************************************************
+ * Public Data
+ ****************************************************************************/
+
+/****************************************************************************
+ * Private Data
+ ****************************************************************************/
+
+/****************************************************************************
+ * Public Functions
+ ****************************************************************************/
+
+/****************************************************************************
+ * Name: execle
+ *
+ * Description:
+ * The standard 'exec' family of functions will replace the current process
+ * image with a new process image. The new image will be constructed from a
+ * regular, executable file called the new process image file. There will
+ * be no return from a successful exec, because the calling process image
+ * is overlaid by the new process image.
+ *
+ * Simplified 'execl()' and 'execv()' functions are provided by NuttX for
+ * compatibility. NuttX is a tiny embedded RTOS that does not support
+ * processes and hence the concept of overlaying a tasks process image with
+ * a new process image does not make any sense. In NuttX, these functions
+ * are wrapper functions that:
+ *
+ * 1. Call the non-standard binfmt function 'exec', and then
+ * 2. exit(0).
+ *
+ * Note the inefficiency when 'exec[l|v]()' is called in the normal, two-
+ * step process: (1) first call vfork() to create a new thread, then (2)
+ * call 'exec[l|v]()' to replace the new thread with a program from the
+ * file system. Since the new thread will be terminated by the
+ * 'exec[l|v]()' call, it really served no purpose other than to support
+ * Unix compatility.
+ *
+ * The non-standard binfmt function 'exec()' needs to have (1) a symbol
+ * table that provides the list of symbols exported by the base code, and
+ * (2) the number of symbols in that table. This information is currently
+ * provided to 'exec()' from 'exec[l|v]()' via NuttX configuration setting:
+ *
+ * CONFIG_LIBC_EXECFUNCS : Enable exec[l|v] support
+ * CONFIG_EXECFUNCS_SYMTAB_ARRAY : Symbol table name used by exec[l|v]
+ * CONFIG_EXECFUNCS_NSYMBOLS_VAR : Variable holding number of symbols in
+ * the table
+ *
+ * As a result of the above, the current implementations of 'execl()' and
+ * 'execv()' suffer from some incompatibilities that may or may not be
+ * addressed in a future version of NuttX. Other than just being an
+ * inefficient use of MCU resource, the most serious of these is that
+ * the exec'ed task will not have the same task ID as the vfork'ed
+ * function. So the parent function cannot know the ID of the exec'ed
+ * task.
+ *
+ * Input Parameters:
+ * path - The path to the program to be executed. If CONFIG_LIBC_ENVPATH
+ * is defined in the configuration, then this may be a relative path
+ * from the current working directory. Otherwise, path must be the
+ * absolute path to the program.
+ * ... - A list of the string arguments to be recevied by the
+ * program. Zero indicates the end of the list.
+ *
+ * Returned Value:
+ * This function does not return on success. On failure, it will return
+ * -1 (ERROR) and will set the 'errno' value appropriately.
+ *
+ ****************************************************************************/
+
+int execle(FAR const char *path, FAR const char *arg0, ...)
+{
+ FAR char *arg = (FAR char *)arg0;
+ FAR char **argv;
+ FAR char **envp;
+ size_t nargs;
+ va_list ap;
+ int argc;
+ int ret;
+
+ /* Count the number of arguments */
+
+ va_start(ap, arg0);
+ nargs = 0;
+
+ while (arg != NULL)
+ {
+ /* Yes.. increment the number of arguments. Here is a sanity
+ * check to prevent running away with an unterminated argv[] list.
+ * MAX_EXECL_ARGS should be sufficiently large that this never
+ * happens in normal usage.
+ */
+
+ if (++nargs > MAX_EXECL_ARGS)
+ {
+ set_errno(E2BIG);
+ va_end(ap);
+ return ERROR;
+ }
+
+ arg = va_arg(ap, FAR char *);
+ }
+
+ envp = va_arg(ap, FAR char **);
+ va_end(ap);
+
+ /* Allocate a temporary argv[] array */
+
+ argv = (FAR char **)lib_malloc((nargs + 1) * sizeof(FAR char *));
+ if (argv == NULL)
+ {
+ set_errno(ENOMEM);
+ return ERROR;
+ }
+
+ argv[0] = (FAR char *)arg0;
+
+ /* Collect the arguments into the argv[] array */
+
+ va_start(ap, arg0);
+ for (argc = 1; argc <= nargs; argc++)
+ {
+ argv[argc] = va_arg(ap, FAR char *);
+ }
+
Review Comment:
But I think the style require one blank line after }.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] pkarashchenko merged pull request #6120: Implement execle, execve, execvp, execlp and execvpe
Posted by GitBox <gi...@apache.org>.
pkarashchenko merged PR #6120:
URL: https://github.com/apache/incubator-nuttx/pull/6120
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a diff in pull request #6120: Implement execle, execve, execvp, execlp and execvpe
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on code in PR #6120:
URL: https://github.com/apache/incubator-nuttx/pull/6120#discussion_r855218316
##########
libs/libc/unistd/lib_execle.c:
##########
@@ -0,0 +1,211 @@
+/****************************************************************************
+ * libs/libc/unistd/lib_execle.c
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership. The
+ * ASF licenses this file to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
+ * License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
+ * under the License.
+ *
+ ****************************************************************************/
+
+/****************************************************************************
+ * Included Files
+ ****************************************************************************/
+
+#include <nuttx/config.h>
+
+#include <stdarg.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+
+#include "libc.h"
+
+#ifdef CONFIG_LIBC_EXECFUNCS
+
+/****************************************************************************
+ * Pre-processor Definitions
+ ****************************************************************************/
+
+/* This is an artificial limit to detect error conditions where an argv[]
+ * and envp[] list is not properly terminated.
+ */
+
+#define MAX_EXECL_ARGS 256
+#define MAX_EXECL_ENVS 256
+
+/****************************************************************************
+ * Public Functions
+ ****************************************************************************/
+
+/****************************************************************************
+ * Name: execle
+ *
+ * Description:
+ * The standard 'exec' family of functions will replace the current process
+ * image with a new process image. The new image will be constructed from a
+ * regular, executable file called the new process image file. There will
+ * be no return from a successful exec, because the calling process image
+ * is overlaid by the new process image.
+ *
+ * Simplified 'execl()' and 'execv()' functions are provided by NuttX for
+ * compatibility. NuttX is a tiny embedded RTOS that does not support
+ * processes and hence the concept of overlaying a tasks process image with
+ * a new process image does not make any sense. In NuttX, these functions
+ * are wrapper functions that:
+ *
+ * 1. Call the non-standard binfmt function 'exec', and then
+ * 2. exit(0).
+ *
+ * Note the inefficiency when 'exec[l|v]()' is called in the normal, two-
+ * step process: (1) first call vfork() to create a new thread, then (2)
+ * call 'exec[l|v]()' to replace the new thread with a program from the
+ * file system. Since the new thread will be terminated by the
+ * 'exec[l|v]()' call, it really served no purpose other than to support
+ * Unix compatility.
+ *
+ * The non-standard binfmt function 'exec()' needs to have (1) a symbol
+ * table that provides the list of symbols exported by the base code, and
+ * (2) the number of symbols in that table. This information is currently
+ * provided to 'exec()' from 'exec[l|v]()' via NuttX configuration setting:
+ *
+ * CONFIG_LIBC_EXECFUNCS : Enable exec[l|v] support
+ * CONFIG_EXECFUNCS_SYMTAB_ARRAY : Symbol table name used by exec[l|v]
+ * CONFIG_EXECFUNCS_NSYMBOLS_VAR : Variable holding number of symbols in
+ * the table
+ *
+ * As a result of the above, the current implementations of 'execl()' and
+ * 'execv()' suffer from some incompatibilities that may or may not be
+ * addressed in a future version of NuttX. Other than just being an
+ * inefficient use of MCU resource, the most serious of these is that
+ * the exec'ed task will not have the same task ID as the vfork'ed
+ * function. So the parent function cannot know the ID of the exec'ed
+ * task.
+ *
+ * Input Parameters:
+ * path - The path to the program to be executed. If CONFIG_LIBC_ENVPATH
+ * is defined in the configuration, then this may be a relative path
+ * from the current working directory. Otherwise, path must be the
+ * absolute path to the program.
+ * ... - A list of the string arguments to be recevied by the
+ * program. Zero indicates the end of the list.
+ *
+ * Returned Value:
+ * This function does not return on success. On failure, it will return
+ * -1 (ERROR) and will set the 'errno' value appropriately.
+ *
+ ****************************************************************************/
+
+int execle(FAR const char *path, FAR const char *arg0, ...)
+{
+ FAR char **argv = NULL;
+ FAR char **envp = NULL;
+ FAR char *arg = (FAR char *)arg0;
+ size_t nargs;
+ size_t nenvs;
+ va_list ap;
+ size_t i;
+ int ret;
+
+ /* Count the number of arguments and environment variables */
+
+ va_start(ap, arg0);
+ nargs = 0;
+
+ while (arg != NULL)
+ {
+ /* Yes.. increment the number of arguments. Here is a sanity
+ * check to prevent running away with an unterminated argv[] list.
+ * MAX_EXECL_ARGS should be sufficiently large that this never
+ * happens in normal usage.
+ */
+
+ if (++nargs > MAX_EXECL_ARGS)
+ {
+ set_errno(E2BIG);
+ va_end(ap);
+ return ERROR;
+ }
+
+ arg = va_arg(ap, FAR char *);
+ }
+
+ arg = va_arg(ap, FAR char *);
+ nenvs = 0;
+
+ while (arg != NULL)
+ {
+ /* Yes.. increment the number of environment variables. Here is a
+ * sanity check to prevent running away with an unterminated envp[]
+ * list. MAX_EXECL_ENVS should be sufficiently large that this never
+ * happens in normal usage.
+ */
+
+ if (++nenvs > MAX_EXECL_ENVS)
+ {
+ set_errno(E2BIG);
+ va_end(ap);
+ return ERROR;
+ }
+
+ arg = va_arg(ap, FAR char *);
+ }
+
+ va_end(ap);
+
+ /* Allocate a temporary argv[] and envp[] array */
+
+ argv = (FAR char **)lib_malloc((nargs + 1) * sizeof(FAR char *));
+ if (argv == NULL)
+ {
+ set_errno(ENOMEM);
+ return ERROR;
+ }
+
+ envp = (FAR char **)lib_malloc((nenvs + 1) * sizeof(FAR char *));
+ if (envp == NULL)
+ {
+ lib_free(argv);
+ set_errno(ENOMEM);
+ return ERROR;
+ }
+
+ /* Collect the arguments into the argv[] and envp[] array */
+
+ va_start(ap, arg0);
+
+ argv[0] = (FAR char *)arg0;
+ for (i = 1; i <= nargs; i++)
+ {
+ argv[i] = va_arg(ap, FAR char *);
+ }
+
Review Comment:
Don't need since the code call va_arg until it return NULL.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] pussuw commented on pull request #6120: Implement execle, execve, execvp, execlp and execvpe
Posted by GitBox <gi...@apache.org>.
pussuw commented on PR #6120:
URL: https://github.com/apache/incubator-nuttx/pull/6120#issuecomment-1105452504
Btw I implemented/completed an untested version of vfork for risc-v: https://github.com/tiiuae/nuttx/tree/riscv_vfork
If you wish I can make it into an upstream PR. I don't have time to test it very soon though.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on a diff in pull request #6120: Implement execle, execve, execvp, execlp and execvpe
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on code in PR #6120:
URL: https://github.com/apache/incubator-nuttx/pull/6120#discussion_r855216794
##########
libs/libc/unistd/lib_execle.c:
##########
@@ -0,0 +1,211 @@
+/****************************************************************************
+ * libs/libc/unistd/lib_execle.c
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership. The
+ * ASF licenses this file to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
+ * License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
+ * under the License.
+ *
+ ****************************************************************************/
+
+/****************************************************************************
+ * Included Files
+ ****************************************************************************/
+
+#include <nuttx/config.h>
+
+#include <stdarg.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+
+#include "libc.h"
+
+#ifdef CONFIG_LIBC_EXECFUNCS
+
+/****************************************************************************
+ * Pre-processor Definitions
+ ****************************************************************************/
+
+/* This is an artificial limit to detect error conditions where an argv[]
+ * and envp[] list is not properly terminated.
+ */
+
+#define MAX_EXECL_ARGS 256
+#define MAX_EXECL_ENVS 256
+
+/****************************************************************************
+ * Public Functions
+ ****************************************************************************/
+
+/****************************************************************************
+ * Name: execle
+ *
+ * Description:
+ * The standard 'exec' family of functions will replace the current process
+ * image with a new process image. The new image will be constructed from a
+ * regular, executable file called the new process image file. There will
+ * be no return from a successful exec, because the calling process image
+ * is overlaid by the new process image.
+ *
+ * Simplified 'execl()' and 'execv()' functions are provided by NuttX for
+ * compatibility. NuttX is a tiny embedded RTOS that does not support
+ * processes and hence the concept of overlaying a tasks process image with
+ * a new process image does not make any sense. In NuttX, these functions
+ * are wrapper functions that:
+ *
+ * 1. Call the non-standard binfmt function 'exec', and then
+ * 2. exit(0).
+ *
+ * Note the inefficiency when 'exec[l|v]()' is called in the normal, two-
+ * step process: (1) first call vfork() to create a new thread, then (2)
+ * call 'exec[l|v]()' to replace the new thread with a program from the
+ * file system. Since the new thread will be terminated by the
+ * 'exec[l|v]()' call, it really served no purpose other than to support
+ * Unix compatility.
+ *
+ * The non-standard binfmt function 'exec()' needs to have (1) a symbol
+ * table that provides the list of symbols exported by the base code, and
+ * (2) the number of symbols in that table. This information is currently
+ * provided to 'exec()' from 'exec[l|v]()' via NuttX configuration setting:
+ *
+ * CONFIG_LIBC_EXECFUNCS : Enable exec[l|v] support
+ * CONFIG_EXECFUNCS_SYMTAB_ARRAY : Symbol table name used by exec[l|v]
+ * CONFIG_EXECFUNCS_NSYMBOLS_VAR : Variable holding number of symbols in
+ * the table
+ *
+ * As a result of the above, the current implementations of 'execl()' and
+ * 'execv()' suffer from some incompatibilities that may or may not be
+ * addressed in a future version of NuttX. Other than just being an
+ * inefficient use of MCU resource, the most serious of these is that
+ * the exec'ed task will not have the same task ID as the vfork'ed
+ * function. So the parent function cannot know the ID of the exec'ed
+ * task.
+ *
+ * Input Parameters:
+ * path - The path to the program to be executed. If CONFIG_LIBC_ENVPATH
+ * is defined in the configuration, then this may be a relative path
+ * from the current working directory. Otherwise, path must be the
+ * absolute path to the program.
+ * ... - A list of the string arguments to be recevied by the
+ * program. Zero indicates the end of the list.
+ *
+ * Returned Value:
+ * This function does not return on success. On failure, it will return
+ * -1 (ERROR) and will set the 'errno' value appropriately.
+ *
+ ****************************************************************************/
+
+int execle(FAR const char *path, FAR const char *arg0, ...)
+{
+ FAR char **argv = NULL;
+ FAR char **envp = NULL;
+ FAR char *arg = (FAR char *)arg0;
+ size_t nargs;
+ size_t nenvs;
+ va_list ap;
+ size_t i;
+ int ret;
+
+ /* Count the number of arguments and environment variables */
+
+ va_start(ap, arg0);
+ nargs = 0;
+
+ while (arg != NULL)
+ {
+ /* Yes.. increment the number of arguments. Here is a sanity
+ * check to prevent running away with an unterminated argv[] list.
+ * MAX_EXECL_ARGS should be sufficiently large that this never
+ * happens in normal usage.
+ */
+
+ if (++nargs > MAX_EXECL_ARGS)
+ {
+ set_errno(E2BIG);
+ va_end(ap);
+ return ERROR;
+ }
+
+ arg = va_arg(ap, FAR char *);
+ }
+
+ arg = va_arg(ap, FAR char *);
+ nenvs = 0;
Review Comment:
Yes, you are right, I misunderstand how execle layout envp.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] pkarashchenko commented on a diff in pull request #6120: Implement execle, execve, execvp, execlp and execvpe
Posted by GitBox <gi...@apache.org>.
pkarashchenko commented on code in PR #6120:
URL: https://github.com/apache/incubator-nuttx/pull/6120#discussion_r855146957
##########
libs/libc/unistd/lib_execle.c:
##########
@@ -0,0 +1,211 @@
+/****************************************************************************
+ * libs/libc/unistd/lib_execle.c
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership. The
+ * ASF licenses this file to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
+ * License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
+ * under the License.
+ *
+ ****************************************************************************/
+
+/****************************************************************************
+ * Included Files
+ ****************************************************************************/
+
+#include <nuttx/config.h>
+
+#include <stdarg.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+
+#include "libc.h"
+
+#ifdef CONFIG_LIBC_EXECFUNCS
+
+/****************************************************************************
+ * Pre-processor Definitions
+ ****************************************************************************/
+
+/* This is an artificial limit to detect error conditions where an argv[]
+ * and envp[] list is not properly terminated.
+ */
+
+#define MAX_EXECL_ARGS 256
+#define MAX_EXECL_ENVS 256
+
+/****************************************************************************
+ * Public Functions
+ ****************************************************************************/
+
+/****************************************************************************
+ * Name: execle
+ *
+ * Description:
+ * The standard 'exec' family of functions will replace the current process
+ * image with a new process image. The new image will be constructed from a
+ * regular, executable file called the new process image file. There will
+ * be no return from a successful exec, because the calling process image
+ * is overlaid by the new process image.
+ *
+ * Simplified 'execl()' and 'execv()' functions are provided by NuttX for
+ * compatibility. NuttX is a tiny embedded RTOS that does not support
+ * processes and hence the concept of overlaying a tasks process image with
+ * a new process image does not make any sense. In NuttX, these functions
+ * are wrapper functions that:
+ *
+ * 1. Call the non-standard binfmt function 'exec', and then
+ * 2. exit(0).
+ *
+ * Note the inefficiency when 'exec[l|v]()' is called in the normal, two-
+ * step process: (1) first call vfork() to create a new thread, then (2)
+ * call 'exec[l|v]()' to replace the new thread with a program from the
+ * file system. Since the new thread will be terminated by the
+ * 'exec[l|v]()' call, it really served no purpose other than to support
+ * Unix compatility.
+ *
+ * The non-standard binfmt function 'exec()' needs to have (1) a symbol
+ * table that provides the list of symbols exported by the base code, and
+ * (2) the number of symbols in that table. This information is currently
+ * provided to 'exec()' from 'exec[l|v]()' via NuttX configuration setting:
+ *
+ * CONFIG_LIBC_EXECFUNCS : Enable exec[l|v] support
+ * CONFIG_EXECFUNCS_SYMTAB_ARRAY : Symbol table name used by exec[l|v]
+ * CONFIG_EXECFUNCS_NSYMBOLS_VAR : Variable holding number of symbols in
+ * the table
+ *
+ * As a result of the above, the current implementations of 'execl()' and
+ * 'execv()' suffer from some incompatibilities that may or may not be
+ * addressed in a future version of NuttX. Other than just being an
+ * inefficient use of MCU resource, the most serious of these is that
+ * the exec'ed task will not have the same task ID as the vfork'ed
+ * function. So the parent function cannot know the ID of the exec'ed
+ * task.
+ *
+ * Input Parameters:
+ * path - The path to the program to be executed. If CONFIG_LIBC_ENVPATH
+ * is defined in the configuration, then this may be a relative path
+ * from the current working directory. Otherwise, path must be the
+ * absolute path to the program.
+ * ... - A list of the string arguments to be recevied by the
+ * program. Zero indicates the end of the list.
+ *
+ * Returned Value:
+ * This function does not return on success. On failure, it will return
+ * -1 (ERROR) and will set the 'errno' value appropriately.
+ *
+ ****************************************************************************/
+
+int execle(FAR const char *path, FAR const char *arg0, ...)
+{
+ FAR char **argv = NULL;
+ FAR char **envp = NULL;
+ FAR char *arg = (FAR char *)arg0;
+ size_t nargs;
+ size_t nenvs;
+ va_list ap;
+ size_t i;
+ int ret;
+
+ /* Count the number of arguments and environment variables */
+
+ va_start(ap, arg0);
+ nargs = 0;
+
+ while (arg != NULL)
+ {
+ /* Yes.. increment the number of arguments. Here is a sanity
+ * check to prevent running away with an unterminated argv[] list.
+ * MAX_EXECL_ARGS should be sufficiently large that this never
+ * happens in normal usage.
+ */
+
+ if (++nargs > MAX_EXECL_ARGS)
+ {
+ set_errno(E2BIG);
+ va_end(ap);
+ return ERROR;
+ }
+
+ arg = va_arg(ap, FAR char *);
+ }
+
+ arg = va_arg(ap, FAR char *);
+ nenvs = 0;
+
+ while (arg != NULL)
+ {
+ /* Yes.. increment the number of environment variables. Here is a
+ * sanity check to prevent running away with an unterminated envp[]
+ * list. MAX_EXECL_ENVS should be sufficiently large that this never
+ * happens in normal usage.
+ */
+
+ if (++nenvs > MAX_EXECL_ENVS)
+ {
+ set_errno(E2BIG);
+ va_end(ap);
+ return ERROR;
+ }
+
+ arg = va_arg(ap, FAR char *);
Review Comment:
Why are we using `arg = va_arg(ap, FAR char *);` here and not `arg++;`?
##########
libs/libc/unistd/lib_execle.c:
##########
@@ -0,0 +1,211 @@
+/****************************************************************************
+ * libs/libc/unistd/lib_execle.c
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership. The
+ * ASF licenses this file to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
+ * License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
+ * under the License.
+ *
+ ****************************************************************************/
+
+/****************************************************************************
+ * Included Files
+ ****************************************************************************/
+
+#include <nuttx/config.h>
+
+#include <stdarg.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+
+#include "libc.h"
+
+#ifdef CONFIG_LIBC_EXECFUNCS
+
+/****************************************************************************
+ * Pre-processor Definitions
+ ****************************************************************************/
+
+/* This is an artificial limit to detect error conditions where an argv[]
+ * and envp[] list is not properly terminated.
+ */
+
+#define MAX_EXECL_ARGS 256
+#define MAX_EXECL_ENVS 256
+
+/****************************************************************************
+ * Public Functions
+ ****************************************************************************/
+
+/****************************************************************************
+ * Name: execle
+ *
+ * Description:
+ * The standard 'exec' family of functions will replace the current process
+ * image with a new process image. The new image will be constructed from a
+ * regular, executable file called the new process image file. There will
+ * be no return from a successful exec, because the calling process image
+ * is overlaid by the new process image.
+ *
+ * Simplified 'execl()' and 'execv()' functions are provided by NuttX for
+ * compatibility. NuttX is a tiny embedded RTOS that does not support
+ * processes and hence the concept of overlaying a tasks process image with
+ * a new process image does not make any sense. In NuttX, these functions
+ * are wrapper functions that:
+ *
+ * 1. Call the non-standard binfmt function 'exec', and then
+ * 2. exit(0).
+ *
+ * Note the inefficiency when 'exec[l|v]()' is called in the normal, two-
+ * step process: (1) first call vfork() to create a new thread, then (2)
+ * call 'exec[l|v]()' to replace the new thread with a program from the
+ * file system. Since the new thread will be terminated by the
+ * 'exec[l|v]()' call, it really served no purpose other than to support
+ * Unix compatility.
+ *
+ * The non-standard binfmt function 'exec()' needs to have (1) a symbol
+ * table that provides the list of symbols exported by the base code, and
+ * (2) the number of symbols in that table. This information is currently
+ * provided to 'exec()' from 'exec[l|v]()' via NuttX configuration setting:
+ *
+ * CONFIG_LIBC_EXECFUNCS : Enable exec[l|v] support
+ * CONFIG_EXECFUNCS_SYMTAB_ARRAY : Symbol table name used by exec[l|v]
+ * CONFIG_EXECFUNCS_NSYMBOLS_VAR : Variable holding number of symbols in
+ * the table
+ *
+ * As a result of the above, the current implementations of 'execl()' and
+ * 'execv()' suffer from some incompatibilities that may or may not be
+ * addressed in a future version of NuttX. Other than just being an
+ * inefficient use of MCU resource, the most serious of these is that
+ * the exec'ed task will not have the same task ID as the vfork'ed
+ * function. So the parent function cannot know the ID of the exec'ed
+ * task.
+ *
+ * Input Parameters:
+ * path - The path to the program to be executed. If CONFIG_LIBC_ENVPATH
+ * is defined in the configuration, then this may be a relative path
+ * from the current working directory. Otherwise, path must be the
+ * absolute path to the program.
+ * ... - A list of the string arguments to be recevied by the
+ * program. Zero indicates the end of the list.
+ *
+ * Returned Value:
+ * This function does not return on success. On failure, it will return
+ * -1 (ERROR) and will set the 'errno' value appropriately.
+ *
+ ****************************************************************************/
+
+int execle(FAR const char *path, FAR const char *arg0, ...)
+{
+ FAR char **argv = NULL;
+ FAR char **envp = NULL;
+ FAR char *arg = (FAR char *)arg0;
+ size_t nargs;
+ size_t nenvs;
+ va_list ap;
+ size_t i;
+ int ret;
+
+ /* Count the number of arguments and environment variables */
+
+ va_start(ap, arg0);
+ nargs = 0;
+
+ while (arg != NULL)
+ {
+ /* Yes.. increment the number of arguments. Here is a sanity
+ * check to prevent running away with an unterminated argv[] list.
+ * MAX_EXECL_ARGS should be sufficiently large that this never
+ * happens in normal usage.
+ */
+
+ if (++nargs > MAX_EXECL_ARGS)
+ {
+ set_errno(E2BIG);
+ va_end(ap);
+ return ERROR;
+ }
+
+ arg = va_arg(ap, FAR char *);
+ }
+
+ arg = va_arg(ap, FAR char *);
+ nenvs = 0;
Review Comment:
I think we should `va_end(ap);` here because `char *const envp[]` is the last argument.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] pkarashchenko commented on a diff in pull request #6120: Implement execle, execve, execvp, execlp and execvpe
Posted by GitBox <gi...@apache.org>.
pkarashchenko commented on code in PR #6120:
URL: https://github.com/apache/incubator-nuttx/pull/6120#discussion_r855149833
##########
libs/libc/unistd/lib_execle.c:
##########
@@ -0,0 +1,211 @@
+/****************************************************************************
+ * libs/libc/unistd/lib_execle.c
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership. The
+ * ASF licenses this file to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
+ * License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
+ * under the License.
+ *
+ ****************************************************************************/
+
+/****************************************************************************
+ * Included Files
+ ****************************************************************************/
+
+#include <nuttx/config.h>
+
+#include <stdarg.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+
+#include "libc.h"
+
+#ifdef CONFIG_LIBC_EXECFUNCS
+
+/****************************************************************************
+ * Pre-processor Definitions
+ ****************************************************************************/
+
+/* This is an artificial limit to detect error conditions where an argv[]
+ * and envp[] list is not properly terminated.
+ */
+
+#define MAX_EXECL_ARGS 256
+#define MAX_EXECL_ENVS 256
+
+/****************************************************************************
+ * Public Functions
+ ****************************************************************************/
+
+/****************************************************************************
+ * Name: execle
+ *
+ * Description:
+ * The standard 'exec' family of functions will replace the current process
+ * image with a new process image. The new image will be constructed from a
+ * regular, executable file called the new process image file. There will
+ * be no return from a successful exec, because the calling process image
+ * is overlaid by the new process image.
+ *
+ * Simplified 'execl()' and 'execv()' functions are provided by NuttX for
+ * compatibility. NuttX is a tiny embedded RTOS that does not support
+ * processes and hence the concept of overlaying a tasks process image with
+ * a new process image does not make any sense. In NuttX, these functions
+ * are wrapper functions that:
+ *
+ * 1. Call the non-standard binfmt function 'exec', and then
+ * 2. exit(0).
+ *
+ * Note the inefficiency when 'exec[l|v]()' is called in the normal, two-
+ * step process: (1) first call vfork() to create a new thread, then (2)
+ * call 'exec[l|v]()' to replace the new thread with a program from the
+ * file system. Since the new thread will be terminated by the
+ * 'exec[l|v]()' call, it really served no purpose other than to support
+ * Unix compatility.
+ *
+ * The non-standard binfmt function 'exec()' needs to have (1) a symbol
+ * table that provides the list of symbols exported by the base code, and
+ * (2) the number of symbols in that table. This information is currently
+ * provided to 'exec()' from 'exec[l|v]()' via NuttX configuration setting:
+ *
+ * CONFIG_LIBC_EXECFUNCS : Enable exec[l|v] support
+ * CONFIG_EXECFUNCS_SYMTAB_ARRAY : Symbol table name used by exec[l|v]
+ * CONFIG_EXECFUNCS_NSYMBOLS_VAR : Variable holding number of symbols in
+ * the table
+ *
+ * As a result of the above, the current implementations of 'execl()' and
+ * 'execv()' suffer from some incompatibilities that may or may not be
+ * addressed in a future version of NuttX. Other than just being an
+ * inefficient use of MCU resource, the most serious of these is that
+ * the exec'ed task will not have the same task ID as the vfork'ed
+ * function. So the parent function cannot know the ID of the exec'ed
+ * task.
+ *
+ * Input Parameters:
+ * path - The path to the program to be executed. If CONFIG_LIBC_ENVPATH
+ * is defined in the configuration, then this may be a relative path
+ * from the current working directory. Otherwise, path must be the
+ * absolute path to the program.
+ * ... - A list of the string arguments to be recevied by the
+ * program. Zero indicates the end of the list.
+ *
+ * Returned Value:
+ * This function does not return on success. On failure, it will return
+ * -1 (ERROR) and will set the 'errno' value appropriately.
+ *
+ ****************************************************************************/
+
+int execle(FAR const char *path, FAR const char *arg0, ...)
+{
+ FAR char **argv = NULL;
+ FAR char **envp = NULL;
+ FAR char *arg = (FAR char *)arg0;
+ size_t nargs;
+ size_t nenvs;
+ va_list ap;
+ size_t i;
+ int ret;
+
+ /* Count the number of arguments and environment variables */
+
+ va_start(ap, arg0);
+ nargs = 0;
+
+ while (arg != NULL)
+ {
+ /* Yes.. increment the number of arguments. Here is a sanity
+ * check to prevent running away with an unterminated argv[] list.
+ * MAX_EXECL_ARGS should be sufficiently large that this never
+ * happens in normal usage.
+ */
+
+ if (++nargs > MAX_EXECL_ARGS)
+ {
+ set_errno(E2BIG);
+ va_end(ap);
+ return ERROR;
+ }
+
+ arg = va_arg(ap, FAR char *);
+ }
+
+ arg = va_arg(ap, FAR char *);
+ nenvs = 0;
+
+ while (arg != NULL)
+ {
+ /* Yes.. increment the number of environment variables. Here is a
+ * sanity check to prevent running away with an unterminated envp[]
+ * list. MAX_EXECL_ENVS should be sufficiently large that this never
+ * happens in normal usage.
+ */
+
+ if (++nenvs > MAX_EXECL_ENVS)
+ {
+ set_errno(E2BIG);
+ va_end(ap);
+ return ERROR;
+ }
+
+ arg = va_arg(ap, FAR char *);
+ }
+
+ va_end(ap);
+
+ /* Allocate a temporary argv[] and envp[] array */
+
+ argv = (FAR char **)lib_malloc((nargs + 1) * sizeof(FAR char *));
+ if (argv == NULL)
+ {
+ set_errno(ENOMEM);
+ return ERROR;
+ }
+
+ envp = (FAR char **)lib_malloc((nenvs + 1) * sizeof(FAR char *));
+ if (envp == NULL)
+ {
+ lib_free(argv);
+ set_errno(ENOMEM);
+ return ERROR;
+ }
+
+ /* Collect the arguments into the argv[] and envp[] array */
+
+ va_start(ap, arg0);
+
+ argv[0] = (FAR char *)arg0;
+ for (i = 1; i <= nargs; i++)
+ {
+ argv[i] = va_arg(ap, FAR char *);
+ }
+
Review Comment:
Should we `argv[nargs] = NULL;`? Same for `envp`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on pull request #6120: Implement execle, execve, execvp, execlp and execvpe
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on PR #6120:
URL: https://github.com/apache/incubator-nuttx/pull/6120#issuecomment-1105155528
@pussuw execve is implemented here.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on pull request #6120: Implement execle, execve, execvp, execlp and execvpe
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on PR #6120:
URL: https://github.com/apache/incubator-nuttx/pull/6120#issuecomment-1105335149
@pkarashchenko this patch depends on https://github.com/apache/incubator-nuttx-apps/pull/1149, please merge together.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [incubator-nuttx] xiaoxiang781216 commented on pull request #6120: Implement execle, execve, execvp, execlp and execvpe
Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on PR #6120:
URL: https://github.com/apache/incubator-nuttx/pull/6120#issuecomment-1105481253
> @xiaoxiang781216 Btw I implemented/completed an untested version of vfork for risc-v: https://github.com/tiiuae/nuttx/tree/riscv_vfork
>
> If you wish I can make it into an upstream PR.
Sure.
> I don't have time to test it very soon though.
ostest has the test code:
https://github.com/apache/incubator-nuttx-apps/blob/master/testing/ostest/vfork.c#L47
passing ostest is enough to verify the implementation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org