Displaying 3 results from an estimated 3 matches for "try_xenstoreds".
Did you mean:
try_xenstored
2019 Feb 12
2
[PATCH 08/13] xen init script: rewrite xenstored start logic
...stored" -- \
> + $XENSTORED_ARGS --pid-file="$XENSTORED_PIDFILE"
I really don't like the way all of this is open-coded. There are two
almost-identical runes here. How about this:
case "$XENSTORED" in
/*) USER_XENSTORED="$XENSTORED" ; try_xenstoreds=USER_XENSTORED ;;
?*) USER_XENSTORED="$ROOT"/bin/$XENSTORED ; try_xenstoreds=USER_XENSTORED ;;
'') USER_XENSTORED="" ; try_xenstoreds='OXENSTORED CXENSTORED' ;;
esac
and then
for try_xenstored_var in $try_xenstoreds; do
eval "try_xenstored=\...
2019 Feb 10
21
[PATCH 00/13] Patch blast of salsa wip.testme branch
The contents are the wip.testme branch currently on salsa. I combined
the wip.initscript and wip.oxenstored into this and added more things
today. I think this is pretty gtg and it's smoke tested (in several
cases by scping files around instead of doing package build), so it
needs a final extra review and test round before putting it in master
branch (which I don't want to force push).
I
2019 Feb 12
2
[PATCH 08/13] xen init script: rewrite xenstored start logic
...gt; case "$?" in
> 0|1) ;;
> *) log_end_msg 1; exit ;;
> esac
>
> I mean, why torture the reader of the code with counter intuitive 1
> values that mean success...
I agree. Madness.
> > for try_xenstored_var in $try_xenstoreds; do
> > eval "try_xenstored=\$$try_xenstored_var"
> > ...
>
> Yes, that way the two start-stop-daemon can be one instead, nice!
>
> And do you agree that exploding when an explicit choice has been made by
> the user + that binary can't be started i...