RFC: Logging of version info?

[Ulrich Teichert]

Hi,

I have a requirement to log the version information during startup on swupdate, as well

as logging the version during install. Setting the log level to TRACE would cover that,

as there are logging statements in core/artifacts_versions.c and parser/parser.c already

which would report this information. Well, as you might guess, this leads to the

complaint that this causes way too much logging output :-/

My proposal to get out of this conflicting requirements would be to submit a patch which

would introduce a new Kconfig entry, say CONFIG_REPORT_VERSIONS which is off by

default, but when switched on would change the reporting level of the two log messages

mentioned above. The different log level for them could either be INFO or an additional

log level EVENT, added between WARN and INFO (which I would prefer - the startup

messages which are logged on stdout could be switched over to log level EVENT in

that case as well, but that's probably a different discussion).

Would a patch which adds something like that be of interest for the community? Or is

that something which I have to maintain separately?

TIA,

Ulrich Teichert

[Stefano Babic]

Hi Ulrich,

On 7/27/26 09:52, 'Ulrich Teichert' via swupdate wrote:
> Hi,
>
> I have a requirement to log the version information during startup on
> swupdate, as well

SWUpdate's version or versions of the artifacts ?

> as logging the version during install. Setting the log level to TRACE
> would cover that,
> as there are logging statements in core/artifacts_versions.c and parser/
> parser.c already
> which would report this information. Well, as you might guess, this
> leads to the
> complaint that this causes way too much logging output :-/

Oh, strange ! :-D

>
> My proposal to get out of this conflicting requirements would be to
> submit a patch which
> would introduce a new Kconfig entry, say CONFIG_REPORT_VERSIONS which is
> off by
> default, but when switched on would change the reporting level of the
> two log messages
> mentioned above. The different log level for them could either be INFO
> or an additional
> log level EVENT, added between WARN and INFO (which I would prefer - the
> startup
> messages which are logged on stdout could be switched over to log level
> EVENT in
> that case as well, but that's probably a different discussion).
>
> Would a patch which adds something like that be of interest for the
> community? Or is
> that something which I have to maintain separately?

Which logs we are talking about ? I do not know if makes sense to
introduce another Kconfig, and if it won't become very verbose, we can
simply change the logs you want to have from TRACE to INFO.

But if they are becoming a lot, such as a patch with
CONFIG_REPORT_VERSIONS is also ok.

Best regards,
Stefano Babic

>
> TIA,
> Ulrich Teichert
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> swupdate/44916c0a-2f74-4b65-a913-00fdaa49e25en%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/44916c0a-2f74-4b65-
> a913-00fdaa49e25en%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
_______________________________________________________________________
Nabla Software Engineering GmbH
Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596
Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
E-Mail: sba...@nabladev.com

[Ulrich Teichert]

Hi Stefano,

>On 7/27/26 09:52, 'Ulrich Teichert' via swupdate wrote:
>> Hi,
>>
>> I have a requirement to log the version information during startup on
>> swupdate, as well

>SWUpdate's version or versions of the artifacts ?

The artifact versions - both the installed and the to-be-installed.

The statements in question are (line numbers from current HEAD of master):

in core/artifacts_versions.c, line 70-73:

TRACE("Installed %s: Version %s",
swcomp->name,
swcomp->version);

which is logging the versions read from sw_versions, and in parser/parser.c, line 185:

TRACE("Version %s", swcfg->version);

which is logging the versions contained in the freshly parsed SWU container.

>But if they are becoming a lot, such as a patch with
>CONFIG_REPORT_VERSIONS is also ok.

No, only two of them and logging these with level INFO would be appropiate,
I think. But I have the feeling that logging with INFO would still produce too
much output for my use case/requirements/users...

I wonder what log level settings others are using in a production setup? Currently,
we are using WARN, which was fine until this requirement came along...

CU,
Uli

[Stefano Babic]

Hi Ulrich,

On 7/28/26 08:33, Ulrich Teichert wrote:
> Hi Stefano,
>
>> On 7/27/26 09:52, 'Ulrich Teichert' via swupdate wrote:
>>> Hi,
>>>
>>> I have a requirement to log the version information during startup on
>>> swupdate, as well
>
>> SWUpdate's version or versions of the artifacts ?
>
> The artifact versions - both the installed and the to-be-installed.

They are not always printed. The update is atomic, that means the
identification of the software is in the global "version" on the top of
sw-description. Artifact versions are available only if added explicitly
to the sw-description file.

We can switch to INFO.

>
> which is logging the versions read from sw_versions, and in parser/parser.c, line 185:
>
> TRACE("Version %s", swcfg->version);

And yes, this is the global version, that means the version that
identifies the whole update / SWU / firmware.

"version" and "description" can be switched to INFO.

Anyway, you are logging the versions inside sw-version (if any) and the
global version, so two different things.

>
> which is logging the versions contained in the freshly parsed SWU container.
>
>> But if they are becoming a lot, such as a patch with
>> CONFIG_REPORT_VERSIONS is also ok.
>
> No, only two of them and logging these with level INFO would be appropiate,
> I think.

It is ok for me to switch them to INFO.

> But I have the feeling that logging with INFO would still produce too
> much output for my use case/requirements/users...

They cannot have everything, tell them, life is hard...

>
> I wonder what log level settings others are using in a production setup? Currently,
> we are using WARN, which was fine until this requirement came along...

It is pretty questionable - I have projects with high level because the
update at the end does not happen frequently, and even if it is verbose,
it doesn't matter. Customer's choice.

Other users want to reduce at minimum, and then WARN or even ERROR is used.

Best regards,
Stefano

[Ulrich Teichert]

Hi Stefano,

>> No, only two of them and logging these with level INFO would be appropiate,
>> I think.

>It is ok for me to switch them to INFO.

Right, I've sent a separate patch to change the logging level of these two statements,

CU,
Uli