Messages in this thread | | | Date | Wed, 8 Jun 2022 09:31:46 -0400 | Subject | Re: [PATCH v19 11/20] s390/vfio-ap: prepare for dynamic update of guest's APCB on queue probe/remove | From | Tony Krowiak <> |
| |
On 6/7/22 8:05 AM, Halil Pasic wrote: > On Tue, 31 May 2022 06:44:46 -0400 > Tony Krowiak <akrowiak@linux.ibm.com> wrote: > >>> vfio_ap_mdev_get_update_locks_for_apqn is "crazy long". >>> How about: >>> get_mdev_for_apqn() >>> >>> This function is static and the terms mdev and apqn are specific >>> enough that I >>> don't think it needs to start with vfio_ap. And there is no need to >>> state in >>> the function name that locks are acquired. That point will be obvious >>> to anyone >>> reading the prologue or the code. >> The primary purpose of the function is to acquire the locks in the >> proper order, so >> I think the name should state that purpose. It may be obvious to someone >> reading >> the prologue or this function, but not so obvious in the context of the >> calling function. > I agree with Tony. To me get_mdev_for_apqn() sounds like getting a > reference to a matrix_mdev object (and incrementing its refcount) or > something similar. BTW some more bike shedding: I prefer by_apqn instead > of for_apqn, because the set of locks we need to take is determined _by_ > the apqn parameter, but it ain't semantically the set of locks we need > to perform an update operation on the apqn or on the queue associated > with the apqn. No strong opinion though -- I'm no native speaker and > prepositions are difficult for me.
I am a native speaker and I had to review prepositions. I learned grammar in elementary school (grades 1-6) and have forgotten much of the terminology as it relates to sentence structure. Anyway, I digress. I'm okay with 'by_apqn'.
> > Regards, > Halil
| |