linux-kernel - Re: [PATCH 00/50] staging: vchiq: Getting rid of the vchi/vchiq split

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:   Thu, 25 Jun 2020 16:34:30 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
Cc:     devel@...verdev.osuosl.org, kernel-list@...pberrypi.com,
        linux-kernel@...r.kernel.org, laurent.pinchart@...asonboard.com,
        linux-arm-kernel@...ts.infradead.org,
        linux-rpi-kernel@...ts.infradead.org
Subject: Re: [PATCH 00/50] staging: vchiq: Getting rid of the vchi/vchiq split

On Tue, Jun 23, 2020 at 06:41:46PM +0200, Nicolas Saenz Julienne wrote:
> vchi acts as a mid layer between vchiq and its kernel services, while
> arguably providing little to no benefit: half of the functions exposed
> are a 1:1 copy of vchiq's, and the rest provide some functionality which
> can be easly integrated into vchiq without all the churn. Moreover it
> has been found in the past as a blockage to further fixes in vchiq as
> every change needed its vchi counterpart, if even possible.
> 
> Hence this series, which merges all vchi functionality into vchiq and
> provies a simpler and more concise API to services.
> 
> I'm aware that kernel's vchi API tries to mimic its userspace
> counterpart (or vice versa). Obviously this breaks the parity, but I
> don't think it's a sane goal to have. There is little sense or gain from
> it, and adds impossible constraints to upstreaming the driver.
> 
> Overall this fall short of removing 1100 lines of code, which is pretty
> neat on itself.
> 
> So far it has been tested trough bcm2835-camera, audio and vchiq-test. I
> can't do much about vc-sm-cma for now as it's only available downstream,
> but I made sure not to break anything and will provide some patches for
> the RPi devs to pick-up, so as to make their life easier.
> 
> Note that in order to keep the divergence between the downstream and
> upstream versions of this as small as possible I picked up some
> mmal-vchiq patches that might not be absolutely necessary to the goal of
> the series.

I took the first 2 patches and will wait for the rest to be resent :)

thanks,

greg k-h