From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pv50p00im-tydg10011801.me.com (pv50p00im-tydg10011801.me.com [17.58.6.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C0806391 for ; Thu, 5 Dec 2024 00:07:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=17.58.6.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733357278; cv=none; b=CgHx3wvnewAcCae13Yth4l8dbGsd7JmP7p0nmhZ3QsFThL5TSwtTgreIDrke5S5vxZkqXlbBKu+S1OGw9jYNA+elz2OFrnDzJiUvvfpNtW1kP+86IQQDW3prKz0tp7LdYi+w9MMfOfDaqS6BQ2ZeAYnfC0BhqksPU40j3tgTZk8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733357278; c=relaxed/simple; bh=jXDu8pWjhuYPdMP7VqE1gBu4NrjerabEKnAlH0ltUtc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ka/GDZR5STnUm7xk67NmWWDUU3Lduypw1gYZSicxIwbFd4N2z2W8OfM+zbHnh5K/Wf9s9AYyx7tdt++5OaM6sdnxrmmDwhaNZ+OOecsw7XxDnifoifvFzvi46wFOhfkztZ61pB+R1uzMIvZqBOd49OFrl8Q04ClkM+BqnOvrYQ0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=icloud.com; spf=pass smtp.mailfrom=icloud.com; dkim=pass (2048-bit key) header.d=icloud.com header.i=@icloud.com header.b=viUyMPDu; arc=none smtp.client-ip=17.58.6.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=icloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=icloud.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=icloud.com header.i=@icloud.com header.b="viUyMPDu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1733357275; bh=T0i1UIwZu179fqDDvM1SaMgHe4/s268Ao/wTXHvJFpU=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type: x-icloud-hme; b=viUyMPDupWXi4CsrMrPO0pTZeZeGxPoM+enltzZDnkb+kI0qdByPZT5LU1xBetse2 NtaWPzW2mnfiL0cDcb5AxsMAlW09DyzC74O6RR3cBb+ZzhEN7re48DHO1hdcod+aXb zbl3rMYxZGrv7wQqdRJsrWCp9PSwtE6uiLaNWgjCRsBT8D1ZUgFnCeCL+arYkrJDex wriQVWYopBjYxrWk6ouKFvfzOLXBz2VSyl6NuyevHO9GGv1V4cTmquonLgabfDNxjR 5eSkEUOnbtt2Et4RjPSCmjNRxtqblo8cbQN/o+14zsvC0nuehSg5FcL9uofh/yy5ZC z6tN/Ugl8ZG4Q== Received: from [192.168.1.26] (pv50p00im-dlb-asmtp-mailmevip.me.com [17.56.9.10]) by pv50p00im-tydg10011801.me.com (Postfix) with ESMTPSA id 9CBA68001C9; Thu, 5 Dec 2024 00:07:24 +0000 (UTC) Message-ID: <3a4de1bb-3eb2-469a-8ff7-ff706804f5bb@icloud.com> Date: Thu, 5 Dec 2024 08:07:20 +0800 Precedence: bulk X-Mailing-List: arm-scmi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 00/32] driver core: Constify API device_find_child() and adapt for various existing usages To: James Bottomley , =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= Cc: Greg Kroah-Hartman , =?UTF-8?Q?Uwe_Kleine-K=C3=B6nig?= , "Rafael J. Wysocki" , Chun-Kuang Hu , Philipp Zabel , David Airlie , Simona Vetter , Matthias Brugger , AngeloGioacchino Del Regno , Jean Delvare , Guenter Roeck , Martin Tuma , Mauro Carvalho Chehab , Andreas Noever , Michael Jamet , Mika Westerberg , Yehezkel Bernat , Linus Walleij , Bartosz Golaszewski , Andrew Lunn , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Dan Williams , Vishal Verma , Dave Jiang , Ira Weiny , Takashi Sakamoto , Jiri Slaby , Heikki Krogerus , Srinivas Kandagatla , Lee Duncan , Chris Leech , Mike Christie , "Martin K. Petersen" , Nilesh Javali , Manish Rangankar , GR-QLogic-Storage-Upstream@marvell.com, Davidlohr Bueso , Jonathan Cameron , Alison Schofield , Andreas Larsson , Stuart Yoder , Laurentiu Tudor , Jens Axboe , Sudeep Holla , Cristian Marussi , Ard Biesheuvel , Bjorn Andersson , Mathieu Poirier , 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 References: <20241203-const_dfc_done-v2-0-7436a98c497f@quicinc.com> <9d34bd6f-b120-428a-837b-5a5813e14618@icloud.com> <2024120320-manual-jockey-dfd1@gregkh> <8eb7c0c54b280b8eb72f82032ede802c001ab087.camel@HansenPartnership.com> <8fb887a0-3634-4e07-9f0d-d8d7c72ca802@t-8ch.de> <108c63c753f2f637a72c2e105ac138f80d4b0859.camel@HansenPartnership.com> <235ce0a9-1db1-4558-817b-6f92f22be5ab@icloud.com> <5c905df49a332b1136787a524955b46b6153c012.camel@HansenPartnership.com> Content-Language: en-US From: Zijun Hu In-Reply-To: <5c905df49a332b1136787a524955b46b6153c012.camel@HansenPartnership.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: SnhSPaefh2SqVr4UPg8Q8Npi4W-Py9Af X-Proofpoint-ORIG-GUID: SnhSPaefh2SqVr4UPg8Q8Npi4W-Py9Af X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.68.34 definitions=2024-12-04_19,2024-12-04_02,2024-11-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 suspectscore=0 bulkscore=0 spamscore=0 phishscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2412040186 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.