Taking a closer look at the RFC examples, it appears it's very plaintext-based, and messages could actually be constructed through the existing sprintf implementation with some modifications.
The main drawback would be that if a user enabled both RFC5424 compatible messages and left out many of the fields (timestamp, PID, etc), the output message would include a lot of "NIL" fields. Not sure there's a way around that though, and if a user wants RFC5424 compatible output they likely don't overly care about the "prettiness" of the output to be read by humans. I'll play around with modifying this a little and open a draft PR for RFC5424 lots to get some early review. Matteo On Sat, Jun 7, 2025, 7:51 PM Matteo Golin <matteo.go...@gmail.com> wrote: > Mainly my concern is that the current implementation of syslog (from my > understanding reading the NuttX source code) is to `sprintf` the logs into > the syslog stream that was configured (gleaned from `nx_vsyslog` in > drivers/syslog/vslog.c). This has always worked since logs have only really > been consumed through some kind of character device/as characters printed > to a file or console. > > What I'm thinking would facilitate implementing RFC5424 would be to have > the syslog call fill out some kind of `struct` of the RFC defined syslog > message, and put that in the stream. However, this would require a large > change to NuttX's current syslog implementation while really only > benefitting the implementation of sinks that need the RFC formatted > message. I don't really want to do that since I think it would be prone to > bugs, and `syslog` is very important and touches basically every platform. > > Maybe if there was some way to identify a stream as a binary stream > (RFC5424 structs in that stream) or character stream (current syslog > behaviour) and choose how to process syslog calls? I will probably spend > some more time reading into how this is implemented on other systems, like > what intermediate storage type is being used for logs or how they are being > turned into these RFC compatible messages for network transmission. > > The central collection that passes on further to other sinks is a good > idea, but I think it would be difficult to implement. The devices I was > thinking of using this on are RPi Pico Ws, so I'd like to minimize extra > processing and also avoid losing log collection at boot time if possible. > This is why drawing from ramlog was a very smart suggestion. Something like > ramlog but storing non-character logs would be helpful in my mind. > > Matteo > > On Sat, Jun 7, 2025 at 7:08 PM Gregory Nutt <spudan...@gmail.com> wrote: > >> Get BlueMail for Android <https://bluemail.me> >> On Jun 7, 2025, at 4:31 PM, Tomek CEDRO <to...@cedro.info> wrote: >> > >> > Looks like having a central point to gather the information and >> > construct them according to RFC then passing these to "sinks" that >> > does the further processing i.e. output to text stream and/or output >> > to network? You could then just enable/disable or add more sinks when >> > necessary? >> > >> > >> A couple of of complexities to considerL >> >> Any central point would have to a task that supports an IPC. In the KERNEL >> BUILD this would have to be a process. >> tasks (or processes) cannot be started until the very conclusion of power >> up initialization. It would not be possible to collect syslog data until >> then. That would prohibit any syslog output during initialization when it >> is most needed. >> >> Perhaps a clever design could overcome those issues? >> >
