Hi Heinrich,
On Tue, 22 Sep 2020 at 16:03, Simon Glass <s...@chromium.org> wrote:
>
> Hi Heinrich,
>
> On Tue, 22 Sep 2020 at 13:10, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
> >
> > On 9/22/20 8:48 PM, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Thu, 17 Sep 2020 at 06:19, Heinrich Schuchardt <xypron.g...@gmx.de>
> > > wrote:
> > >>
> > >> Some drivers use macro pr_cont() for continuing a message sent via
> > >> printk.
> > >> Hence if we want to convert printk messaging to using the logging system,
> > >> we must support continuation of log messages too.
> > >>
> > >> As pr_cont() does not provide a message level we need a means of
> > >> remembering the last log level.
> > >>
> > >> With the patch a pseudo log level LOGL_CONT as well as a pseudo log
> > >> category LOGC_CONT are introduced. Using these results in the application
> > >> of the same log level and category as in the previous log message.
> > >>
> > >> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
> > >> ---
> > >> common/log.c | 23 ++++++++++++++++++-----
> > >> doc/develop/logging.rst | 6 ++++++
> > >> include/log.h | 2 ++
> > >> 3 files changed, 26 insertions(+), 5 deletions(-)
> > >>
> > >> diff --git a/common/log.c b/common/log.c
> > >> index 9a5f100da3..bafc09f263 100644
> > >> --- a/common/log.c
> > >> +++ b/common/log.c
> > >> @@ -183,10 +183,12 @@ static bool log_passes_filters(struct log_device
> > >> *ldev, struct log_rec *rec)
> > >> * log_dispatch() - Send a log record to all log devices for processing
> > >> *
> > >> * The log record is sent to each log device in turn, skipping those
> > >> which have
> > >> - * filters which block the record
> > >> + * filters which block the record.
> > >> *
> > >> - * @rec: Log record to dispatch
> > >> - * @return 0 (meaning success)
> > >> + * All log messages created while processing log record @rec are
> > >> ignored.
> > >> + *
> > >> + * @rec: log record to dispatch
> > >> + * Return: 0 msg sent, 1 msg not sent while already dispatching
> > >> another msg
> > >> */
> > >> static int log_dispatch(struct log_rec *rec)
> > >> {
> > >> @@ -199,7 +201,7 @@ static int log_dispatch(struct log_rec *rec)
> > >> * as this might result in infinite recursion.
> > >> */
> > >> if (processing_msg)
> > >> - return 0;
> > >> + return 1;
> > >>
> > >> /* Emit message */
> > >> processing_msg = 1;
> > >> @@ -214,10 +216,18 @@ static int log_dispatch(struct log_rec *rec)
> > >> int _log(enum log_category_t cat, enum log_level_t level, const char
> > >> *file,
> > >> int line, const char *func, const char *fmt, ...)
> > >> {
> > >> + static enum log_category_t logc_prev = LOGC_NONE;
> > >> + static enum log_level_t logl_prev = LOGL_INFO;
> > >
> > > I don't think we can use static variables in logging. Perhaps we can
> > > use gobal_data?
> >
> > Are you worried about relocation?
>
> Yes, and SPL.
>
> >
> > The initialization of the global data fields should be done in
> > log_init() before gd->flags |= GD_FLG_LOG_READY; I assume.
>
> Yes.
>
> >
> > Is the rest ok for you?
>
> Yes. If you are adding new things to global_data you could convert
> default_log_level to a char to avoid using more space.
>
Also I notice that the processing_msg variable in log.c crashes
logging in SPL/TPL. Can you please move this to global_data too?
Regards,
Simon
