RE: [PATCH v10 03/10] admin: introduce group administration commands

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Tuesday, March 7, 2023 8:06 PM
> 
> On Wed, Mar 08, 2023 at 01:01:27AM +0000, Parav Pandit wrote:
> >
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Tuesday, March 7, 2023 7:34 PM COMMAND_SPECIFIC_ERR is just
> > > way too much detail - commands generally just should not fail it's a
> > > quality of implementation issue.
> >
> > I disagree partially.
> >
> > 1. Hw device != sw_hypervisor device.
> > Device may fail or error out that may need want sw driver to retry.
> > Like Stefan's example, it may need to return timeout/retry intermittently.
> > Doesnt means the device is broken at that point.
> >
> > 2. A device implementation may not have imposed a certain locking scheme
> to synchronize VF enablement with VF provisioning.
> > ENODEV can reflect two commands not synchronized.
> >
> > So Boolean 0 = success, 22 = error is not the right way to craft the spec.
> > Many times, those sub-error codes are good indications of what may have
> gone wrong in the field.
> > Useful for the quality issue you pointed out to debug.
> 
> Maybe, but I think we can just leave this stuff for later. Too much hand-waving,
> when we add commands that actually need this kind of ability that is when we
> will add the relevant error codes.
Sounds good to me.
I thought the whole reason you wanted to use errno.h was to reuse all applicable error codes from it.
And so doing it in one go appeared natural to me.
As long as adding new error codes doesn't need new feature bits or new/extension of list commands, adding later looks good to me.
As long as we agree that adding more error codes to reflect specific errors is fine, (not Boolean 22), seems like a good direction.