rename lib_pathbuffer to lib_tempbuffer

[Zhangshoukui]

Summary

rename lib_pathbuffer to lib_tempbuffer

Impact

None

Testing

./tools/configure.sh -l sim:nsh
make -j7

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR does not fully meet the NuttX requirements. While it provides some information, it lacks crucial details.

Here's what's missing:

• Summary: It states what is being changed (renaming lib_pathbuffer to lib_tempbuffer), but not why. What problem does this renaming solve? What was the motivation for this change? How does the renaming work (is it a simple rename, or are there code changes associated with it)? Are there related NuttX issues?
• Impact: Simply stating "None" is insufficient. Even a seemingly simple rename can have unforeseen impacts. The PR needs to explicitly address each impact point with justification. For example, why is there no impact on documentation? If there truly is no impact, explicitly state "NO" for each item.
• Testing: While it mentions build commands, it provides no actual testing logs. Showing the output before and after the change is crucial to demonstrate that the change works as intended and doesn't introduce regressions. What functionality was tested? What were the expected results? Also, specifying only the build host is insufficient; the target architecture (e.g., sim:nsh) should be listed under Target(s) with details about the board and configuration. Furthermore, mentioning the build host operating system, CPU architecture, and compiler version is essential.

In short, the PR needs to be significantly more detailed to meet the NuttX requirements. It needs to explain the rationale behind the change, justify the claimed lack of impact, and provide concrete evidence of testing.

[acassis]

@Zhangshoukui I think we need to simplify the LINELEN / LINEMAX instead of creating a new one, currently there are many configs to that:

CONFIG_SYSTEM_CLE_CMD_HISTORY_LINELEN
CONFIG_SYSTEM_CLE_CMD_HISTORY_LEN
CONFIG_NSH_LINELEN
CONFIG_PROCFS_LINELEN
CONFIG_HELP_LINELEN

Having a LINELEN for each application could be more flexible, but it is also a lot a code duplication. It should be nice to have a single LINE_MAX to be the standard LINELEN

[Zhangshoukui]

@Zhangshoukui I think we need to simplify the LINELEN / LINEMAX instead of creating a new one, currently there are many configs to that:

CONFIG_SYSTEM_CLE_CMD_HISTORY_LINELEN CONFIG_SYSTEM_CLE_CMD_HISTORY_LEN CONFIG_NSH_LINELEN CONFIG_PROCFS_LINELEN CONFIG_HELP_LINELEN

Having a LINELEN for each application could be more flexible, but it is also a lot a code duplication. It should be nice to have a single LINE_MAX to be the standard LINELEN

@acassis Yes, the next step is to optimize and remove the above configuration to use LINE_MAX.
remove this:
config SYSTEM_CLE_CMD_HISTORY_LEN
config SYSTEM_CLE_CMD_HISTORY_LINELEN
CONFIG_NSH_LINELEN
HELP_LINELEN
PROCFS_LINELEN
cc @anchao

[anchao]

@Zhangshoukui I think we need to simplify the LINELEN / LINEMAX instead of creating a new one, currently there are many configs to that:
CONFIG_SYSTEM_CLE_CMD_HISTORY_LINELEN CONFIG_SYSTEM_CLE_CMD_HISTORY_LEN CONFIG_NSH_LINELEN CONFIG_PROCFS_LINELEN CONFIG_HELP_LINELEN
Having a LINELEN for each application could be more flexible, but it is also a lot a code duplication. It should be nice to have a single LINE_MAX to be the standard LINELEN

@acassis Yes, the next step is to optimize and remove the above configuration to use LINE_MAX. remove this: config SYSTEM_CLE_CMD_HISTORY_LEN config SYSTEM_CLE_CMD_HISTORY_LINELEN CONFIG_NSH_LINELEN HELP_LINELEN PROCFS_LINELEN cc @anchao

I agree with the line buffer change, but I have reservations about reusing lib_get_tempbuffer(). could the first 2 patches be submitted as a separate PR?

[Zhangshoukui]

config SYSTEM_CLE_CMD_HISTORY_LEN
config SYSTEM_CLE_CMD_HISTORY_LINELEN
CONFIG_NSH_LINELEN
HELP_LINELEN
PROCFS_LINELEN

#15344 I've separated the disputed submissions.

But I had one problem I had to solve:

1. How can we optimize the stack and avoid memory fragmentation as much as possible?

cc @anchao @acassis @yamt @xiaoxiang781216

[anchao]

We need to analyze these problems case by case. Do you have the deepest stack consumption print?maybe backtrace or source code?

[Zhangshoukui]

