From: Jakub Kicinski <kuba@kernel•org>
To: Shannon Nelson <shannon.nelson@amd•com>
Cc: brett.creeley@amd•com, davem@davemloft•net,
netdev@vger•kernel.org, drivers@pensando•io, leon@kernel•org,
jiri@resnulli•us
Subject: Re: [PATCH v6 net-next 01/14] pds_core: initial framework for pds_core PF driver
Date: Thu, 30 Mar 2023 09:46:30 -0700 [thread overview]
Message-ID: <20230330094630.3ba04654@kernel.org> (raw)
In-Reply-To: <90284b4a-0e81-441b-5d28-547992dab274@amd.com>
On Thu, 30 Mar 2023 00:43:56 -0700 Shannon Nelson wrote:
> On 3/29/23 7:27 PM, Jakub Kicinski wrote:
> > On Wed, 29 Mar 2023 13:53:23 -0700 Shannon Nelson wrote:
> >> The devlink alloc and registration are obviously a part of the probe and
> >> thus device control setup, so I’m not sure why this is an issue.
> >>
> >> As is suggested in coding style, the smaller functions make for easier
> >> reading, and keeps the related locking in a nice little package. Having
> >> the devlink registration code gathered in one place in the devlink.c
> >> file seems to follow most conventions, which then allows the helper
> >> functions to be static to that file. This seems to be what about half
> >> the drivers that use devlink have chosen to do.
> >
> > It is precisely the painful experience of dealing with those drivers
> > when refactoring devlink code which makes me ask you to do it right.
>
> Is there a useful place where such guidance can be put to help future
> folks from falling into the same traps?
Putting it mildly we have a reasonable expectation that any large
company will have at least one person reading the mailing list :(
Who's going to write the documentation you're asking about?
This is an open source project, let's be realistic..
next prev parent reply other threads:[~2023-03-30 16:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-24 19:02 [PATCH v6 net-next 00/14] pds_core driver Shannon Nelson
2023-03-24 19:02 ` [PATCH v6 net-next 01/14] pds_core: initial framework for pds_core PF driver Shannon Nelson
2023-03-25 23:39 ` Jakub Kicinski
2023-03-26 4:07 ` Shannon Nelson
2023-03-28 0:43 ` Jakub Kicinski
2023-03-28 6:19 ` Shannon Nelson
2023-03-28 22:17 ` Jakub Kicinski
2023-03-29 20:53 ` Shannon Nelson
2023-03-30 2:27 ` Jakub Kicinski
2023-03-30 7:02 ` Leon Romanovsky
2023-03-30 7:43 ` Shannon Nelson
2023-03-30 16:46 ` Jakub Kicinski [this message]
2023-03-24 19:02 ` [PATCH v6 net-next 02/14] pds_core: add devcmd device interfaces Shannon Nelson
2023-03-24 19:02 ` [PATCH v6 net-next 03/14] pds_core: health timer and workqueue Shannon Nelson
2023-03-24 19:02 ` [PATCH v6 net-next 04/14] pds_core: add devlink health facilities Shannon Nelson
2023-03-24 19:02 ` [PATCH v6 net-next 05/14] pds_core: set up device and adminq Shannon Nelson
2023-03-24 19:02 ` [PATCH v6 net-next 06/14] pds_core: Add adminq processing and commands Shannon Nelson
2023-03-24 19:02 ` [PATCH v6 net-next 07/14] pds_core: add FW update feature to devlink Shannon Nelson
2023-03-24 19:02 ` [PATCH v6 net-next 08/14] pds_core: set up the VIF definitions and defaults Shannon Nelson
2023-03-24 19:02 ` [PATCH v6 net-next 09/14] pds_core: add initial VF device handling Shannon Nelson
2023-03-24 19:02 ` [PATCH v6 net-next 10/14] pds_core: add auxiliary_bus devices Shannon Nelson
2023-03-24 19:02 ` [PATCH v6 net-next 11/14] pds_core: devlink params for enabling VIF support Shannon Nelson
2023-03-24 19:02 ` [PATCH v6 net-next 12/14] pds_core: add the aux client API Shannon Nelson
2023-03-24 19:02 ` [PATCH v6 net-next 13/14] pds_core: publish events to the clients Shannon Nelson
2023-03-24 19:02 ` [PATCH v6 net-next 14/14] pds_core: Kconfig and pds_core.rst Shannon Nelson
2023-03-25 20:40 ` kernel test robot
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=20230330094630.3ba04654@kernel.org \
--to=kuba@kernel$(echo .)org \
--cc=brett.creeley@amd$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=drivers@pensando$(echo .)io \
--cc=jiri@resnulli$(echo .)us \
--cc=leon@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shannon.nelson@amd$(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