Re: [Xen-devel] [PATCH v2] tools/xenstore: Do not abort xenstore-ls if a node disappears while iterating

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Fri, 2019-08-09 at 12:27 +0100, Ian Jackson wrote:
> Can you explain to me what your needs are for all this ?  I want
> xenstore-ls to be able to do what you want, but I don't want to impose
> a lot of work on you.  I also want the correctness property I mention
> above.

Ultimately, I don't really care about anything but the ENOENT example
that I gave in my previous email:

(dom0) # for a in `seq 1 1000` ; do xenstore-write /local/domain/2/foo/$a $a ; 
done

Now simultaneously:

(dom0) # for a in `seq 1 999` ; do xenstore-rm /local/domain/2/foo/$a  ; done
(dom2) # while true ; do ./xenstore-ls -p /local/domain/2/foo | grep -c 1000;  
done

I want to see node 1000, reliably, every single time. I absolutely
don't want it aborting because of the other nodes disappearing between
the xs_directory() on the parent, and on a (now removed) child that I
don't even care about.

> My view of the ideal situation would be for xenstore-ls to have
> defined exit status values, like
> 
>   0    everything went well
>   1    not used, reserved because some runtimes etc. invent 1
>   2    permissions of at least one node could not be printed
>   3    value of at least one node could not be printed
>   4    children of at least one node could not be listed,
>         nodes may be missing
>  127   catastrophe, all bets are off

Sure.

> And maybe some command line options to control which of these
> conditions print a message to stderr, and/or to turn some of them into
> 0 for the caller's convenience.

That part seems like overkill.

> But this would involve xenstore-ls having a global variable where it
> accumulates the error status, and going through the whole program and
> fixing the error handling (which currently seems not very good to me).

I don't think we need a global variable. The do_ls() function is
recursive and could return an error which then accumulates. The straw
man in my previous patch fixes up most of the error handling and makes
sure we're only printing one error per node, and could fairly easily be
extended to return an error value. Then we just need to define
priorities for ENOENT vs. EACCESS (or make it a bitfield, but let's
not).

> If you want to do that, then great, let us talk about the details.
> 
> If that's too much work then maybe you can do something now which at
> least goes in the right direction.

I'll send a v3 of the original patch which *only* ignores ENOENT. That
one really shouldn't need to cause a non-zero exit status because it's
equivalent to the case where the child node didn't exist when we called
xs_directory() on the parent. Then we can refine the rest of the
cleanup in a follow-on patch.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel