Re: [PATCH 2/5] libxl: drop dead assignments to "ret" from libxl__domain_config_setdefault()

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

On 6/12/23 15:44, Daniel P. Smith wrote:
> On 6/12/23 07:46, Jan Beulich wrote:
> > The variable needs to be properly set only on the error paths.
> >
> > Coverity ID: 1532311
> > Fixes: ab4440112bec ("xl / libxl: push parsing of SSID and CPU pool ID 
> > down to libxl")
> > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> Reviewed-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxx>
>
> > ---
> > If XSM is disabled, is it really useful to issue the 2nd and 3rd calls
> > if the 1st yielded ENOSYS?
> Would you be okay with the calls staying if instead on the first 
> invocation of any libxl_flask_* method, flask status was checked and 
> stored in a variable that would then be checked by any subsequent calls 
> and immediately returned if flask was not enabled?
> v/r,
> dps
Looking closer I realized there is a slight flaw in the logic here. The 
first call is accomplished via an xsm_op call and then assumes that 
FLASK is the only XSM that has implemented the xsm hook, xsm_op, and 
that the result will be an ENOSYS. If someone decides to implement an 
xsm_op hook for any of the existing XSM modules or introduces a new XSM 
module that has an xsm_op hook, the return likely would not be ENOSYS. I 
have often debated if there should be a way to query which XSM module 
was loaded for instances just like this. The question is what mechanism 
would be best to do so.
v/r,
dps