[U-Boot] [PATCH 06/13] log: Add an implemention of logging

[Simon Glass]

Hi Bin,

On 22 September 2017 at 07:37, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Simon,
>
> On Thu, Sep 21, 2017 at 12:58 PM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Bin,
>>
>> On 20 September 2017 at 08:41, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>
>>> Hi Simon,
>>>
>>> On Wed, Sep 20, 2017 at 9:50 PM, Simon Glass <sjg at chromium.org> wrote:
>>> > Hi Bin,
>>> >
>>> > On 17 September 2017 at 21:45, Bin Meng <bmeng.cn at gmail.com> wrote:
>>> >> Hi Simon,
>>> >>
>>> >> On Sun, Sep 17, 2017 at 5:23 AM, Simon Glass <sjg at chromium.org> wrote:
>>> >>> Add the logging header file and implementation with some configuration
>>> >>> options to control it.
>>> >>>
>>> >>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>> >>> ---
>>> >>>
>>> >>>  MAINTAINERS                       |   9 ++
>>> >>>  common/Kconfig                    |  56 +++++++++
>>> >>>  common/Makefile                   |   1 +
>>> >>>  common/log.c                      | 246 +++++++++++++++++++++++++++++++++++++
>>> >>>  include/asm-generic/global_data.h |   5 +
>>> >>>  include/log.h                     | 247 ++++++++++++++++++++++++++++++++++++--
>>> >>>  6 files changed, 555 insertions(+), 9 deletions(-)
>>> >>>  create mode 100644 common/log.c
>>> >>>
>>> >>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> >>> index 04acf2b89d..eb420afa8d 100644
>>> >>> --- a/MAINTAINERS
>>> >>> +++ b/MAINTAINERS
>>> >>> @@ -290,6 +290,15 @@ S: Maintained
>>> >>>  T:     git git://git.denx.de/u-boot-i2c.git
>>> >>>  F:     drivers/i2c/
>>> >>>
>>> >>> +LOGGING
>>> >>> +M:     Simon Glass <sjg at chromium.org>
>>> >>> +S:     Maintained
>>> >>> +T:     git git://git.denx.de/u-boot.git
>>> >>> +F:     common/log.c
>>> >>> +F:     cmd/log.c
>>> >>> +F:     test/log/log_test.c
>>> >>> +F:     test/py/tests/test_log.py
>>> >>
>>> >> test/log/log_test.c and test/py/tests/test_log.py have not been
>>> >> introduced at this point.
>>> >
>>> > OK I can tweak that,
>>> > [..]
>>> >
>>> >>> +/**
>>> >>> + * struct log_driver - a driver which accepts and processes log records
>>> >>> + *
>>> >>> + * @name: Name of driver
>>> >>> + */
>>> >>> +struct log_driver {
>>> >>> +       const char *name;
>>> >>> +       /**
>>> >>> +        * emit() - emit a log record
>>> >>> +        *
>>> >>> +        * Called by the log system to pass a log record to a particular driver
>>> >>> +        * for processing. The filter is checked before calling this function.
>>> >>> +        */
>>> >>> +       int (*emit)(struct log_device *ldev, struct log_rec *rec);
>>> >>> +};
>>> >>> +
>>> >>
>>> >> So we are creating a new type of non-DM driver which is log-specific?
>>> >> How about we add this emit to the existing uclass driver that can be
>>> >> used as the log driver? (eg: blk devices with file system?)
>>> >
>>> > Yes that's right. I think I can link it to DM once it starts up, but a
>>> > logging of DM start-up is useful.
>>> >
>>> > Re your idea are you saying add an emit() method to UCLASS_BLK?
>>> >
>>>
>>> Yep, something like
>>>
>>> #ifdef CONFIG_LOG
>>>     .log_emit = xxx_log_emit,
>>> #endif
>>>
>>> Probably we need a flag to find out which driver provides such log
>>> functionality.
>>
>> So what would the block driver do in that function? I guess I don't
>> understand what it is for. Can you please give me more information?
>>
>
> The blk driver can save the logs to a predefined block address for
> permanent storage. Or file system driver can send the logs to a file.

OK I see. IMO this is not really a function of a block device. I don't
see what an emit() method in a USB block device (for example) would do
differently from one in a SATA block device.

We could have a single 'log_blk' driver which:

- allows configuration of what blocks are used for the log
- writes blocks there (perhaps wrapping if it runs out of space)

For file systems we could have a 'log_fs' driver which:

- allows configuration of log file path
- writes blocks into that file (perhaps starting a new file and
rotating the log if things get over a limit

Regards,
Simon