On 20 Sep 2017, at 16:41, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Wed, Sep 20, 2017 at 9:50 PM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 17 September 2017 at 21:45, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sun, Sep 17, 2017 at 5:23 AM, Simon Glass sjg@chromium.org wrote:
Add the logging header file and implementation with some configuration options to control it.
Signed-off-by: Simon Glass sjg@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@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.
I had started to sketch (but have been able to fully flesh this out, due to other priorities intervening) a mechanism for MISC devices that might be a good fit for this.
My work centers around the idea of having devices comply to “protocols” and was aimed at distinguishing between an efuse-device and a GbE RGMII-control (one where we need to adjust the RGMII clock depending on the link rate the PHY negotiated) device.
I.e. I had started to implement something along the lines of:
/** * misc_supports - tests if a misc device complies to a given protocol * * protocols can either be ‘how data is processed after calling write()’, * ‘how data is presented for a read()’ or ‘what ioctl-values are supported’. * The assumption is that protocols can be versioned and higher versions * offer full backward compatibility (i.e. a client for “Ethernet PHY control, v1” * can work with a driver implementing v1 or any higher version). */ bool misc_supports(struct udevice *dev, const char *protocol, u32 version);
and a way to register a list of protocols as part of the misc uclass-priv for any given driver.
This would allow us to enumerate all MISC devices until we find one that complies to the ‘logging’-protocol and then invoke write or ioctl on it.
Regards, Philipp.