linux-kernel - Re: [PATCH] s390/cio: add missing MODULE

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: <8ae9b1bef0e8ef4689873911c8ae5c9a921401a9.camel@linux.ibm.com>
Date: Wed, 19 Jun 2024 10:00:14 -0400
From: Eric Farman <farman@...ux.ibm.com>
To: Halil Pasic <pasic@...ux.ibm.com>
Cc: Vineeth Vijayan <vneethv@...ux.ibm.com>,
        Jeff Johnson
 <quic_jjohnson@...cinc.com>,
        Peter Oberparleiter <oberpar@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Christian Borntraeger
 <borntraeger@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        Matthew
 Rosato <mjrosato@...ux.ibm.com>, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] s390/cio: add missing MODULE_DESCRIPTION() macros

On Wed, 2024-06-19 at 12:32 +0200, Halil Pasic wrote:
> On Tue, 18 Jun 2024 16:11:33 -0400
> Eric Farman <farman@...ux.ibm.com> wrote:
> 
> > > > +MODULE_DESCRIPTION("VFIO based Physical Subchannel device
> > > > driver");  
> > > 
> > > Halil/Mathew/Eric,
> > > Could you please comment on this ?  
> > 
> > That's what is in the prologue, and is fine.
> 
> Eric can you explain it to me why is the attribute "physical"
> appropriate
> here? I did a quick grep for "Physical Subchannel" only turned up
> hits
> in vfio-ccw.

One hit, in the prologue comment of this module. "Physical device" adds
three to the tally, but only one of those is in vfio-ccw so we should
expand your query regarding "physical" vs "emulated" vs "virtual" in
the context of, say, tape devices.

> 
> My best guess is that "physical" was somehow intended to mean the
> opposite of "virtual". But actually it does not matter if our
> underlying
> subchannel is emulated or not, at least AFAIU.

I also believe this was intended to mean "not virtual," regardless of
whether there's emulation taking place underneath. That point is moot
since I don't see that information being surfaced, such that the driver
can only work with "physical" subchannels.

I'm fine with removing it if it bothers you, but I don't see it as an
issue.

Thanks,
Eric

> 
> Regards,
> Halil