linux-kernel - [RFC PATCH v2 0/4] staging: vc04: Drop custom logging

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-next>] [day] [month] [year] [list]

Message-Id: <20230913185528.770634-1-umang.jain@ideasonboard.com>
Date:   Thu, 14 Sep 2023 00:25:24 +0530
From:   Umang Jain <umang.jain@...asonboard.com>
To:     linux-staging@...ts.linux.dev,
        linux-arm-kernel@...ts.infradead.org,
        linux-rpi-kernel@...ts.infradead.org, linux-media@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc:     Stefan Wahren <stefan.wahren@...e.com>,
        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>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Phil Elwell <phil@...pberrypi.com>,
        Umang Jain <umang.jain@...asonboard.com>
Subject: [RFC PATCH v2 0/4] staging: vc04: Drop custom logging

Hello,

This series attempts to restart the discussion on custom logging used
in VC04. In the last feedback gathered in [1] it seems that the logging
would rather be moved to use dynamic debug. The series tries to move
in that direction.

The elephant in the room is the ability of turning on/off log levels,
which this series just drops. Compensated by a crude strings
("error", "warning", "info"... etc) for easier grepping.

The log category are also just strings (which probably can be transformed
to dynamic debug class names moving forwards?).

To move forwards, I would like feedback on the broader direction.
There are couple of TODOs in each of the patch (summarised in commit
messages) which require case-by-case discussion.

Additional high-level questions to move forwards:
1. Is loss of log levels by moving to dynamic debug, is actually a
   concern? Is dynamic debug a valid replacement?
2. Whether debugfs should be dropped as well, found vestigial in [2]
3. whether vchiq_log_trace() should actually be tracing support for VC04

All this is done to elimiate the TODO item in:
drivers/staging/vc04_services/interface/TODO
* Cleanup logging mechanism 

Addtional comments/questions are welcome.

Thank you.

Tested over media-tree master with dynamic debug configs enabled and
drivers/staging/vc04_services/interface/TESTING.

[1] https://lore.kernel.org/lkml/20230118115810.21979-1-umang.jain@ideasonboard.com/
[2] https://lore.kernel.org/lkml/Y8lHqd9FlxiXTLuW@kroah.com/

Umang Jain (4):
  staging: vc04: Convert vchiq_log_error() to use dynamic debug
  staging: vc04: Convert vchiq_log_warning() to use dynamic debug
  staging: vc04: Convert vchiq_log_info() to use dynamic debug
  staging: vc04: Convert vchiq_log_trace() to use dynamic debug

 .../interface/vchiq_arm/vchiq_arm.c           | 127 +++++-----
 .../interface/vchiq_arm/vchiq_connected.c     |   6 +-
 .../interface/vchiq_arm/vchiq_core.c          | 225 ++++++++----------
 .../interface/vchiq_arm/vchiq_core.h          |  46 ++--
 .../interface/vchiq_arm/vchiq_dev.c           |  41 ++--
 5 files changed, 232 insertions(+), 213 deletions(-)

base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d
-- 
2.40.1