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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 18 Dec 2018 10:47:43 +0200
From:   Oleksandr Andrushchenko <andr2000@...il.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.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 5:26 PM, Boris Ostrovsky wrote:
> 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).
Agreed, maybe by that time DRM part will also get its r-b/ack
>
>
> -boris
>
>
>>> -boris
>> Thank you,
>>
>> Oleksandr
>>
>> [1]
>> https://github.com/andr2000/linux/blob/camera_front_v1/drivers/media/xen/Kconfig#L6
>>