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: <dadc99c5-dd63-9b3e-aa00-c9dc0b622134@metux.net>
Date:   Mon, 7 Dec 2020 21:34:55 +0100
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     "Michael S. Tsirkin" <mst@...hat.com>
Cc:     Jason Wang <jasowang@...hat.com>,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>,
        linux-kernel@...r.kernel.org, corbet@....net,
        linus.walleij@...aro.org, bgolaszewski@...libre.com,
        linux-doc@...r.kernel.org, linux-gpio@...r.kernel.org,
        virtualization@...ts.linux-foundation.org,
        linux-riscv@...ts.infradead.org, stefanha@...hat.com,
        msuchanek@...e.de
Subject: Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver

On 07.12.20 14:52, Michael S. Tsirkin wrote:

>> See above: NAK. because it can't even be enabled directly (by the user).
>> If it wasn't meant otherwise, we'd have to add an menu text.
> 
> The point is that user enables one of the bindings.
> That in turn enables drivers. If we merely select VIRTIO
> there's a chance user won't remember to select any bindings
> and will be surprised not to see any devices.

Not sure what you mean by "bindings" ... transports ?

IMHO, transports and device drivers are entirely orthogonal. Both *use*
the core, but I don't think they shall only show up, after the core was
enabled explicitly. Any combination of transports is valid (having none
at all, of course, isn't actually useful).

>> When using other transports ?
> 
> Any transport selects VIRTIO so if you enable that, you get
> VIRTIO and thus it's enough to depend on it.

The combination of 'select VIRTIO' and 'depends on VIRTIO' is what
caused the recursive dependency. Chaning everything to 'select VIRTIO'
fixed that.

>> I don't thinkt that would be good - instead everybody should just select
>> VIRTIO, never depend on it (maybe depend on VIRTIO_MENU instead)
> 
> GPU depends on VIRTIO and on VIRTIO_MENU ... which seems even messier
> ...

See:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2404871.html


--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