./netutils/rexec/rexec.c: char cmd[CONFIG_NSH_LINELEN];
./nshlib/nsh_timcmds.c: char buffer[CONFIG_NSH_LINELEN];
./nshlib/nsh_timcmds.c: strlcpy(buffer, cmd, CONFIG_NSH_LINELEN);
./nshlib/nsh_parse.c: char sh_arg2[CONFIG_NSH_LINELEN];
./nshlib/nsh_parse.c: char tracebuf[CONFIG_NSH_LINELEN + 1];
./nshlib/nsh_parse.c: char sh_arg2[CONFIG_NSH_LINELEN];
./nshlib/nsh.h:#ifndef CONFIG_NSH_LINELEN
./nshlib/nsh.h:# define CONFIG_NSH_LINELEN 80
./nshlib/Kconfig:config NSH_LINELEN
./nshlib/nsh_telnetlogin.c: if (readline_fd(pstate->cn_line, CONFIG_NSH_LINELEN,
./nshlib/nsh_telnetlogin.c: ret = readline_fd(pstate->cn_line, CONFIG_NSH_LINELEN,
./nshlib/nsh_session.c: ret = cle_fd(pstate->cn_line, nsh_prompt(), CONFIG_NSH_LINELEN,
./nshlib/nsh_session.c: ret = readline_fd(pstate->cn_line, CONFIG_NSH_LINELEN,
./nshlib/nsh_login.c: ret = readline_fd(pstate->cn_line, CONFIG_NSH_LINELEN,
./nshlib/nsh_login.c: ret = readline_fd(pstate->cn_line, CONFIG_NSH_LINELEN,
./nshlib/nsh_console.h: char cn_line[CONFIG_NSH_LINELEN];
./nshlib/nsh_script.c: ret = readline_fd(buffer, CONFIG_NSH_LINELEN, vtbl->np.np_fd, -1);
./nshlib/nsh_mmcmds.c: char arg[CONFIG_NSH_LINELEN] = "";
./nshlib/nsh_mmcmds.c: strlcpy(arg, "used", CONFIG_NSH_LINELEN);
./nshlib/nsh_mmcmds.c: strlcat(arg, argv[i], CONFIG_NSH_LINELEN);
./nshlib/nsh_mmcmds.c: strlcat(arg, " ", CONFIG_NSH_LINELEN);
./examples/lp503x/lp503x_main.c: char buffer[CONFIG_NSH_LINELEN];
./system/nxlooper/nxlooper_main.c: char buffer[CONFIG_NSH_LINELEN];
./system/readline/readline.c:#ifndef CONFIG_NSH_LINELEN
./system/readline/readline.c:# define CONFIG_NSH_LINELEN 80
./system/readline/readline.c: FAR char *line = malloc(CONFIG_NSH_LINELEN);
./system/readline/readline.c: if (readline_fd(line, CONFIG_NSH_LINELEN,
./system/nxrecorder/nxrecorder_main.c: char buffer[CONFIG_NSH_LINELEN];
./system/taskset/taskset.c: char command[CONFIG_NSH_LINELEN];
./system/taskset/taskset.c: * NOTE: total length does not exceed CONFIG_NSH_LINELEN
./system/nxcamera/nxcamera_main.c: char buffer[CONFIG_NSH_LINELEN];
./system/trace/trace.c: char command[CONFIG_NSH_LINELEN];
./system/nxplayer/nxplayer_main.c: char buffer[CONFIG_NSH_LINELEN];

The main thing is that when CONFIG_NSH_LINELEN is configured to 256, the 2k stack is not enough for some scenarios, such as popen to invoke a simple command on a real device not sim

My plan was to remove：
config SYSTEM_CLE_CMD_HISTORY_LEN
config SYSTEM_CLE_CMD_HISTORY_LINELEN
CONFIG_NSH_LINELEN
HELP_LINELEN
PROCFS_LINELEN
and use LINE_MAX and lib_get_tempbuffer To save stack consumption and avoid memory fragmentation @anchao

[xiaoxiang781216]

please rebase the patch to resolve the conflict, @Zhangshoukui

[anchao]

My plan was to remove： config SYSTEM_CLE_CMD_HISTORY_LEN config SYSTEM_CLE_CMD_HISTORY_LINELEN CONFIG_NSH_LINELEN HELP_LINELEN PROCFS_LINELEN and use LINE_MAX and lib_get_tempbuffer To save stack consumption and avoid memory fragmentation @anchao

apache/nuttx-apps#2918

[JianyuWang0623]

@Zhangshoukui Could you cherry pick #15326 (this PR) and #15344 to openvela please?