linux-kernel - Re: [PATCH v2 2/2] 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: <87lf9mmo7l.fsf@linaro.org>
Date:   Tue, 13 Apr 2021 12:07:58 +0100
From:   Alex Bennée <alex.bennee@...aro.org>
To:     "Enrico Weigelt, metux IT consult" <info@...ux.net>
Cc:     Jason Wang <jasowang@...hat.com>, linux-kernel@...r.kernel.org,
        corbet@....net, linus.walleij@...aro.org,
        bgolaszewski@...libre.com, mst@...hat.com,
        linux-doc@...r.kernel.org, linux-gpio@...r.kernel.org,
        virtualization@...ts.linux-foundation.org,
        linux-riscv@...ts.infradead.org,
        Jean-Philippe Brucker <jean-philippe@...aro.org>
Subject: Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver


"Enrico Weigelt, metux IT consult" <info@...ux.net> writes:

> On 04.12.20 04:35, Jason Wang wrote:
>
> Hi,
>
>> Is the plan to keep this doc synced with the one in the virtio
>> specification?
>
> Yes, of course. I'm still in progress of doing the beaurocratic stuff w/
> virtio-tc folks (ID registration, ...) - yet have to see whether they
> wanna add it to their spec documents ...
>
> BTW: if you feel, sometings not good w/ the current spec, please raise
> your voice now.
>
>> I think it's better to use u8 ot uint8_t here.Git grep told me the
>> former is more popular under Documentation/.
>
> thx, I'll fix that
>
>>> +- for version field currently only value 1 supported.
>>> +- the line names block holds a stream of zero-terminated strings,
>>> +  holding the individual line names.
>> 
>> I'm not sure but does this mean we don't have a fixed length of config
>> space? Need to check whether it can bring any trouble to
>> migration(compatibility).
>
> Yes, it depends on how many gpio lines are present and how much space
> their names take up.
>
> A fixed size would either put unpleasent limits on the max number of
> lines or waste a lot space when only few lines present.
>
> Not that virtio-gpio is also meant for small embedded workloads running
> under some hypervisor.
>
>>> +- unspecified fields are reserved for future use and should be zero.
>>> +
>>> +------------------------
>>> +Virtqueues and messages:
>>> +------------------------
>>> +
>>> +- Queue #0: transmission from host to guest
>>> +- Queue #1: transmission from guest to host
>> 
>> 
>> Virtio became more a popular in the area without virtualization. So I
>> think it's better to use "device/driver" instead of "host/guest" here.
>
> Good point. But I'd prefer "cpu" instead of "driver" in that case.

I think you are going to tie yourself up in knots if you don't move this
to the OASIS spec. The reason being the VirtIO spec has definitions for
what a "Device" and a "Driver" is that are clear and unambiguous. The
upstream spec should be considered the canonical source of truth for any
implementation (Linux or otherwise).

By all means have the distilled documentation for the driver in the
kernel source tree but trying to upstream an implementation before
starting the definition in the standard is a little back to front IMHO*.

* that's not to say these things can't be done in parallel as the spec
  is reviewed and worked on and the kinks worked out but you want the
  final order of upstreaming to start with the spec.

-- 
Alex Bennée