[PATCH 00/19 v2] mkfs cleaning
Jan Tulak
jtulak at redhat.com
Fri Jun 3 07:09:19 CDT 2016
[
snip all, another issue, unrelated to the lsunit one]
>
I realised one small glitch with conflicts watching in the code in
combination with flags. It is not regression, I think, because before now,
it was not possible to do something like -l internal=0,logdev=something,
but now it should be possible.
The code checks only whether an option was seen, not its value, so it
does't know that we are in fact disabling something. I see two ways how to
do solve it. One is a custom conflict solving for these cases, putting some
if (flag1 && option2) somewhere once every argument and option is parsed.
But this goes against what the patchset did and moves it again out of the
option table...
The other way is to make a special case for flags in the conflicts-handling
code. Basically, I would extend the structure with something like:
{ .index = L_INTERNAL,
.conflicts = { L_FILE,
L_DEV,
LAST_CONFLICT },
.conflicts_ignore_on_false=true, // new item, shorter name to be found
.minval = 0,
.maxval = 1,
.defaultval = 1,
},
And then, if a conflict is found, it checks the value and if the value is
false/zero, then ignore the conflict. A more generic code would allow for
any given value, but I think that this would be useful only for flags, so
"on_false" and possibly "on_true" would be enough.
Any comments?
Thanks,
Jan
--
Jan Tulak
jtulak at redhat.com / jan at tulak.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20160603/f0f52352/attachment.html>
More information about the xfs
mailing list