From: Jason Gunthorpe <jgg@nvidia•com>
To: Jakub Kicinski <kuba@kernel•org>
Cc: Brett Creeley <brett.creeley@amd•com>,
kvm@vger•kernel.org, netdev@vger•kernel.org,
alex.williamson@redhat•com, yishaih@nvidia•com,
shameerali.kolothum.thodi@huawei•com, kevin.tian@intel•com,
shannon.nelson@amd•com, drivers@pensando•io
Subject: Re: [PATCH v9 vfio 2/7] vfio/pds: Initial support for pds_vfio VFIO driver
Date: Fri, 5 May 2023 10:29:02 -0300 [thread overview]
Message-ID: <ZFUEnvDYZVJnPwQa@nvidia.com> (raw)
In-Reply-To: <20230504164005.16fb3deb@kernel.org>
On Thu, May 04, 2023 at 04:40:05PM -0700, Jakub Kicinski wrote:
> On Thu, 4 May 2023 19:41:54 -0300 Jason Gunthorpe wrote:
> > On Thu, May 04, 2023 at 01:20:01PM -0700, Jakub Kicinski wrote:
> > > On Thu, 4 May 2023 14:26:43 -0300 Jason Gunthorpe wrote:
> > > > This GNU style of left aligning the function name should not be
> > > > in the kernel.
> > >
> > > FTR that's not a kernel-wide rule. Please scope your coding style
> > > suggestions to your subsystem, you may confuse people.
> >
> > It is what Documentation/process/coding-style.rst expects.
>
> A reference to the section? You mean the vague mentions of the GNU
> coding style?
Here I was looking at the "left indent the function name" - that is a
GNUism. IIRC the justification is it makes it easy to find the
function with 'grep "^func"'
Coding style says:
Descendants are always substantially shorter than the parent and
are placed substantially to the right. A very commonly used style
is to align descendants to a function open parenthesis.
So this patch had things like this:
+static void
+pds_vfio_pci_remove(struct pci_dev *pdev)
The first line is shorter than the second and the second is left not
right placed. It doesn't even need wrapping.
I know some people like to do this in some parts of the tree
regardless of coding-style. The GNU idea is sort of reasonable after
all.
> If the function declaration does not fit in 80 chars breaking the type
> off as a separate line is often a very reasonable choice.
Reasonable yes, but not "common" :)
> Anyway, I shouldn't complain, networking still has its odd rules.
> Probably why people making up rules for no strong reason is on my mind.
I usually try to ignore most of the style details, but this one stood
out. When I checked the series against clang-format it was pretty good
otherwise. A few minor fine tunings on some line wrapping :)
Jason
next prev parent reply other threads:[~2023-05-05 13:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-22 1:06 [PATCH v9 vfio 0/7] pds_vfio driver Brett Creeley
2023-04-22 1:06 ` [PATCH v9 vfio 1/7] vfio: Commonize combine_ranges for use in other VFIO drivers Brett Creeley
2023-04-22 1:06 ` [PATCH v9 vfio 2/7] vfio/pds: Initial support for pds_vfio VFIO driver Brett Creeley
2023-05-04 17:26 ` Jason Gunthorpe
2023-05-04 20:20 ` Jakub Kicinski
2023-05-04 22:41 ` Jason Gunthorpe
2023-05-04 23:40 ` Jakub Kicinski
2023-05-05 13:29 ` Jason Gunthorpe [this message]
2023-05-05 15:35 ` Brett Creeley
2023-05-04 17:31 ` Jason Gunthorpe
2023-05-05 15:36 ` Brett Creeley
2023-06-02 22:05 ` Brett Creeley
2023-04-22 1:06 ` [PATCH v9 vfio 3/7] vfio/pds: register with the pds_core PF Brett Creeley
2023-04-22 1:06 ` [PATCH v9 vfio 4/7] vfio/pds: Add VFIO live migration support Brett Creeley
2023-05-04 17:34 ` Jason Gunthorpe
2023-05-05 15:37 ` Brett Creeley
2023-05-04 17:40 ` Jason Gunthorpe
2023-05-05 15:39 ` Brett Creeley
2023-05-04 17:50 ` Jason Gunthorpe
2023-05-05 15:42 ` Brett Creeley
2023-04-22 1:06 ` [PATCH v9 vfio 5/7] vfio/pds: Add support for dirty page tracking Brett Creeley
2023-05-04 18:21 ` Jason Gunthorpe
2023-04-22 1:06 ` [PATCH v9 vfio 6/7] vfio/pds: Add support for firmware recovery Brett Creeley
2023-04-22 1:06 ` [PATCH v9 vfio 7/7] vfio/pds: Add Kconfig and documentation Brett Creeley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZFUEnvDYZVJnPwQa@nvidia.com \
--to=jgg@nvidia$(echo .)com \
--cc=alex.williamson@redhat$(echo .)com \
--cc=brett.creeley@amd$(echo .)com \
--cc=drivers@pensando$(echo .)io \
--cc=kevin.tian@intel$(echo .)com \
--cc=kuba@kernel$(echo .)org \
--cc=kvm@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shameerali.kolothum.thodi@huawei$(echo .)com \
--cc=shannon.nelson@amd$(echo .)com \
--cc=yishaih@nvidia$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox