Yes, lib_outstream_s is a better candidate. BTW, the buffer may always need before the hardware transport driver finish the initialization otherwise the important initial activity will lost.
> -----Original Message----- > From: Gregory Nutt <spudan...@gmail.com> > Sent: Thursday, July 2, 2020 10:05 AM > To: dev@nuttx.apache.org > Subject: Re: NXView > > > > It's a reasonable function partitioning. How about we define an interface > > like syslog_channel_s between note and driver? So we can > plug in the different transport like syslog. > > The correct way to redirect streams within the OS is to use NuttX stream > interfaces. Forget about systlog channels. That is not > relevant here. > > NuttX stream interfaces are defined in include/nuttx/streams.h. you would > need to create an oustream and "inherits" from struct > lib_outstream_s. There are several examples of custom outstreams in that > header file, but you will create a custom one for the ram > log. You will need one that manages the circular ram buffer and whatever > other special properties. Please follow the examples in that > header file. > > This is the universal way of redirecting byte streams within the OS. there > are many examples since they are used in all cases. A good > example is libs/libc/stdio/lib_libvsprintf.c. That implements all of the > family of printf-like functions including printf, fprintf, dprintf, > sprintf, snprintf, asprintf, etc. It uses an outstream to send the formatted > data to the correct recipient: > > int lib_vsprintf(FAR struct lib_outstream_s *stream, > FAR const IPTR char *fmt, va_list ap) > > Functions like printf, fprintf, dprintf, sprintf, snprintf, asprintf, etc > then just setup the outstream instance and call lib_vsprintf(). > > The architecture should consist of a encoder that converts the sched_note > call data to a byte stream by serializing/marshaling a > packed data structure. It should then use a global outstream to send the > data. Each "client" of the encoder should provide the global > outstream and handle the data sent to "client" byte-by-byte. The syslog is > only one of many possible "clients" for the encoded data > so you should not focus on that. > > The byte-by-byte transfer may be too inefficient. You could come up with a > similar interface that transfers multiple bytes of data at a > time (the full packed data in one transfer) -- like write() vs fputc(). That > will probably be necessary for performance reasons. > >
