[PATCH 08/19] mkfs: getbool is redundant
Eric Sandeen
sandeen at sandeen.net
Fri Apr 8 12:41:44 CDT 2016
On 4/8/16 5:30 AM, Jan Tulak wrote:
> On Thu, Apr 7, 2016 at 7:25 PM, Eric Sandeen <sandeen at sandeen.net <mailto:sandeen at sandeen.net>>wrote:
>
>
>
> "Many options allow for an optional argument of 0 or 1, ..."
>
> > +disable or enable the functionality, in a forward-compatible syntax.
>
> What does "forward-compatible syntax" mean? I'm not sure that clarifies
> anything for the reader.
>
> Yeah, I should reformulate it, I think. The meaning is that it won't
> matter what the defaults are now, or will be in the future. E.g., if
> you had a script creating a fs without crc before, when it was
> disabled by default, and we changed the default, you are now creating
> with the crc. But if you give it -m crc=0, then no matter what the
> default is, you have it always disabled.
Ok, I see.
> How about changing the line to "Boolean options allows for optional
> argument of value 0 or 1, to explicitly disable or enable the
> functionality," and dropping the forward-compatible part?
I think just:
Many options accept an optional argument of value 0 or 1, to explicitly
disable or enable the functionality.
would suffice.
>
>
> Otherwise this looks ok to me; Dave explained that it is intentional to
> make every single option accept a value, whether it is now
> boolean or a numeric value, so there is no such thing as a bare "--flag"
> anymore; such flags are always "--flag [0|1]" now, right?
>
>
> For options inside of -m, -d and such, yes. Top-level flags, that is
> -f, -q, -N, -K and -V, are still only flags, but these don't change
> the FS attributes. They are something different from the other.
> Still, I wonder whether they should accept [0|1] too...
Eh, not right now ;)
Thanks,
-Eric
More information about the xfs
mailing list