linux-kernel - Re: [PATCH v5 1/3] xen: Sync up with the canonical protocol definitions in Xen

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:   Wed, 13 Jun 2018 09:43:09 +0300
From:   Oleksandr Andrushchenko <Oleksandr_Andrushchenko@...m.com>
To:     Juergen Gross <jgross@...e.com>,
        Oleksandr Andrushchenko <andr2000@...il.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     xen-devel@...ts.xenproject.org, linux-input@...r.kernel.org,
        linux-kernel@...r.kernel.org, lyan@...e.com,
        boris.ostrovsky@...cle.com, konrad.wilk@...cle.com,
        andrii_chepurnyi@...m.com
Subject: Re: [PATCH v5 1/3] xen: Sync up with the canonical protocol
 definitions in Xen

On 06/13/2018 09:40 AM, Juergen Gross wrote:
> On 13/06/18 08:13, Oleksandr Andrushchenko wrote:
>> On 06/13/2018 09:11 AM, Dmitry Torokhov wrote:
>>> On June 12, 2018 10:49:31 PM PDT, Oleksandr Andrushchenko
>>> <andr2000@...il.com> wrote:
>>>> On 06/13/2018 02:40 AM, Dmitry Torokhov wrote:
>>>>> On Tue, Jun 12, 2018 at 03:46:10PM +0200, Juergen Gross wrote:
>>>>>> On 12/06/18 09:48, Oleksandr Andrushchenko wrote:
>>>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
>>>>>>>
>>>>>>> This is the sync up with the canonical definitions of the input,
>>>>>>> sound and display protocols in Xen.
>>>>>>>
>>>>>>> Changes to kbdif:
>>>>>>> 1. Add missing string constants for {feature|request}-raw-pointer
>>>>>>>       to align with the rest of the interface file.
>>>>>>>
>>>>>>> 2. Add new XenStore feature fields, so it is possible to
>>>> individually
>>>>>>>       control set of exposed virtual devices for each guest OS:
>>>>>>>         - set feature-disable-keyboard to 1 if no keyboard device
>>>> needs
>>>>>>>           to be created
>>>>>>>         - set feature-disable-pointer to 1 if no pointer device needs
>>>>>>>           to be created
>>>>>>>
>>>>>>> 3. Move multi-touch device parameters to backend nodes: these are
>>>>>>>        described as a part of frontend's XenBus configuration nodes
>>>>>>>        while they belong to backend's configuration. Fix this by
>>>> moving
>>>>>>>        the parameters to the proper section.
>>>>>>>
>>>>>>> Unique-id field:
>>>>>>> 1. Add unique-id XenBus entry for virtual input and display.
>>>>>>>
>>>>>>> 2. Change type of unique-id field to string for sndif to align with
>>>>>>> display and input protocols.
>>>>>>>
>>>>>>> Signed-off-by: Oleksandr Andrushchenko
>>>> <oleksandr_andrushchenko@...m.com>
>>>>>>> Cc: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
>>>>>> Reviewed-by: Juergen Gross <jgross@...e.com>
>>>>>>
>>>>>> I'm fine with this patch being added via the input tree with the
>>>> other
>>>>>> patches. In case I should take it via the Xen tree, please send me a
>>>>>> note.
>>>>> Juergen,
>>>>>
>>>>> I created an immutable branch off v4.17 with these 3 patches in case
>>>> you
>>>>> would want to merge them into your tree without waiting for them to
>>>>> appear in mainline:
>>>>>
>>>>> git pull git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
>>>> ib/4.17-xen-kbdfront-runtime-config
>>>>> Thanks.
>>>>>
>>>> Thank you,
>>>> I would prefer the fastest path of course
>>> It will be part of 4.19 pull request; the immutable branch is for
>>> Juergen if he does not want to wait till 4.19 merge window to get the
>>> changes.
>> Ah, I see. Juergen, can we please merge this via Xen tree then which
>> I assume will be faster?
> As Dmitry has it already queued in the input tree I think this is fine.
> I trust him to take the right decision for which kernel version those
> patches are to be queued. They belong to the input tree after all.
Of course, no doubt here
>
> Juergen
>
Thank you,
Oleksandr