linux-kernel - Re: [Xen-devel] [PATCH v2 2/3] drm/xen-front: Use Xen common shared buffer implementation

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <19501fdd-eae6-295e-7394-777c25ea4cf1@oracle.com>
Date:   Mon, 17 Dec 2018 10:26:42 -0500
From:   Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:     Oleksandr Andrushchenko <andr2000@...il.com>, jgross@...e.com
Cc:     alsa-devel@...a-project.org,
        Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        xen-devel@...ts.xenproject.org
Subject: Re: [Xen-devel] [PATCH v2 2/3] drm/xen-front: Use Xen common shared
 buffer implementation

On 12/17/18 10:03 AM, Oleksandr Andrushchenko wrote:
> On 12/17/18 4:52 PM, Boris Ostrovsky wrote:
>> On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
>>> Hello, Juergen, Boris!
>>>
>>> As this DRM part of the series is the only one which needs ack/nack
>>>
>>> (and it might take quite some time to complete) could we please
>>>
>>> merge the patches 1 and 3 now that already have ack/r-b?
>>>
>>
>>
>> TBH I am not sure it makes sense to do this without the second patch.
>> Refactoring (and IIUIC this series is purely refactoring --- is it not?)
>> is done to reduce amount of code, and with only first and third patch we
>> end up with quite a significant increase in the number of LoC. (I am
>> going purely by diffstat)
>>
>> Of course, the other reason for refactoring is to eliminate code
>> duplication, but without second patch that will not happen.
>
> Agree, but this is the basis for the new pv camera frontend
>
> I am working on now [1], so even if we do not remove the code from DRM
>
> then we at least do not add it to the camera driver


Since 1 and 3 are already ACKed you should be able to start the camera
series with these two patches as pre-requisites even if patch 2 is still
stalled by the time your camera code is posted (which I assume will be
4.22 or later).



-boris


>
>> -boris
>
> Thank you,
>
> Oleksandr
>
> [1]
> https://github.com/andr2000/linux/blob/camera_front_v1/drivers/media/xen/Kconfig#L6
>