On Tue, Dec 17, 2019 at 12:44:19AM +0000, Al Viro wrote:
> On Wed, Nov 06, 2019 at 11:14:42AM +0100, Lukas Czerner wrote:
> > + fsparam_string_empty
> > + ("usrjquota", Opt_usrjquota),
> > + fsparam_string_empty
> > + ("grpjquota", Opt_grpjquota),
>
> Umm... That makes ...,usrjquota,... equivalent to ...,usrjquota=,...
> unless I'm misreading the series. Different from mainline, right?
Unfortunatelly yes, I do not think this is a problem, but if you have a
solution within the new mount api framework I am happy to use it.
>
> > + fsparam_bool ("barrier", Opt_barrier),
> > + fsparam_flag ("nobarrier", Opt_nobarrier),
>
> That's even more interesting. Current mainline:
> barrier OK, sets EXT4_MOUNT_BARRIER
> barrier=0 OK, sets EXT4_MOUNT_BARRIER
> barrier=42 OK, sets EXT4_MOUNT_BARRIER
> barrier=yes error
> barrier=no error
> nobarrier OK, clears EXT4_MOUNT_BARRIER
> Unless I'm misreading your series, you get
> barrier error
Not really, this seems to be working as expected. Assuming that this
didn't change since 5.4.0-rc6. I does make sense to me that specifying
bool type parameter without any options would express "true".
> barrier=0 OK, sets EXT4_MOUNT_BARRIER
> barrier=42 error
> barrier=yes OK, sets EXT4_MOUNT_BARRIER
> barrier=no OK, sets EXT4_MOUNT_BARRIER
Those three are different, just because of how param_book() work. I do
not really see a problem with it, but if we want to keep it exactly the
same as current mainline it would be difficult with how the current api
works. Any suggestions ?
Thanks!
-Lukas
> nobarrier OK, clears EXT4_MOUNT_BARRIER
>
> Granted, mainline behaviour is... unintuitive, to put it mildly,
> but the replacement is just as strange _and_ incompatible with the
> existing one.
>
> Am I missing something subtle there?
>
