[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