On Wed, 2020-07-29 at 22:08 +0200, Klaus Jensen wrote:
> On Jul 29 21:45, Maxim Levitsky wrote:
> > On Wed, 2020-07-29 at 15:37 +0200, Klaus Jensen wrote:
> > > On Jul 29 13:43, Maxim Levitsky wrote:
> > > > On Mon, 2020-07-06 at 08:12 +0200, Klaus Jensen wrote:
> > > > > + DEFINE_PROP_UINT8("aerl", NvmeCtrl, params.aerl, 3),
> > > > So this is number of AERs that we allow the user to be outstanding
> > >
> > > Yeah, and per the spec, 0's based.
> > >
> > > > > + DEFINE_PROP_UINT32("aer_max_queued", NvmeCtrl,
> > > > > params.aer_max_queued, 64),
> > > > And this is the number of AERs that we keep in our internal AER queue
> > > > untill user posts and AER so that we
> > > > can complete it.
> > > >
> > >
> > > Correct.
> >
> > Yep - this is what I understood after examining all of the patch, but from
> > the names itself it is hard to understand this.
> > Maybe a comment next to property to at least make it easier for advanced
> > user (e.g user that reads code)
> > to understand?
> >
> > (I often end up reading source to understand various qemu device
> > parameters).
> >
>
> I should add this in docs/specs/nvme.txt (which shows up in one of my
> next series when I add a new PCI id for the device). For now, I will add
> it to the top of the file like the rest of the parameters.
This is a good idea!
>
> Subsequent series contains a lot more additions of new parameters that
> is directly from the spec and to me it really only makes sense that they
> share the names if they can.
>
> We could consider having them under a "spec namespace"? So, say, we do
> DEFINE_PROP_UINT("spec.aerl", ...)?
I personally tend to think that it won't make it much more readable.
Best regards,
Maxim Levitsky
>
