netdev - Re: [PATCH v2 5/6] mdev: Update sysfs documentation

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: <20190902163658.51fc48d2.cohuck@redhat.com>
Date:   Mon, 2 Sep 2019 16:36:58 +0200
From:   Cornelia Huck <cohuck@...hat.com>
To:     Parav Pandit <parav@...lanox.com>
Cc:     "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        Jiri Pirko <jiri@...lanox.com>,
        "kwankhede@...dia.com" <kwankhede@...dia.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 5/6] mdev: Update sysfs documentation

On Fri, 30 Aug 2019 13:10:17 +0000
Parav Pandit <parav@...lanox.com> wrote:

> > -----Original Message-----
> > From: Cornelia Huck <cohuck@...hat.com>
> > Sent: Friday, August 30, 2019 6:19 PM
> > To: Parav Pandit <parav@...lanox.com>
> > Cc: alex.williamson@...hat.com; Jiri Pirko <jiri@...lanox.com>;
> > kwankhede@...dia.com; davem@...emloft.net; kvm@...r.kernel.org; linux-
> > kernel@...r.kernel.org; netdev@...r.kernel.org
> > Subject: Re: [PATCH v2 5/6] mdev: Update sysfs documentation
> > 
> > On Thu, 29 Aug 2019 06:19:03 -0500
> > Parav Pandit <parav@...lanox.com> wrote:
> >   
> > > Updated documentation for optional read only sysfs attribute.  
> > 
> > I'd probably merge this into the patch introducing the attribute.
> >   
> Ok. I will spin v3.
> 
> > >
> > > Signed-off-by: Parav Pandit <parav@...lanox.com>
> > > ---
> > >  Documentation/driver-api/vfio-mediated-device.rst | 5 +++++
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/Documentation/driver-api/vfio-mediated-device.rst
> > > b/Documentation/driver-api/vfio-mediated-device.rst
> > > index 25eb7d5b834b..0ab03d3f5629 100644
> > > --- a/Documentation/driver-api/vfio-mediated-device.rst
> > > +++ b/Documentation/driver-api/vfio-mediated-device.rst
> > > @@ -270,6 +270,7 @@ Directories and Files Under the sysfs for Each mdev  
> > Device  
> > >           |--- remove
> > >           |--- mdev_type {link to its type}
> > >           |--- vendor-specific-attributes [optional]
> > > +         |--- alias [optional]  
> > 
> > "optional" implies "not always present" to me, not "might return a read error if
> > not available". Don't know if there's a better way to tag this? Or make it really
> > optional? :)  
> 
> May be write it as,
> 
> alias [ optional when requested by parent ]

I'm not sure what 'optional when requested' is supposed to mean...
maybe something like 'content optional' or so?

> 
> >   
> > >
> > >  * remove (write only)
> > >
> > > @@ -281,6 +282,10 @@ Example::
> > >
> > >  	# echo 1 > /sys/bus/mdev/devices/$mdev_UUID/remove
> > >
> > > +* alias (read only)
> > > +Whenever a parent requested to generate an alias, each mdev is
> > > +assigned a unique alias by the mdev core. This file shows the alias of the  
> > mdev device.
> > 
> > It's not really the parent, but the vendor driver requesting this, right? Also,  
> At mdev level, it only knows parent->ops structure, whether parent is registered by vendor driver or something else.

Who else is supposed to create the mdev device?

> 
> > "each mdev" is a bit ambiguous,   
> It is in context of the parent. Sentence is not starting with "each mdev".
> But may be more verbosely written as,
> 
> Whenever a parent requested to generate an alias, Each mdev device of such parent is assigned 
> unique alias by the mdev core. This file shows the alias of the mdev device.

I'd really leave the parent out of this: this seems more like an
implementation detail. It's more that alias may either contain an
alias, or return a read error if no alias has been generated. Who
requested the alias to be generated is probably not really of interest
to the userspace reader.

> 
> > created via that driver. Lastly, if we stick with the "returns an error if not
> > implemented" approach, that should also be mentioned here.  
> Ok. Will spin v3 to describe it.
> 
> >   
> > > +
> > >  Mediated device Hot plug
> > >  ------------------------
> > >  
>