Re: [PATCH v2 00/32] driver core: Constify API device_find_child() and adapt for various existing usages

Zijun Hu <[email protected]>
Newsgroups gmane.linux.scsi,gmane.linux.kernel,gmane.comp.video.dri.devel,gmane.linux.ports.arm.mediatek,gmane.linux.ports.arm.kernel,gmane.linux.kernel.hwmon,gmane.linux.drivers.video-input-infrastructure,gmane.linux.usb.general,gmane.linux.kernel.gpio,gmane.linux.network,gmane.linux.pwm,gmane.linux.kernel.firewire.devel,gmane.linux.serial,gmane.linux.sound,gmane.linux.iscsi.open-iscsi,gmane.linux.ports.sparc,gmane.linux.block,gmane.linux.kernel.efi
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.