linux-kernel - Re: [PATCH v2] vfio-pci: Provide reviewers and acceptance criteria for vendor drivers

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: <87pmmoxqv8.fsf@meer.lwn.net>
Date:   Mon, 14 Mar 2022 13:42:51 -0600
From:   Jonathan Corbet <corbet@....net>
To:     Alex Williamson <alex.williamson@...hat.com>,
        alex.williamson@...hat.com, kvm@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, jgg@...dia.com,
        shameerali.kolothum.thodi@...wei.com, kevin.tian@...el.com,
        yishaih@...dia.com, linux-doc@...r.kernel.org
Subject: Re: [PATCH v2] vfio-pci: Provide reviewers and acceptance criteria
 for vendor drivers

Alex Williamson <alex.williamson@...hat.com> writes:

> Vendor or device specific extensions for devices exposed to userspace
> through the vfio-pci-core library open both new functionality and new
> risks.  Here we attempt to provided formalized requirements and
> expectations to ensure that future drivers both collaborate in their
> interaction with existing host drivers, as well as receive additional
> reviews from community members with experience in this area.
>
> Cc: Jason Gunthorpe <jgg@...dia.com>
> Cc: Yishai Hadas <yishaih@...dia.com>
> Cc: Shameer Kolothum <shameerali.kolothum.thodi@...wei.com>
> Cc: Kevin Tian <kevin.tian@...el.com>
> Signed-off-by: Alex Williamson <alex.williamson@...hat.com>
> ---

One thing...

>  .../vfio/vfio-pci-vendor-driver-acceptance.rst     |   35 ++++++++++++++++++++
>  MAINTAINERS                                        |   10 ++++++
>  2 files changed, 45 insertions(+)

If you add a new RST file, you need to add it to an index.rst somewhere
so that it becomes part of the kernel docs build.

Also, though: can we avoid creating a new top-level documentation
directory for just this file?  It seems like it would logically be a
part of the maintainers guide (Documentation/maintainer) ... ?

Thanks,

jon