linux-kernel - Re: [PATCH] drivers: gpio: add virtio-gpio guest driver

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: <098f669f-b451-18e1-9aed-a71f400bd581@metux.net>
Date:   Wed, 16 Jun 2021 16:41:22 +0200
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Linus Walleij <linus.walleij@...aro.org>,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Jason Wang <jasowang@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Anton Vorontsov <anton@...msg.org>,
        Colin Cross <ccross@...roid.com>,
        Tony Luck <tony.luck@...el.com>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        virtualization@...ts.linux-foundation.org,
        linux-riscv <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH] drivers: gpio: add virtio-gpio guest driver

On 16.06.21 10:31, Linus Walleij wrote:
 > Hi Enrico,

 > So now there are two contesting patches for this and that creates a
 > social problem for us as maintainers. I am not too happy about that.

note that this is a polished up of a repost of my original driver
from last year.

 > Can we get the discussion down to actual technical points?

Sure. Perhaps you recall or discussions from late 2020. The missing
point there was (besides a few wording issues) the missing formal
specification process w/ virtio TC. (spec was already included in this
driver as well as the corresponding qemu patches).

My spec was not just meant for VM applications but also actual silicon
(as already mentioned, some folks of my client also implemented it in
FPGAs - don't ask me about details, they just mentioned it was quite
easy for them).

This is why it is so trimmed on things like fixed packet size,
unidirectional queues, mirroring packets w/ thus a few bits changed,
etc. In constrast, a more network-like approach might have been looking
nicer to traditional computer programmers, but much more complex to do
in pure logic and eat up *lots of* more gates (think of actual memory
management instead of hardwired latches, more complex decoding, etc).

Meanwhile it played out working nicely in several HIL installations

If I wanted to have a simple and CPU-only approach (just for VMs), I
would have just mounted some sysfs pieces via 9P :p

Several weeks ago, Viresh just wanted to continue the missing pieces
(which was: tex'ifying the spec and submitting to virtio TC), but then
unfortunately he invented something entirely different also put my name
on it.

Easy to imagine that I'm not amused at all.

--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287