Thanks for detailed comment. I'll study streams.h to apply it for the note data interface.
> -----Original Message----- > From: Gregory Nutt <spudan...@gmail.com> > Sent: Thursday, July 2, 2020 11: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. > >
