libc/unistd: move NAME_MAX/LINE_MAX/PATH_MAX define to unistd

[anchao]

Summary

1. libc/unistd: move NAME_MAX/LINE_MAX/PATH_MAX define to unistd

These options are unistd-specific and should not be filesystem dependent,
and also not suitable for define in the sched directory.

Signed-off-by: chao an anchao.archer@bytedance.com

2. libs/libc: rename LIBC_OPEN_MAX to OPEN_MAX

Signed-off-by: chao an anchao.archer@bytedance.com

3. Documentation: clean up of CONFIG_NSH_LINELEN define

Signed-off-by: chao an anchao.archer@bytedance.com

Impact

N/A

Testing

ci-check

[nuttxpr]

[Experimental Bot, please feedback here]

This PR appears to mostly meet the requirements, but is missing some key information.

What's good:

• Summary provides a decent overview of the what. It clearly lists the three changes being made.
• Testing mentions ci-check, implying some automated testing. While not ideal, it's better than no testing information.

What's missing/needs improvement:

• Summary lacks the why. It states what is being moved/renamed, but not why these changes are necessary. What problem do they solve? What's the benefit? For example, why are NAME_MAX, etc. "unistd-specific and should not be filesystem dependent"? What issues did this dependency cause? Similarly, why rename LIBC_OPEN_MAX? Why clean up CONFIG_NSH_LINELEN?
• Impact is too dismissive. "N/A" is almost never true. Even seemingly small changes can have impacts. Consider:
  • Impact on user: Will any applications relying on the old names/locations break? Even if the answer is no, explain why.
  • Impact on build: Are there any conditional compilation changes? Again, even if no, explain why.
  • Impact on documentation: This is explicitly mentioned as changed, so the impact cannot be N/A. Describe what documentation was changed.
  • Impact on compatibility: Moving definitions can introduce subtle compatibility issues. Justify why there are none.
• Testing is insufficient. ci-check tells us nothing specific. What targets were tested? What tests were run? What were the results of those tests? Providing "before" and "after" logs, even if they are identical, demonstrates due diligence. If the logs are voluminous, consider linking to a CI run instead of pasting them directly. At a minimum, specify the host OS, compiler, target architecture, and board configuration used for testing.

In short: The PR needs to expand on the why for each change and provide more concrete details regarding the impact and testing performed. Simply stating "N/A" or "ci-check" is not sufficient for a thorough review.

[yamt]

and also not suitable for use in the sched directory.

why not?
they are kernel characteristics as far as i know.

[anchao]

why not? they are kernel characteristics as far as i know.

Let me clarify further, should be"define", not "use"

and also not suitable for define in the sched directory.

[yamt]

why not? they are kernel characteristics as far as i know.

Let me clarify further, should be"define", not "use"

and also not suitable for define in the sched directory.

well, to me, it seems more natural to define kernel constants in kernel than libc.

[anchao]

why not? they are kernel characteristics as far as i know.

Let me clarify further, should be"define", not "use"

and also not suitable for define in the sched directory.

well, to me, it seems more natural to define kernel constants in kernel than libc.

actually no one in the sched directory is using these definitions

[yamt]

why not? they are kernel characteristics as far as i know.

Let me clarify further, should be"define", not "use"

and also not suitable for define in the sched directory.

well, to me, it seems more natural to define kernel constants in kernel than libc.

actually no one in the sched directory is using these definitions

if you move them to fs, it might make sense.
but why libc?

[anchao]

why not? they are kernel characteristics as far as i know.

Let me clarify further, should be"define", not "use"

and also not suitable for define in the sched directory.

well, to me, it seems more natural to define kernel constants in kernel than libc.

actually no one in the sched directory is using these definitions

if you move them to fs, it might make sense. but why libc?

Most of the limit macros are Unix-specific and are more likely to be defined in libc unistd

https://pubs.opengroup.org/onlinepubs/009696799/functions/fpathconf.html

[yamt]

why not? they are kernel characteristics as far as i know.

Let me clarify further, should be"define", not "use"

and also not suitable for define in the sched directory.

well, to me, it seems more natural to define kernel constants in kernel than libc.

actually no one in the sched directory is using these definitions

if you move them to fs, it might make sense. but why libc?

Most of the limit macros are Unix-specific and are more likely to be defined in libc unistd

https://pubs.opengroup.org/onlinepubs/009696799/functions/fpathconf.html

sorry, i don't understand your logic.
i expect these constants (eg. PATH_MAX) are defined in a userland header (eg. limits.h) to match the kernel counterpart. (eg. CONFIG_PATH_MAX)
defining them in the opposite way sounds a bit awkward to me.

[anchao]

why not? they are kernel characteristics as far as i know.

Let me clarify further, should be"define", not "use"

and also not suitable for define in the sched directory.

well, to me, it seems more natural to define kernel constants in kernel than libc.

actually no one in the sched directory is using these definitions

if you move them to fs, it might make sense. but why libc?

Most of the limit macros are Unix-specific and are more likely to be defined in libc unistd
https://pubs.opengroup.org/onlinepubs/009696799/functions/fpathconf.html

sorry, i don't understand your logic. i expect these constants (eg. PATH_MAX) are defined in a userland header (eg. limits.h) to match the kernel counterpart. (eg. CONFIG_PATH_MAX) defining them in the opposite way sounds a bit awkward to me.

I just need a more suitable place to define these macros, not sched. unistd is the best choice I see. If you think there is a better place, please suggest instead of constantly saying no. What I need is the method, not your challenge.

[yamt]

why not? they are kernel characteristics as far as i know.

Let me clarify further, should be"define", not "use"

and also not suitable for define in the sched directory.

well, to me, it seems more natural to define kernel constants in kernel than libc.

actually no one in the sched directory is using these definitions

if you move them to fs, it might make sense. but why libc?

Most of the limit macros are Unix-specific and are more likely to be defined in libc unistd
https://pubs.opengroup.org/onlinepubs/009696799/functions/fpathconf.html

sorry, i don't understand your logic. i expect these constants (eg. PATH_MAX) are defined in a userland header (eg. limits.h) to match the kernel counterpart. (eg. CONFIG_PATH_MAX) defining them in the opposite way sounds a bit awkward to me.

I just need a more suitable place to define these macros, not sched. unistd is the best choice I see. If you think there is a better place, please suggest instead of constantly saying no. What I need is the method, not your challenge.

i feel sched is a more natural place for them than libc.
if you are unhappy with sched, how about fs/Kconfig?

[anchao]

i feel sched is a more natural place for them than libc. if you are unhappy with sched, how about fs/Kconfig?

Sure, except for the sched directory, libc/fs is more reasonable. I think the reason why libc is better is that the limit value is frequently used in user space, so libc may be better.