[LTP] [PATCH] lib: tst_device: Allow more control over the device size

[Cyril Hrubis <chrubis@suse.cz>]

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