From: Joerg Vehlow <lkml@jv-coder.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] lib: tst_device: Allow more control over the device size
Date: Mon, 2 Aug 2021 14:21:11 +0200 [thread overview]
Message-ID: <d02ab79b-b52a-d4c6-33a4-c836c30a7523@jv-coder.de> (raw)
In-Reply-To: <YQfhszoCgVv1mGjf@yuki>
Hi Cyril,
On 8/2/2021 2:14 PM, Cyril Hrubis wrote:
> 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.
next prev parent reply other threads:[~2021-08-02 12:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-30 13:31 [LTP] [PATCH] lib: tst_device: Allow more control over the device size Cyril Hrubis
2021-08-02 3:16 ` Li Wang
2021-08-02 6:29 ` Joerg Vehlow
2021-08-02 11:38 ` Cyril Hrubis
2021-08-02 11:43 ` Cyril Hrubis
2021-08-02 12:07 ` Joerg Vehlow
2021-08-02 12:14 ` Cyril Hrubis
2021-08-02 12:21 ` Joerg Vehlow [this message]
2021-08-02 13:23 ` Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d02ab79b-b52a-d4c6-33a4-c836c30a7523@jv-coder.de \
--to=lkml@jv-coder.de \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.