Re: [PATCH v19 11/20] s390/vfio-ap: prepare for dynamic update of guest's APCB on queue probe/remove

[Tony Krowiak]

On 6/7/22 8:05 AM, Halil Pasic wrote:
> On Tue, 31 May 2022 06:44:46 -0400
> Tony Krowiak <akrowiak@xxxxxxxxxxxxx> 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