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]

Message-ID: <ce52ec2e-1b22-8a2f-7f99-d90fcfdbfebd@oracle.com>
Date:   Mon, 17 Dec 2018 09:52:24 -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 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.

-boris