linux-kernel - Re: [RFC PATCH 0/4] 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-prev] [day] [month] [year] [list]

Date:   Mon, 23 Jan 2023 16:54:24 +0000
From:   Kieran Bingham <kieran.bingham@...asonboard.com>
To:     Stefan Wahren <stefan.wahren@...e.com>,
        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,
        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 Stefan,

Quoting Stefan Wahren (2023-01-22 18:07:03)
> Hi Kieran,
> 
> Am 22.01.23 um 17:26 schrieb Kieran Bingham:
> > Hi Stefan,
> >
> > Quoting Stefan Wahren (2023-01-22 14:21:05)
> >> 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.
> > Do you have a full list of the tasks you'd like to see completed ?
> > (including/or above drivers/staging/vc04_services/interface/TODO)
> 
> i consider every point except of point 1 (importing new drivers) as 
> necessary to leave staging.

Thanks

> Additionally there is the additional point (i can add them to the TODO) 
> above. Unfortunately i don't have a complete insight, how vchiq should 
> be to be acceptable. Sorry, if i can't help you further with possible 
> resource planning.
> 
> Are some points on the TODO list unclear?

I believe the list is fine, but I was enquiring if there were anymore
additional tasks above the scope listed in
drivers/staging/vc04_services/interface/TODO which are required. I don't
think you need to send a patch for the task above - unless there are a
lot more tasks required, or it becomes too much to do now.

The goal is to get the ISP upstream to support libcamera, and it would
help to know how deep the rabbit hole really is ;-)

--
Kieran