[LTP] [PATCH] lib: tst_device: Allow more control over the device size
Cyril Hrubis
chrubis@suse.cz
Mon Aug 2 15:23:00 CEST 2021
Hi!
> >> The usage of foo foo_ and foo__ does not really help in reading the code :)
> >> There could also be some logic errors hiding, e.g.
> >> tst_acquire_loop_device should probably not default to DEV_SIZE_MB at all.
> >> The caller should be responsible for finding a correct size and the two
> >> users of this function (tst_device [the binary] and
> >> tst_acquire_device__) do pass a concrete value for size.
> > Actually the tst_device binary does not pass a concrete size unless the
> > shell code that calls it passes an optional parameter, so the fallback
> > to DEV_SIZE_MB if size == 0 has to stay in the double underscore
> > function. I will send a v2 that just replaces the second occurence of
> > MAX() in tst_device.c for now as it looks to me that any singificant
> > cleanup would require complete redesing of the interface and quite
> > possibly rewrite of the last 16 tests that use the old API as a
> > pre-requisite.
> I think we maximized confusion.
> I was not arguing about the defaulting to DEV_SIZE_MB in the double
> underscore function, but about the defaulting in the
> tst_acquire_loop_device function. This function is never called with
> size=0, because the call is either from the double underscore function,
> that defaults to DEV_SIZE_MB or from the tst_device binary, that only
> calls tst_acquire_loop_device if the 3 argument version (tst_device
> acquire [size [filename]]) is used and size is not allowed to be 0 in
> that case.
Well it's true that at the moment all callers pass non-zero size to the
tst_device binary but any shell test can pass down 0 to the call in
order to get the default size which is large enough for all possible
filesystems.
--
Cyril Hrubis
chrubis@suse.cz
More information about the ltp
mailing list