On Wed 30 Apr 2025 03:45:36 PM , Tim Hardisty wrote:
> >> I think that this system already exists and is the syslog.
>
> I cannot find anywhere to configure NuttX syslog to send output to
> stdout or stderr...I am sure it is my inexperience but not being able to
> do is in part what drove me to discuss this change. My arch/board has a
> default UART as the console output and that is what syslog stubbornly
> uses unless I add log to file (which I do have in my main app). I just
> want some friendly messages to my LCD! So see below.
There are actually two ways. One for just application, but you probably know
that (`openlog("", LOG_PERROR, LOG_USER)`). This is actual sending of the syslog
to stderr. The second is to configure system itself to send syslog output to the
system console with option CONFIG_SYSLOG_CONSOLE. This doesn't cover for example
telnet but because we are talking about bootloader it is likely that the output
you are using is the console. I would suggest you to go through the syslog
related configurations such as CONFIG_SYSLOG_DEVPATH
(`Device Drivers/System Logging`). NuttX has really significant amount of syslog
consumers (channels) and you can even register new ones
(CONFIG_SYSLOG_REGISTER). Honestly I haven't used that but still it might be an
interesting option if you want to write some monitoring LCD application that
prints syslogs only in some situation.
You might also want to modify SYSLOG_DEFAULT_MASK.
>
> >> 1. There was an earlier discussion which requested that NXboot shouldn't
> >> be
> >> dependent on syslog (to keep the size down).
> > I caught that discussion but forgot to respond to it, honestly.
> I just built my nxboot binary with and without syslog enabled - there's
> about 300 bytes difference so the size argument seems misjudged?
Are you sure that you disabled it really? As far as I can see it can't be
disabled in Kconfig. It might be forced somehow but it is "choice" in Kconfig
and I live in believe that it requires that exactly one option in choice would
be selected.
> >> 2. Syslog output is generally not seen by the user anyway - and I want
> >> to give
> >> the user comfort that things are OK (info type messages)- or not
> >> (error
> >> type messages!
> > I think that this is the primary point. You are attempting to provide user
> > with
> > nice presentation with cleanup up information while I am more concerned
> > about
> > traceability. <snip>
> > In conclusion that is why I suggested that syslog should stay but that we
> > should
> > also add callbacks to the NXBoot loader allowing info about boot process to
> > be
> > displayed in the user defined way.
>
> I have just implemented a very simple callback that is only called from
> <copy_partition> right now, as that is what takes forever for me. It
> just handles the "." using my in-progress "nxboot_report_info". To make
> it sensible, I also added string constants in the calls to
> <validate_image> to allow printing of "what" was being validated
> (primary/secondary/recovery/etc). But that means changes throughout the
> code which is not necessarily a good plan.
>
> If we want to call the function wherever it is appropriate, not just for
> <copy_partition>, it really does need more information - the
> what/why/where the callback is being invoked.
>
> So...does this suggest the callback function should have a "reason code"
> perhaps? Allowing the default callback function in nxboot_main -
> dprintf, essentially - to produce meaningful default feedback messages
> based on the reason code, and only when enabled, that can readily be
> unbolted and replaced by a custom out-of-tree derivative of nxboot_main
> using nxboot as a library as you suggest?
>
> Have I "got it"?
I think that you have a correct idea in the sense that some additional info in
the callback should be provided. The exact location and content should probably
be collaboration with Michal. I am not sure what are all the possible
significant time consuming operations in the code. I think that callback should
be right in front of all of the long operations and in case of data copy
operation (the callback you now have) it should signal also progress for sure.You should not probably add any strings for that callback to the library. Instead use enums and ints or even floats and document them. That provides easy way to even localize the user facing boot process side. It would be way harder if you would have to compare strings.
signature.asc
Description: PGP signature
