From: Zijun Hu <zijun_hu@icloud.com>
To: "James Bottomley" <James.Bottomley@HansenPartnership.com>,
"Thomas Weißschuh" <thomas@t-8ch.de>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Chun-Kuang Hu" <chunkuang.hu@kernel.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Jean Delvare" <jdelvare@suse.com>,
"Guenter Roeck" <linux@roeck-us.net>,
"Martin Tuma" <martin.tuma@digiteqautomotive.com>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Andreas Noever" <andreas.noever@gmail.com>,
"Michael Jamet" <michael.jamet@intel.com>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
"Yehezkel Bernat" <YehezkelShB@gmail.com>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Bartosz Golaszewski" <brgl@bgdev.pl>,
"Andrew Lunn" <andrew@lunn.ch>,
"Vladimir Oltean" <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Dan Williams" <dan.j.williams@intel.com>,
"Vishal Verma" <vishal.l.verma@intel.com>,
"Dave Jiang" <dave.jiang@intel.com>,
"Ira Weiny" <ira.weiny@intel.com>,
"Takashi Sakamoto" <o-takashi@sakamocchi.jp>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
"Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
"Lee Duncan" <lduncan@suse.com>,
"Chris Leech" <cleech@redhat.com>,
"Mike Christie" <michael.christie@oracle.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
"Nilesh Javali" <njavali@marvell.com>,
"Manish Rangankar" <mrangankar@marvell.com>,
GR-QLogic-Storage-Upstream@marvell.com,
"Davidlohr Bueso" <dave@stgolabs.net>,
"Jonathan Cameron" <jonathan.cameron@huawei.com>,
"Alison Schofield" <alison.schofield@intel.com>,
"Andreas Larsson" <andreas@gaisler.com>,
"Stuart Yoder" <stuyoder@gmail.com>,
"Laurentiu Tudor" <laurentiu.tudor@nxp.com>,
"Jens Axboe" <axboe@kernel.dk>,
"Sudeep Holla" <sudeep.holla@arm.com>,
"Cristian Marussi" <cristian.marussi@arm.com>,
"Ard Biesheuvel" <ardb@kernel.org>,
"Bjorn Andersson" <andersson@kernel.org>,
"Mathieu Poirier" <mathieu.poirier@linaro.org>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-hwmon@vger.kernel.org, linux-media@vger.kernel.org,
linux-usb@vger.kernel.org, linux-gpio@vger.kernel.org,
netdev@vger.kernel.org, linux-pwm@vger.kernel.org,
nvdimm@lists.linux.dev, linux1394-devel@lists.sourceforge.net,
linux-serial@vger.kernel.org, linux-sound@vger.kernel.org,
open-iscsi@googlegroups.com, linux-scsi@vger.kernel.org,
linux-cxl@vger.kernel.org, sparclinux@vger.kernel.org,
linux-block@vger.kernel.org, arm-scmi@vger.kernel.org,
linux-efi@vger.kernel.org, linux-remoteproc@vger.kernel.org,
"Zijun Hu" <quic_zijuhu@quicinc.com>
Subject: Re: [PATCH v2 00/32] driver core: Constify API device_find_child() and adapt for various existing usages
Date: Thu, 5 Dec 2024 08:07:20 +0800 [thread overview]
Message-ID: <3a4de1bb-3eb2-469a-8ff7-ff706804f5bb@icloud.com> (raw)
In-Reply-To: <5c905df49a332b1136787a524955b46b6153c012.camel@HansenPartnership.com>
On 2024/12/5 00:42, James Bottomley wrote:
>>>> introduce extra device_find_child_new() which is constified ->
>>>> use *_new() replace ALL device_find_child() instances one by one
>>>> -> remove device_find_child() -> rename *_new() to
>>>> device_find_child() once.
>>> Why bother with the last step, which churns the entire code base
>>> again?
>> keep the good API name device_find_child().
> Well, I think it's a good opportunity to rename the API better, but if
> that's the goal, you can still do it with _Generic() without churning
> the code base a second time. The example is in
> slab.h:kmem_cache_create
>
i understand these solutions _Generic()/_new/squashing.
every solutions have its advantages and disadvantages.
i decide to use squashing solution for this concrete scenario after some
considerations since:
1) it has the minimal patch count to achieve target.
2) every patch is valuable, but other solutions needs to undo beginning
patch finally.
3) for the squashing patch, i will only make the least and simplest
changes for various match functions, that will compensate its
disadvantages.
>>> Why not call the new function device_find_child_const() and simply
>>> keep it (it's descriptive of its function). That way you can have
>>> a patch series without merging and at the end simply remove the old
>>> function.
>> device_find_child is a good name for the API, 'find' already means
>> const.
> Not to me it doesn't, but that's actually not what I think is wrong
> with the API name: it actually only returns the first match, so I'd
> marginally prefer it to be called device_find_first_child() ... not
> enough to churn the code to change it, but since you're doing that
> anyway it might make sense as an update.
name device_find_child appeared 18 years ago, it is good to keep this
name developers known about.
the API only return one device *, it should be obvious that it is the
first device which meet matching condition.
Other device finding APIs (bus|class|driver)_find_device() does not have
concern about 'first'
So, IMO, current name is good.
prev parent reply other threads:[~2024-12-05 0:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-03 0:33 [PATCH v2 00/32] driver core: Constify API device_find_child() and adapt for various existing usages Zijun Hu
2024-12-03 0:33 ` [PATCH v2 01/32] driver core: Constify API device_find_child() Zijun Hu
2024-12-03 0:33 ` [PATCH v2 02/32] driver core: Introduce device_match_type() to match device with a device type Zijun Hu
2024-12-03 0:33 ` [PATCH v2 03/32] drm/mediatek: Adapt for constified device_find_child() Zijun Hu
2024-12-03 0:33 ` [PATCH v2 04/32] hwmon: " Zijun Hu
2024-12-03 0:33 ` [PATCH v2 05/32] media: pci: mgb4: " Zijun Hu
2024-12-03 0:33 ` [PATCH v2 06/32] thunderbolt: " Zijun Hu
2024-12-03 0:33 ` [PATCH v2 07/32] gpio: sim: Remove gpio_sim_dev_match_fwnode() Zijun Hu
2024-12-03 0:33 ` [PATCH v2 08/32] net: dsa: Adapt for constified device_find_child() Zijun Hu
2024-12-03 0:33 ` [PATCH v2 09/32] pwm: " Zijun Hu
2024-12-03 0:33 ` [PATCH v2 10/32] nvdimm: " Zijun Hu
2024-12-03 0:33 ` [PATCH v2 11/32] libnvdimm: Simplify nd_namespace_store() implementation Zijun Hu
2024-12-03 2:29 ` [PATCH v2 00/32] driver core: Constify API device_find_child() and adapt for various existing usages quic_zijuhu
2024-12-03 12:00 ` Uwe Kleine-König
2024-12-03 12:23 ` Zijun Hu
2024-12-03 12:41 ` Greg Kroah-Hartman
2024-12-03 13:02 ` Zijun Hu
2024-12-03 13:58 ` James Bottomley
2024-12-03 14:07 ` Thomas Weißschuh
2024-12-03 14:56 ` Zijun Hu
2024-12-03 15:34 ` James Bottomley
2024-12-04 12:26 ` Zijun Hu
2024-12-04 16:42 ` James Bottomley
2024-12-05 0:07 ` Zijun Hu [this message]
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=3a4de1bb-3eb2-469a-8ff7-ff706804f5bb@icloud.com \
--to=zijun_hu@icloud.com \
--cc=GR-QLogic-Storage-Upstream@marvell.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=YehezkelShB@gmail.com \
--cc=airlied@gmail.com \
--cc=alison.schofield@intel.com \
--cc=andersson@kernel.org \
--cc=andreas.noever@gmail.com \
--cc=andreas@gaisler.com \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=ardb@kernel.org \
--cc=arm-scmi@vger.kernel.org \
--cc=axboe@kernel.dk \
--cc=brgl@bgdev.pl \
--cc=chunkuang.hu@kernel.org \
--cc=cleech@redhat.com \
--cc=cristian.marussi@arm.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=davem@davemloft.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=edumazet@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=horms@kernel.org \
--cc=ira.weiny@intel.com \
--cc=jdelvare@suse.com \
--cc=jirislaby@kernel.org \
--cc=jonathan.cameron@huawei.com \
--cc=kuba@kernel.org \
--cc=laurentiu.tudor@nxp.com \
--cc=lduncan@suse.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=linux@roeck-us.net \
--cc=martin.petersen@oracle.com \
--cc=martin.tuma@digiteqautomotive.com \
--cc=mathieu.poirier@linaro.org \
--cc=matthias.bgg@gmail.com \
--cc=mchehab@kernel.org \
--cc=michael.christie@oracle.com \
--cc=michael.jamet@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=mrangankar@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=njavali@marvell.com \
--cc=nvdimm@lists.linux.dev \
--cc=o-takashi@sakamocchi.jp \
--cc=olteanv@gmail.com \
--cc=open-iscsi@googlegroups.com \
--cc=p.zabel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=quic_zijuhu@quicinc.com \
--cc=rafael@kernel.org \
--cc=simona@ffwll.ch \
--cc=sparclinux@vger.kernel.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=stuyoder@gmail.com \
--cc=sudeep.holla@arm.com \
--cc=thomas@t-8ch.de \
--cc=ukleinek@kernel.org \
--cc=vishal.l.verma@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).