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? >
