lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d5363f85-44e1-eee1-f7a5-61102637ef53@i2se.com>
Date:   Sun, 22 Jan 2023 15:21:05 +0100
From:   Stefan Wahren <stefan.wahren@...e.com>
To:     Umang Jain <umang.jain@...asonboard.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Adrien Thierry <athierry@...hat.com>,
        Dan Carpenter <error27@...il.com>,
        Dave Stevenson <dave.stevenson@...pberrypi.com>,
        linux-arm-kernel@...ts.infradead.org,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        linux-kernel@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
        linux-staging@...ts.linux.dev, linux-media@...r.kernel.org,
        Phil Elwell <phil@...pberrypi.com>
Subject: Re: [RFC PATCH 0/4] Drop custom logging

Hi Umang,

Am 18.01.23 um 12:58 schrieb Umang Jain:
> Drop custom logging from the vchiq interface.
> Mostly of them are replaced with dev_dbg and friends
> and/or pr_info and friends.
>
> The debugfs log levels (in 4/4) are mapped to kernel
> logs levels (coming from include/linux/kern_levels.h)
> Would like some thoughts on it as I am not sure (hence
> marking this is RFC)
>
>  From drivers/staging/vc04_services/interface/TODO:
>
> """
> * Cleanup logging mechanism
>
> The driver should probably be using the standard kernel logging mechanisms
> such as dev_info, dev_dbg, and friends.
> """

at first i want to thank you for the work on vchiq so far.

There is something which is not directly related to this series, but it 
is also about debugging. The driver has a buffer which is accessed by 
it's own DEBUG_* macros. The content of this debug buffer can be dumped 
via the /dev/vchiq which is also used by ioctl. I would appreciate to 
move this dump feature into a new debugfs entry.

Best regards

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