[PATCH 1/2] log: allow for message continuation

Simon Glass sjg at chromium.org
Wed Sep 23 00:03:57 CEST 2020


Hi Heinrich,

On Tue, 22 Sep 2020 at 13:10, Heinrich Schuchardt <xypron.glpk at 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.glpk at 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.glpk at 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.


>
> Best regards
>
> Heinrich
>
> >
> >
> >>         char buf[CONFIG_SYS_CBSIZE];
> >>         struct log_rec rec;
> >>         va_list args;
> >>
> >> +       /* Check for message continuation */
> >> +       if (cat == LOGC_CONT)
> >
> > Regards,
> > Simon
> >
>


More information about the U-Boot mailing list