lib/os: fix ll format specifier in z_prf

[pabigot]

Transfer the missed Kconfig that controls support for %ll? format specifier in z_prf out of minimal libc and into the lib/os Kconfig area. Give it a better name, since it's not in minimal libc anymore.

Also add just enough of a test case to verify this works.

Fixes #29165

[pabigot]

@sdalu

[andrewboie]

I must have missed the patch that moved z_prf out of minimal libc.
Couldn't we have worked around this in the shell instead?? Or used printk()?? Anything but this terrible arrangement.
Now if you use a third-party C library, your code could pull in printk(), z_prf() and whatever is in that C library for printf. not good.
I really think you should reconsider all of this.

[sdalu]

that's fixing my problem.
(i've no idea on what is / would be the best way of fixing it)

[pabigot]

Couldn't we have worked around this in the shell instead?? Or used printk()??

@andrewboie Not really. The requirements and rationale are in #27655: only z_prf() and z_vprintk() have the interface necessary, and of those z_prf() is far more powerful.

This only affects things that explicitly use z_prf(), which is the shell, the log subsystem, and for minimal libc the *printf functions. It should have no impact on using third-party C code.

[andrewboie]

The shell requires a *printf function that produces its output by calling a function like putchar(3c) to output one character at a time. This eliminates dynamic or static allocation of buffers large enough to hold arbitrary messages.

At any point did anyone consider that maybe we should change the shell code to not have this inflexible requirement such that any C library could be used, instead of us now having to support and maintain TWO printf implementations in the core kernel itself?

[pabigot]

From #27655 I don't see how to change the shell code: the shell requires generating output to arbitrary destinations, and there is no way to do that using the C standard library. z_prf() or something just like it is needed, v_printk() is "just like it" but is too limited.

If we want to eliminate duplicate code, we could convert v_printk() to be a wrapper around z_prf().

In any case such discussion is not directly related to this PR which fixes a bug.

[andrewboie]

the shell requires generating output to arbitrary destinations

So add some buffering or re-work the code so this isn't a requirement?
Maintaining two different printf implementations in the Zephyr codebase is not the way to go.

If we want to eliminate duplicate code, we could convert v_printk() to be a wrapper around z_prf().

Not happening. z_prf uses far more stack space.

You should really think about:

1. What could be changed in the shell to allow C standard library functions to be used
2. Do you REALLY need the extra formatting that z_prf supports and vprintk() doesn't have

In other words, start over from first principles. IMO the other patch should be reverted. This is a mess.

[andrewboie]

I will provide you with a path forward that I would find acceptable:
Remove all dependencies on z_prf.
Implement this in terms of printk() family of functions instead.
If we must have float, find a way to add a Kconfig or something that adds optional float support to printk, in a way that leaves footprint and stack usage unchanged (give or take a few bytes) with the config turned off.
But depending on z_prf this must stop.

[pabigot]

Added to dev-review for tomorrow @galak.

I have some sympathy with @andrewboie's concerns, but do not have time or interest in taking on other solution paths. My acceptable paths are (1) take this fix, (2) revert #27655 breaking shell display of floating point depending on which libc the app happens to link with, or (3) close this unmerged leaving the 64-bit shell printing broken.

Changes like re-architecting the shell or trying to make vprintk() support both kernel and application needs are not in my wheelhouse and somebody else can pick them up after one of the above choices is taken. If no decision is reached the default path would be status quo (option 3).

[andrewboie]

(2) revert #27655 breaking shell display of floating point depending on which libc the app happens to link with,

I already sent a PR that does exactly this #29203

Added to dev-review for tomorrow @galak.

What is the point? @galak does not own lib/os. That is owned by me and Andy. This isn't up for discussion.

somebody else can pick them up

So be it.

[pabigot]

I already sent a PR that does exactly this #29203

OK, didn't see that anywhere.

Added to dev-review for tomorrow @galak.

What is the point? @galak does not own lib/os. That is owned by me and Andy. This isn't up for discussion.

We had been using dev-review to get a wider perspective, but yes, I do agree that maintainers get to make decisions in the face of a lack of consensus. So we'll go with option 2.

[nashif]

What is the point? @galak does not own lib/os. That is owned by me and Andy. This isn't up for discussion.

We had been using dev-review to get a wider perspective, but yes, I do agree that maintainers get to make decisions in the face of a lack of consensus. So we'll go with option 2.

We should try as much as possible to close on such issues here and in related PRs and issues. Not everyone can join meetings and we should not use meetings for things that can be closed on GH.

What is the point? @galak does not own lib/os.

@galak is just the facilitator of the meeting, do not shoot the messenger :-)